The test scenarios, both positive and negative, can be varied and can involve (especially if the app or feature is complex) a large number of cases to reproduce, in addition to various test environments, operating systems, database engines, browsers and devices.
Bug finding can be, in many cases, a highly complex task for a single QA, and that is why pairing with another QA is recommended to save time and ease loads. But since there can be 2 people testing simultaneously, what if we try with 4? Or 6? And why not 8?
This is where group testing techniques become very important. A very efficient technique when it comes to doing this work as a group is War Games.
What are War Games About?
War Games consist of testing an app, or a set of its features, working in groups "attacking" multiple test scenarios in parallel, with different points of view and approaches when it comes to detecting bugs.
This task is carried out during a time interval set by the team leader (generally, between 1 or 2 hours). Then, a record is made of the number of issues that each one has been reporting, hence the "games" feature.
War Games make sense when the application or feature is in an advanced stage of development, so that the developer can provide the QA with a more precise description of how it works and thus develop more robust use cases to start testing.
Let the game begin!
Below we are going to develop an example of the entire procedure (based largely on my personal experience):
Suppose we have a team of 5 QA: John, Paul, Sophie, Patricia and Peter, who need to test an application of a social network which consists of several features that are being developed by several developers.
These features are new account registration (including profile customization), creation of status on a wall (including uploading photos and videos), creation of content in groups (open or private), chat service between contacts and monetary transactions (to, for example, get certain premium benefits).
These features are assigned as follows:
The War Games are Friday 10 am through 12 pm.
During the week in which the War Games begin, John is in charge of testing the first feature, in this case, account registration, developed by Matthew.
Once the developer finishes coding, the testing is carried out from Monday to Thursday, verifying the app feature on both native mobile and web versions of the application, using a Samsung S5 tablet with Android 11 as the operating system.
During this period, the QA keeps in close communication with the dev, clarifying feature test cases and determining what should be expected and unexpected behavior. As of late Thursday, John has reported 5 issues related to account creation.
On Friday at 10 am the rest of the team begins the War Games day, starting with the following table of reported issues, and with different assigned environments:
Having finished the War Games around noon, the following result is obtained:
In total, 15 issues have been reported, some of them being specific to the operating system, and others related to the browser in which the application was tested.
We can say that John finishes as the “winner” of this “battle” of the War Games, as nobody could equalize the 5 reported issues (Patricia was the closest, with 4).
These issues found during the War Games are reported to the developer, who will be responsible for fixing them.
Then, the same procedure is repeated for the rest of the features. If desired, environment assignments can also be switched between QAs.
It may also happen that the application is simpler, or that it is decided to test all the features together once they are all developed.
If such is the case, the process is similar to the previous one (with the omission of the step of testing a feature for four days by one specific QA), though the War Games session can be longer and involve more than one day within the same week.
Given the example above, this is recommended to verify how the integration of all the features works, especially being near the release date, as a “final” War Games instance.
Pros and Cons
Pros:
● Multiple QAs with different points of view and orientations are certifying a feature or app, making bug finding richer and more complete.
● Different environments are tested simultaneously, using different devices and operating systems.
● Teamwork is promoted and bug finding and communication with devs is streamlined.
● Being a "game", each QA seeks to improve him/herself in each instance of War Games and strives to find the best bugs, leading to a more intelligent testing.
● Fun way to find bugs!
Cons:
● It is recommended to do it every certain period of time, when any important change is made in the flow, architecture or business logics of an application, since doing it weekly can be exhausting (it implies stopping the activity of the team for 1 hour or more).
● It can generate feelings of unhealthy competition or frustration on the members who report few issues (for example, a QA with a lot of work from other projects, or not streamlined with bug finding).
● Lasting a limited period of time, the rush can lead to false positives, especially if the devs are absent during that interval for some reason and cannot solve questions made by QAs.
Conclusion
Every task involved during the software process always takes time, and must be done with absolute responsibility, focus, and commitment.
But that does not imply that the atmosphere should be tense, nor should the task be prevented from being enjoyable and entertaining.
In this article War Games are presented as a technique used by QA teams, but it can easily be adapted to any set of tasks related to any project, whatever the type, because it is a "war", but a peaceful one, since it is a "game" in which all the members of the team pull in the same direction.
We improve ourselves so as to bring out the best of each one, but at the same time we learn from our mistakes, we split workload, and we help each other by sharing knowledge, experiences and points of views to accomplish an important objective, like finding errors to improve the quality of the product.
In this way we grow as professionals and, most importantly, we grow as a team.
Also, if you are looking for software testing services, please consider my company Devlane,
which has been recognized as a Top 30 Software Testing Companies in 2021 by DesignRush.
In here we have a huge QA team that is ready to test any product. You can find more information over here.
