How To Create Diversity While Testing — “Group Testing”
There is no doubt that software products are more complex than ever before and the testing process should be diversified enough to ensure the quality for such products. Easy to say! But in practice we need to establish a good balance between manual testing, automated testing, exploratory and on the development side, unit testing and integration testing.
All code is guilty until proven innocence.
During time, I have learned that when a fresh pair of eyes was added to the testing activity, new bugs were found in a very easy manner, in some areas of the application that used to be throughly tested before. After a period of time working on testing the same product, we, as testers usually tend to think to similar or same scenarios to test and we tend to find the same old bugs. That’s why I think is good to bring once in a while some other team members to be involved in testing process.
These being said, let’s go deeper into the story!
Having the Testing Dojo concept in mind, we extended and adapted it to our needs and renamed it to Group Testing. Long story short, a testing dojo is a reunion of testers exercising their testing skills on an application. What we did was to involve all the team members, not only the testers, in the session of Group Testing, and by all the team members I mean developers, project manager, business analyst and designer.
Which is the main focus of the Group Testing?
We focus on the functionalities implemented in the ongoing sprint, trying to create scenarios to cover as many use cases as possible. Having such a diversity of roles participating, every team member has different sets of interests and the application is exposed to different types of tests.
When do we do the Group Testing?
Usually one day before the end of the ongoing sprint (2 weeks sprints) when most or all the functionality implemented in that sprint is delivered by the developers to testing. Group Testing session is time-boxed to 1 hour. (This concept I describe you now is not strictly applicable when using Agile methodologies, but it can be successfully used with some other types of processes — V model, Waterfall etc. It only depends on you as a team to decide when to do the Group Testing session. You can also take into account the functionalities implemented for a release and to involve all your team members in the testing process). This kind of activity is also very helpful when there is a limited period of time for us to cover all of our test cases and involving more people we get a better testing coverage.
How do we do the Group Testing?
We usually set some guidelines before starting testing. The application we are working on is a decision making helper and permits having several types of users. The first step is to define what users are we going to use in the Group Testing session and we decide on which areas we are going to focus on with respect to the functionality delivered in the ongoing sprint, as the whole application cannot be tested in the 1 hour that we have. Also, one of the team members participating will permanently check the server logs of the application to monitor the requests that are made by the others during testing and to spot any potential server errors.
The Group Testing session ends with a list of issues that were found and after that the testers are working to add them to the test management tool with all the required details.
We learned some lessons while using Group Testing activity and one of the most important is that brings a lot of diversity into the traditional testing process. The purpose of this activity is fully accomplished when all of the team members have the same understanding of the application functionalities and each of them brings their input on testing it. I believe that when there is a good plan to follow, the Group Testing can be a worthwhile investment for all the team members.
Photo by rawpixel on Unsplash.