We hear a lot about gamification in enterprises and specifically in software testing. We had an eminent speaker Ross Smith who gave a keynote, at our annual technical conference, Qualloquium at QA InfoTech on leveraging games in software testing. When I sit down to think more about this I am flooded with questions – where can I introduce games, how and when should I use them, how do I encourage and guide my team into this whole process, who will build these games and so on.

Some of the core areas where games can be introduced in software testing include functional, UI, usability, localization test attributes. I am just thinking aloud in this post, on some ideas where games can be introduced in these areas to kick start this whole process of “Leveraging games in software testing”

1. If the application has a lot of localization scope, the localized version can be made available as screens for players to evaluate one screen at a time and win based on number of bugs found. Static UI can also be evaluated along these lines to spot any design or presentation issues

2. If the application is a communication / messaging kind of an application, multiple players can be brought in at the same time to try and use several features and collectively find issues from a functional angle

3. If the application’s usability is under test, varied screen shots can be provided like a jigsaw puzzle asking players to arrange them into the top 3 most usable workflows to understand what the intuitiveness element looks like

4. Combining all of the above, look to see if bug bashes can be organized as games with specific times and prizes announced for varied categories of winners

5. Arrange a contest inviting testers to design games around testing the application such that the most valuable game is rewarded

If all of these are used in conjunction it may overwhelm the team and drift them away from their core focus area of quality of the product under test. You could start small by trying a few of these, see what positive and adverse outcomes arise specific to your team, before you branch into anything bigger. For sure, bringing in games into testing adds fun, promotes collaborations and breaks any monotony the testers may face. So, try some of these and see the difference for yourself!

Performance Testing has grown to be a niche that testers aspiring to build a specialization can focus on. Performance Testing is a large discipline in itself covering several aspects such as load, stress, overhaul test scenarios, capacity planning etc. While each of these warrant their own tests, every kind of performance test fits into a larger test life cycle that involves collecting requirements, defining and designing tests, test data generation (which is a rather important piece in performance testing), test execution, performance benchmarking and tuning. Tuning essentially refers to the activity of making changes (be it configuration or code, sometimes even at the design level), aimed at improving system performance. So, tuning could either be pro-active or re-active depending on when in the product lifecycle it is actually done. Performance tuning is not always undertaken at the request of a tester. A developer, designer, analyst could equally bring in tuning suggestions based on their scope of operations. A tester could take in tuning suggestions based on his test findings but since this is done most often after implementation these are not as proactive as they can be. If the same tester is able to make these tuning suggestions even at the design or coding phase based on his review of the specifications, it can get more proactive in nature. However, tuning is not always very black and white. There are a lot of gray areas that need iteration, ongoing evaluation and understanding of the product, competitive analysis etc. Given all of these, the tuning recommendations made even at the testing stage are very valuable rather than having these come in from the end user after implementation. Also, tuning may sometimes be very quick to implement; however, more often than not, they require a lot of trial and error, troubleshooting and debugging to ensure the right areas are touched on and tuning is done without impacting the performance of other modules in stake.
Tuning is an area of specialization of its own even within the larger performance umbrella. As a tester in the performance space, one can either build specialization as a generic performance tester or a core go-to person in performance tuning spreading his reach across the product and performance life cycle significantly enhancing the system’s overall performance.