After attending a recent Quality Assurance conference, I realized how few companies have jumped on the “Agile Development” bandwagon. As Agile development practices become more and more mainstream, some companies choose to leave their old comfortable development cycles; sometimes with fear and disdain. But nevertheless, there exists a thirst for knowledge about how things actually work in Agile environment; is it just another buzz word?

Even though you can find several books on the topic of testing and running a QA department, this is not what I want to talk about right now. Over time, people have asked me questions about the day-to-day practices and overall spirit of an Agile organization. I would like to try to answer these instead of giving another lecture of DO’s and DON’Ts.

If you are about to enter the world of Agile QA, you need to be prepared for several changes. The biggest change that you will experience is “Trust”, the major selling points of Agile development methodology; power to developers! In a truly Agile team, any member of the team feels ownership of the whole product, not just parts of it. This feeling of ownership is reenforced by allowing the individual to make decisions independently. Team of developers can say “NO” to unreasonable features, push back deadlines, and express opinions on how to make things better. This trust and power in-turn is propagated to the QA department.

Product development places the trust in testers to find the defects and help develop the highest quality software possible. Management trusts that you are competent in your profession, and adopts a “laissez-affair” attitude towards how the department is run. You are given a chance to experiment, make mistakes, and figure out exactly what works for your team and what does not.

Short iteration cycles (development cycles lasting no more then 4 weeks, at the end of which a feature is delivered) re-enforce the low risk atmosphere. These short development cycles can be as dependent or independent of each other as the team desires. This means that the team is allowed to make drastic changes to their practices from iteration to iteration. Anything from the format of the meetings to size of teams can be changed, without resistance from management.

This means a tester can be as integrated or separated from the development team as needed. Inefficient test plans can be scrapped and replaced by better ones, or dropped all together. Some projects might require you to write detailed test cases, others will let you go with no test cases at all. The choice is in your hands; and if something is not working out, you are allowed to play around until you hit the optimal level of performance AND job happiness.

But this power extends beyond the QA department. As a QA representative, you can make adjustments in the world of developers. You are allowed to attend any and all of the meetings with developers. This means you can make suggestions about broken processes, help in the estimation of the project, make adjustments to how the new builds are given to you, and sit in with any developer as they are coding! You have the ability to find bugs while the code is being written, isn’t that exciting?!

Furthermore, you are placed in a unique position of being the middleman between the Product Developers and programers. This gives you the power to align product developer’s expectations with what is possible in the real world. And you are able to make suggestions on the functionality of the product to both the programers and product developers… best part of all is that they listen and implement good suggestions!

When you have this much involvement in the development of the product, you no longer need large volumes of documentation. You are close enough to the product to know the ins and outs of every feature because you helped to develop and implement it. This is much more reliable than pages of acceptance criteria which haven’t been updated in years (let’s be honest, it happens more often then we want to admit to).

Instead of relying on the extensive documentation to write test cases, testers use “tasks” to test the product. A task is a short description of the new feature, it can be as brief or as detailed as the team chooses. Detailed task will spell out every single condition, input and output of each module in the feature thus providing you with pre-made test cases. However, some of the tasks are high level (i.e. “user should be able to register”); thus giving the developer the freedom to work through every aspect of the feature without being constrained by tiny details. Even though the tester does not have a “pre-made” test plan, in this case, he is able to influence the developer in every aspect of the feature. This not only allows the tester to find bugs based on intimate knowledge of the product, but also leaves room to fix minor things that drive everyone crazy. For those perfectionists like me, it is a dream come true!

There are many more advantages for a tester in Agile world that I would like to dive into more detail in my future posts.

-Dima