With the rise in popularity of agile development, professionals from the Quality Assurance or software testing world are finding themselves on agile teams. Customers are becoming more conscious of how they spend money on the software they rely on, and as such are starting to demand that dedicated software testers or Quality Assurance teams be involved with development.
Professionals who work in software testing bring a special set of skills to a project. These are people who are thinking about testing all the time, and they work on projects on behalf of the development team as well as on behalf of the customer. They can help the team have more confidence in the product they have developed, and help the customer have more confidence in the product that has been delivered. Some customers realize the importance of testing, and often demand that testing professionals be on agile projects. Some developers also value these skills, and want to work with people to learn more about testing. How does a conventional tester use these skills to add value in a new and unique project environment?
What is Agile anyway?
I hear this quite often: “Our development shop is pretty chaotic, and doesn’t do much documentation. I guess we’re agile, right?” Wrong. “Agile” does not mean “undisciplined” and “no documentation”. Agile development refers to a group of very disciplined methodologies that share similar characteristics. Agile processes tend to be part of an iterative lifecycle, rely on rapid feedback, and believe that software development cannot be predictive, but must be adaptive. Many practitioners and methodology founders came out of chaotic or waterfall methodologies. They figured out what had worked for them and others, and published their findings.
Agilists tend to believe that it’s pretty much impossible to have all the information up front, so have developed systems that cope with uncertainty, and rely on evolutionary designs. The Agile Manifesto has some good descriptions of overall agile values. The Agile Alliance has some great information to look into to find out more.
But if the developers are testing now, won’t I be out of a job?
Nope. Not necessarily. In my experience, I’ve yet to see a project where I and other conventional testers didn’t find important bugs. This includes agile projects. The difference is that on an agile project, we find the important bugs faster. We are more involved with testing throughout development. Now that the developers are doing rigorous work themselves with solid automated unit tests, the products I test are much more robust. This gives me more time to focus on important testing tasks instead of dealing with lots of broken builds and unreliable software at the beginning of a testing phase.
It’s also important to realize that developer testing such as Test-Driven Development can be very different from the kind of testing that conventional testers are used to doing. Testers don’t tend to unit test the production code. Some testing experts (notably Cem Kaner and Brian Marick) describe TDD as “example driven development”. It can be viewed as design work with examples written to evolve a program until it meets requirements. The automated unit tests then provide a safety net for refactoring. If the tests fail when new code is integrated, they are fixed immediately. Chronic broken builds, hours of debugging and a lot of time-consuming troubleshooting are eliminated or greatly reduced this way.
Conventional testing and agile testing are complementary tasks. One does not necessarily replace the other. I was recently the testing lead on a project that was using Scrum with some elements of XP. I had a couple of conventional testers working with me, doing manual testing (especially exploratory testing), automation at several layers in the application with Open Source testing tools, and working with the customer. The customer was doing acceptance tests, the developers were doing unit tests, and the developers and testers were working together on load testing. One day, the Project Manager asked me if he could get involved with testing during some of his spare cycles. A few days later, the Business Analyst asked the same thing. For several weeks, at any given time 95% of the project team were testing. It didn’t put anyone out of job – each person had something unique to add. In fact, the conventional testers were able to do much more testing in this environment than in others I have seen.
“OK” says the conventional tester, “I’m convinced. Where do I start?”
As a software tester, it is important to not get too caught up in “the right development methodology”. After all, it isn’t the process that is important to the end user, it’s the product. We need to be open-minded to different methods of delivering the right product on time with a reasonable level of quality.
In agile methods, the values behind the development methodology are important to understand. We’ll look at values in the next post.