Gorilla Testing Vs. Monkey Testing

Gorilla Testing:

The core of this type of testing is linked associated with testing a particular module repeatedly by generating random inputs. Often, in this testing technique testers and developers collaborate to test a module’s functionalities repeatedly. The random inputs consist of positive and negative values to assess the system’s performance under stressful conditions as well as to ascertain that the positive inputs follow the desired flow of execution.

There isn’t any rule of thumb to implement this type of testing, it is simply an exhaustive form of testing that emphasizes on digging more and more into an application to uncover the various paths and related issues if any.

Monkey Testing:

In monkey testing, testers perform unit tests without any specific set of test cases. This type of testing has been attributed to the behaviour of a monkey which hops here and there performing random activities every time. The user testing the application is referred to as a monkey who ideally performs random actions

Therefore in monkey testing a user or a tester can input random values to a unit or module, maybe, a string or an integer to verify whether it performs the desired set of actions. 

Gorilla vs Monkey Testing:

Gorilla Testing:

• A type of manual testing which is often termed as a repetitive testing.
• Aimed at testing one module thoroughly.
• A single developer or tester can perform tests even if they possess any knowledge of the application.
• Gorilla testing is meant to test the functionality of a specific module at a time.

Monkey Testing:

• Monkey testing uses test cases to test an application and also known as random testing.
• Randomly checks are performed to ensure that the system does not crash.
• Monkey testing is generally conducted by testing teams.
• Monkey testing is about testing units or modules with random inputs.

Conclusion:

Gorilla and monkey are similar in the sense that they focus on randomly testing a given software under test so that every possible area is verified against the requirement specifications. Both tests thus form an inevitable part of the QA process.