Agile testing differs from testing within the traditional software development environment. In Agile, testers are team members working closely with developers and are partners in delivering quality. Traditional testing generally is performed by a separate test group from the developers. I emphasize the testing differences by looking at two scenarios and focus on two different types of “feelings” which result.
Many of my Agile and Scrum classes are to train organizations who are migrating from traditional software development processes. Typically, these organizations have Development groups which are separate from the Quality Assurance (QA) groups. In most cases, the groups even report upward through different management chains. The traditional process is for development to write and unit test the code (maybe other automated or regression tests) and then submit it to QA for further enhanced testing and bug reporting. Development teams often move onto new tasks, features, or even releases. When QA finally reports the bugs, the development teams must stop their current work to remember what they did previously in order to fix the bugs. Or optionally, a different maintenance team is assigned to fix the bug, but they may not have previously worked in the code area and must spend additional time to investigate the root cause of the problem.
Let’s look at two different scenarios which compare testing in a traditional environment as described above to an Agile environment where testers and developers work together in the same team.
As a class activity, I choose a test engineer and pose the traditional scenario “A developer is under pressure to meet deadlines. The developer submits code to be tested, you run tests and find bug(s). My question is “How do you feel when you find the bug(s)?” Now I know most software engineers do not like to expose feelings so this often creates a bit of uneasiness. But the tester often sits up and replies “I feel great. My test worked. My manager measures my performance on number of defects I discover, so the more bugs identified, the better”.
I follow-up with the Agile testing scenario. The developer and tester are now together in the same small boat, working side by side. At some point the tester notices a “hole” in the boat. My question to the tester is the same “How do you feel about finding the hole?” The response is usually, we need to “fix-it”. This is a totally different feeling and expresses the essential need to fix issues as they are found. It is better to have fewer holes (“bugs”) than more. They are both responsible for getting this fixed.
In summary, developers and testers work together in the same Agile team which provides several benefits over the separate development and QA organizations. Defects are often found earlier which make them easier and cheaper to fix. The developers and testers are partners in delivering quality software and both are accountable. Testers can provide early feedback to developers and may have a different perspective which the developer would not otherwise have considered in coding the design. It is no longer acceptable to “throw code over the wall”, declare some form of “development done” and move onto a new task. Delivered code should meet the acceptance criteria and be of “shippable” quality.
In an Agile project, it is common for the number and severity of bugs to decrease. So what about the QA Manager who measures testing performance by number of bugs found? This is another mindset shift. Testing performance should be evaluated upon the quality of delivered software and not the number of reported bugs. More on Agile metrics in future blogs, stay tuned.
