Software QA in an Agile World: Achieving Agile Testing

Software Quality Assurance (SQA) — a planned and systematic approach to the evaluation of the quality of and adherence to software product standards, processes, and procedures.

Agile development is the concept of churning out a continuous stream of product releases, most of which are expected to enter production. QA being ‘planned and systematic’ as stated above flies in direct contradiction to the prime motivations of Agile. Two of the main challenges of testing and QA management under the Agile methodology are:

• Agile teams are supposed to be cross-functional and self-organizing which means that there is to be a minimal level of specialization among the members. Like a start-up company, members of an Agile team should all be able to do anything required to get the product out.
• The Agile methodology is based on incremental development. So, every sprint creates a deliverable version that is a release candidate. This doesn’t make testing go away, it means that testing must be just as continuous as development through the entire life-cycle. Nor does regression testing disappear from the agenda. If anything, it becomes even more intense and vies for QA resources right alongside functionality verification.

So if QA is so antithetical to Agile, what is the point of having a QA team in the first place? Why not simply have the developers test their code as they create it? After all, they wrote it so they should have the best grasp of both the code and the functions it is intended to provide. To quote the bard, ‘therein lies the rub.’

Pushing testing responsibilities onto the developers does not make them accomplished testers. Instead, the lack of well integrated QA test personnel makes for frazzled, overworked developers. Code development and code testing require different mindsets and very different approaches.

The developer knows what the code is supposed to do and approaches testing it to demonstrate that it does exactly that. The tester approaches the code from the expectation that it won’t do what it is supposed to and looks to try every possible way to prove that it doesn’t.

It is no leap of imagination to realize that this tends to put developers and testers at odds with each other to speak well of the situation. Hold that thought for a moment and then try to imagine compressing both these perspectives into one person.

What Does Agile Testing Really Look Like?

Before Agile, there was the Waterfall methodology. Code updates were often referred to as being “thrown over the wall” to QA for testing. This phrase embodies the perspective of the day that prescribed a complete separation of development and testing. Engineering and QA were separate, divided functions and never the twain should meet. While this worked for a months-long development cycle, it is totally impractical for a days-long sprint cycle.

Agile requires that testing and development proceed in parallel and, as much as possible, that they overlap each other. This means that developers take on white box module testing from their perspective of code awareness to see that all the observable workings of each code module function as that developer expects. It also means that QA oriented testers take over with black box testing just as soon as service stubs and minimal system integration of the new code allow.

There is no longer a sharp dividing line between development and testing that supports or even allows the ‘throw it over the wall’ attitude. QA personnel begin to work with the new code as soon as it is white box tested and then turn around and work with development to help generate test automation scripts that will follow the new code through its release into production.

Note that development and testing are working hand-in-glove with each other. Development is striving to get the maximum conformance of the functionality to the specified new feature or bug fix. Quality is approaching from the business process side to make sure that development’s translation of the functional specs actually results in what the customer (and by definition product marketing) really wants.

How Do We Get to Agile Testing from Here?

Reducing a complex undertaking to a simple statement, QA has to be merged into the entire Agile SCRUM team. In a bit more detail, SQA must be integrated into:

Product Management

When management is planning product feature additions/changes, QA should be involved in identifying the necessary elements to be specified to development to get the desired results translated into working code. Specifying Agile stories, their scope, their interdependency and the use cases to be satisfied are all prime areas for QA participation as they have spent the most time with the system as a whole and have an innate understanding of its structure.

Sprint Planning

From epics to stories, QA provides oversight of plan viability and QA resource requirements for each effort. Often sprints are planned against development effort points. QA needs to add velocity points for the QA effort as well, especially where that effort may be greater than anyone other than QA realizes.

Sprint Execution

QA works directly with planning to make sure that resources and time are allocated for necessary testing activities. They also assure that there is daily input at the stand-up meetings about QA status and they participate in retrospectives to improve development and test processes.

Documentation

Agile has very nearly turned documentation into a dirty word. It diverts hours from other ‘productive’ activities and, besides, everything is going to change too quickly to document in any event. Code documentation has devolved to no more than the comments blocks that developers put into their modules. But, when someone has to go back into the code to work on it, QA’s documentation of test cases becomes an invaluable resource to reconstruct what each piece was supposed to do. And user guides are still necessary. The technical writer’s right hand resource is still the QA tester who worked all the way through the project.

User Acceptance Testing

QA acts as the gate keeper when the code exits development and enters the User Acceptance Testing phase. This is where QA stands in for the customer to make sure that features and their controls perform intended tasks and don’t have unexpected glitches (no it’s not a feature). This is also where regression testing must be performed to verify that this sprint’s fixes work without unfortunate side effects and that past sprint’s fixes are still in place.

Lions and Tigers and Software QA Oh My!

If all this has started to sound somewhat overwhelming, consider this possibility. QualityLogic has been working with software development organizations for over 30 years and has seen the rise and organizational angst of dealing with many Agile implementations.

Our test technicians and engineers work directly with our clients’ development organizations to consult on the transformational effort of merging them with QA. In many instances, we have provided a significant portion of the QA staffing required. Those same engineers and techs can work directly with Agile sprints to perform all the merged QA efforts described above and more.