What is Monkey Testing in Software Testing?
Monkey testing is a technique in software testing where the user tests the application by providing random inputs and checking the behavior (or try to crash the application). Mostly this technique is done automatically where the user enters any random invalid inputs and checks the behavior.
As said earlier, there are no rules; this technique does not follow any predefined test cases or strategy and thus works on tester’s mood and gut feeling.
Many a time, this technique is automated or rather I should say that you can write programs/scripts that can generate random inputs and feed into the application under test and analyze the behavior. This technique works very well when doing load/stress testing when you try to break your application by proving non-stop random inputs.
Before I speak about “Monkey”, let me introduce you to “Horse”.
You see a Bridle in Horse right? It is used to direct and control the horse so that it does not loses its focus and concentrates only on running straight on the road.
Similarly, be it manual or Automation, we are like a horse in testing because we are directed and driven by the test cases/plans and strategies, and controlled by the quality metrics. Because we have a bridle around us, we don’t want to divert our focus and strictly concentrate on the set of test cases and obediently execute them.
It’s perfectly fine to be a horse, but sometimes don’t you enjoy being a Monkey?
Monkey testing is all about “do what you want; automatically”.
This testing technique is a bit chaotic because it does not follow any specific pattern. But the question here is
Whenever you are exposing a big web application to the world, could you imagine the kind of users you are catering your application? There are definitely some good users, but you cannot be very sure that there will not be any nasty users. There are “n” numbers of nasty users, who are also like monkeys and love to play around with the application and provide strange or large inputs or break the applications.
Hence to test on those lines, we testers also have to become Monkey, think and eventually test it so that your application is safe from the outside nasty monkeys.
There are 2: Smart and Dump
Smart Monkeys – A smart monkey is identified by the below characteristics:-
- Have a brief idea about the application
- They know where the pages of application will redirect to.
- They know that the inputs they are providing are valid or invalid.
- They work or focus to break the application.
- In case they find an error, they are smart enough to file a bug.
- They are aware of the menus and the buttons.
- Good to do stress and load testing.
Dumb Monkey – A dumb monkey is identified by the below characteristics:
- They have no idea about the application.
- They don’t know that the inputs they are providing are valid or invalid.
- They test the application randomly and are not aware of any starting point of the application or the end to end flow.
- Though they are not aware of the application, but they too can identify bugs like environmental failure or hardware failure.
- They don’t have much idea about the UI and functionality
The bugs reported as a result of Monkey testing requires a detailed analysis. Because the steps of reproducing the bug are not known (most of the time), recreating the bug becomes difficult.
I feel that it would be good if this technique is done at the later phase of testing when all the functionalities are tested and there is some level of confidence on the effectiveness of the application. Doing it at the beginning of the testing phase would be a higher risk. If we are using a program or script that generates valid and invalid random inputs, the analysis becomes a bit easier.
Advantages of Monkey Testing:
- Can identify some out of the box errors.
- Easy to set up and execute
- Can be done by “not so skilled” resources.
- A good technique to test the reliability of the software
- Can identify bugs which may have a higher impact.
- Not costly
Disadvantages of Monkey test:
- This can go on for days till a bug is not discovered.
- Number of bugs are less
- Reproducing the bugs (if occurs) becomes a challenge.
- Apart from some bugs, there can be some “Not Expected” output of a test scenario, analysis of which becomes a difficult and time-consuming.
Though we say that the “Test Monkeys” or Monkey testing is chaotic, it is recommended to plan for it and assign some time at the later phase.
Though in initial phases of this technique, we may not find some good bugs, eventually it can discover some really good bugs like memory leaks or hardware crashing. In our regular course of testing, we normally ignore many cases thinking that “this scenario” will never happen, however, if happens, can lead to a serious impact (example – low priority and high severity bug).
Doing monkey testing can actually dig out these scenarios. We by any means we come across such a situation, I would recommend finding some time to analyze it and try to come up with a solution.
In my opinion, the best way is to have both the “Horse” and “Monkey” together.
Through “Horse” we can follow a well-planned, well defined and sophisticated method of testing, and through Monkey, we can undercover some really nasty situations; and together, they can contribute to achieve more quality and confidence in the software.