How Agile Makes Testing Harder... And Easier

Raise your hand if you remember the days of waterfall life cycles.  Anyone?  Anyone?  Ahh, they were a different time, weren't they?  First Product would talk a lot about what they wanted.  Then Development would fight a lot about what they couldn't do.  Then they would do it, and QA would wait until the whole package dropped and everyone would start seeing where all the holes were.  But there would be several cycles, and the QA team had strong respect.  It was during waterfall cycles that I truly learned the meaning of the term "The Buck Stops Here."  QA is the last stand, and they have to sign off on the project. Three months of blood and sweat and coffee and coke cans and late nights, and finally, a product is ready to release.

But the testing process was a lot like this comic of the Ikea Job Interview.  Its like Dev would say: "Here is the product, we finished making it, now put it all together." and they kind of hoped it would all fit.

And then came Agile, and the whole philosophy changed.  I mean Product and Dev still fight it out, and the design phases are sometimes very good, but now we have "T-Shirt Sizing" and other fun metaphors that sounds like fun (I stress the "sound like" part).  When agile came along instead of having to put together a large product from all its little pieces, instead we are given an arm, and we have to make sure it works.  Then we are given the back, and see that it works.  Then the other leg.  And so on, until the whole chair is given to us and we have to assemble it.  But what inevitability happens is that QA can't test at the same time a feature is developed.  We have to wait for it to arrive.  So we write test cases, and then we update them, and then we rush to test it before the sprint is over, cause we want to move on to the next sprint.  And then they want to release, and at some point its hard to catch your breath and make sure the product has all the pieces put together.  What we are left with are many new tests that hopefully most of them were run, a bunch of components that may or may not be ready for integration and we have to get ready to start planning the next sprint. 

Agile life-cycles are better for development, no question about it.  But testing is harder because there's a constant race to keep up with the speed of development, and what happens is that some pieces don't get the proper focus they require - unless the company has the ability to slow down its development to ensure the quality is there.

So how do we make sure we keep the quality up while we maintain the integrity of agile?  I will continue to discuss this in further posts.  But for now, let's look at some of the risks that QA has to face in an agile world.

• The quality will be at risk if development did bad planning, and QA will have to work with an insufficient space of time.
• Be careful not to pressure testers to finish too quickly.  All too often I saw the dev teams run too long on their features, and QA had to either rush to finish their tests in a careless manner or rollover into the next sprint unnecessarily.  
• In a constant release business, where releases are every X sprints, or X weeks, integration takes a serious hit, and QA wont be able to fully test the product before each release.
• Test Cases are at risk of being weaker in agile if there's not enough time to fully form and review them.
• And finally, test case learning and test adequacy will be at risk for future strength in agile.

Again, in a future post I will suggest solutions to all of these, but for now, I'd like to point out places in which QA is at risk in a development cycle.  

Now that we've tortured or at least agitated agile enthusiasts enough, its also important to point out that testing in smaller pieces and smaller frames has some very strong advantages to it.  QA should be trained to drill down and keep focus on the components when testing.  Once the components are approved, the whole machine will be stronger.  Much like making a Voltron.

What do you think?  Where does Agile testing create weak links in testing cycles?  Add your comments below.