Agile QA

04 March 2014
Jedrzej Osinski
Frink_Cognifide_2016_HeaderImages_0117
2014-03-05_09h42_19 The concept of software testing is as old as computer science itself. However, during a last few years the perception of a QA engineer in companies has significantly changed. The number of tasks associated with QA and the responsibilities of QA have been constantly increasing as the IT industry continuously discovers newer and newer meanings of the word quality. Let's review these changes...

First, what is the definition of a tester? Well, if an employee from a different department is asked, they would usually define a tester as someone who verifies whether the product meets the functional requirements described in the documentation and meets the requirements of the company (clients’ policy, ethical rules) as well as domain standards (e.g. law aspects, like the EU cookie directive introduced recently) and suggestions (e.g. web content accessibility guidelines). Often this definition would still work.

However, very soon it may be surprisingly to some people to realise that a tester not only verifies whether a system does the right things (and nothing else!) but also evaluates whether the application does these things right. Does it work fast enough for standard customer needs? Can it operate for longer periods of heavy load (soak tests)? Is it able to recover and have all of its services working properly after a period of limited resources (stress tests)? Performance tests verifying efficiency and reliability are currently recognized as one of the common QA tasks.

But the responsibilities already mentioned are just the pieces. Nowadays a QA is a permanent member of an agile development team. His work does not begin after an application is fully implemented but rather starts with the project’s kick-off. This not only gives a tester time for preparation and project discovery but more importantly, provides a team with professional and early feedback on potential future risks, e.g. possible difficulties in testing, potential holes in the concept model or problems in its future maintenance. A good QA goes even further and takes part in the design phase when he or she looks at team ideas from different perspectives such as usability tests (e.g. based on the Nielsen’s heuristics). “Would this additional feature really make an end-user’s life easier?” Nobody knows that better than a tester who has already been reviewing hundreds of applications.

 What will come next? What other meanings of quality are missing? The main responsibility of a QA engineer is to measure and monitor the quality of a product, but is a product the only thing a QA should care about? A product is not in a vacuum nor is it conceived in thin air. In the beginning it develops in the minds of the product owner, developers, and UI specialists. Its elements are somehow hidden in the process, and the process itself affects the final product. If the process fails, the product is likely to fail as well. To ensure the high quality of the product, it is crucial to be sure that the quality of the development process (e.g. the scrum process) is adequate. Does this mean a QA should partially be a Scrum Master? Or maybe a Scrum Master is a special kind of QA? It does not matter which statement sounds more true to you, one thing is for certain: extending QA responsibilities (since the early fifties of XX century) makes these two roles so much closer to each other now than ever before. Revolution? The QA role has been changing constantly to meet new challenges since the moment the first software program was run. And this process will probably never end. It is the QA evolution!

 So is it a good idea to merge QA and Scrum Master roles? Some readers will immediately deny finding it to be in disagreement with the Agile Manifesto. But what if the world is not perfect? Mixing these two roles is not love at first sight but rather a marriage of convenience. In future posts we will share our experience of doing this at Cognifide...