Facing Quality Challenges in Agile Teams

By: Aya El-Gebeely

One of the Agile practitioners tweeted  this quote : "Many Agile-related questions I get are of the type "How do we drive a car safely when it has only 3 wheels, no breaks, and a blind driver?". This is pretty true, because many people consider that software product quality will find itself a path through and just be there, without giving it even small portion of thought.  As  mentioned in various literature about Agile teams, that the product Quality is the responsibility of the whole team. All team members work closely(Product owner - Developers - Testers - Architects - Technical Lead..etc.)to get the software product to the light. And the capacity to create high-quality solutions lies in the (Will) of the team and their dedication in considering quality through project's  different phases.

On tight schedules teams tend to squeeze out the time dedicated for QA and testing activities, with a whole focus on getting the set of features done. Actually this may work for small projects and teams, but getting sloppy with process not always succeed; as we ignore the fact that higher penalty  and technical dept will accumulate  on the team, and then you find that more time and cost are depleted in the maintenance and rework. This was discussed before  the Technical dept posted recently.

If we looked at the project life cycle through the QA lens, we can see it mainly as the iterating of two major activities:

Bug Injection Phase and Bug Removal Phase

As more code is written as more bugs are injected, the developer's experience and neatness of the  design and the code determine the bug injection rate, but however, there is no bug free code. On the other hand, Bug removal occurs during through the requirements and design review, code inspection, multi-level testing and maintenance activities.

So the goal here is to minimize the rate of (Bugs Injection) and maximize the rate of (Bugs Removal).

Agile principles help a lot in distributing the Bug Removal tasks across the project life time rather than stuffing them it in the last two months of the project when deadlines are near, team members are under stress, and the cost of solving a bug is relatively high.

There isn't a best recipe for quality, yet there are some practices that when followed consistently tend to sustain the software quality. However, it all lies in the hand of the team and their commitment; along with the believe of the management that time invested in such activities (Bug Removal activities) will pay them back when having mature software, satisfied customers and less complains.

Here we will present some of the most effective activities that could be done to minimize the rate of bug injection through different project phases:

1- Requirements review:

One of the very common mistakes and problems is the unclear  requirements. Don't you agree that it's really awful to exert effort, money and time in delivering the wrong feature!

Yes, we can not  have the very fine details of everything, but at least for the features that concerns us most, and make sure that the team members clearly understand the requirements and how the end user will be using it. In each sprint (iteration), the Product owner should review the features backlog with the team, and update them with any changes and reassure that it's clear to everyone.

2- Code Walk-through and Inspections:

Team members invite each other in reviewing the source code, illustrate it to each other, so that they collectively verify and validate the: quality of the code, how the design was implemented and getting direct feedback from their peers. Code walkthroughs or code reviews are very effective quality assurance and education tool for the whole team. A team can collaborate together to build a code walkthough checklist to use during their inspection sessions.

3- Session Based Testing:

Session Based Testing was developed by Jonathan and James Bach in 2000. In brief it's based on dividing the testing load into sessions, where each session has a mission (a well stated desired outcome from the testing session), each session have bounded time and the tester should be uninterrupted while the testing session is conducted.

 After the session ends the tester debrief the outcomes and bugs with the Testing and/or Technical Lead and then start  another session. This method has shown to be very effective and efficient; testers are very focused while conducting a session, and the bugs' definition and localization are done more precisely. So for each sprint, testers should start planning their sessions ahead and get them done by the end of the sprint.

4- Bug Triage Meeting:

During the sprint planning meeting, the team review the bugs' repository (it's highly recommended to use Bug Tracking System), and assess the priority and severity of each bug, and check whether a bug requires immediate attention or could be deferred. By including this activity, team members will always aware of the bugs present in the software, immediate actions are taken in the correct time (most likely while the implementation details are still fresh in the developers' mind), and any design or refactoring needs are discussed openly.

5- Risk Based Testing (Mini Regression Cycles):

Regression testing is the process of testing the whole application after major changes are done, to assure that no newly added feature or bug fixation had caused damage to other modules. It helps in assessing the integrity of the application, and allows that team to spot integration problems and to chose a release candidate. However, Regression testing is relatively time consuming task, and certainly an Agile team will not always be able to conduct a regression testing cycle each sprint. Testing people find that we do not have to test "every" feature in the application each sprint, yet we can at least iterate over the high risk (most important) features and test them each sprint, to simply assure the sanity of the application after changes occurred during the iteration.

6- User Acceptance Testing (UAT):

The customers and the team should communicate often, not only in the beginning and at the project delivery, involvement of the customers through the project iterations will always keep them updated with the newly added features, get instant feedback from them and be able to measure their satisfaction. User acceptance testing increases the confidence of both the development and business team in the application being built.

Quality is not for free, one need to focus and consider time and cost invested in assuring the quality of the software through the project life time. When QA activities are integrated within the team daily activities, over time it will flow seamlessly and hopefully will bring satisfaction to all stakeholders on the long run. 

About Aya El-Gebeely:

 Software QA engineer at Symbyo Technologies Egypt.Aya's primary focus is to deliever successful projects.Contact with Aya at:http://ayagebeely.blogspot.com.