It’s been 10 years since the Agile Manifesto was crafted, yet development teams can still struggle with an Agile transition. In this interview, SSQ contributor Lisa Crispin talks with her co-author, Janet Gregory, about Agile test.
SSQ: You’ve been working with teams transitioning to Agile development for well over 10 years. These days, do you find that the transition is any easier for testers? Or do the same issues come up?
Janet Gregory: I am amazed that questions testers had 10 years ago still exist today when they are new to Agile. I guess the biggest difference is there is now literature that I can reference and share with them. We have learned so much since I first started out on an Agile team. Not only has the language changed to use phrases like ATDD (Acceptance Test Driven Development) or the Agile Testing Quadrants, but we have found new and better ways for testers to be involved up front in the definition of the requirements.
SSQ: Programmers on Agile teams were “test-obsessed” 10 years ago, but they were focused on unit and functional testing. Today, do programmers understand other aspects of testing, such as exploratory testing, better? Do they embrace having testers on their teams?
Gregory: One of the biggest resisters for testers 10 years ago was that very problem-- the focus on unit and functional testing. One of the biggest questions I was asked by testers back then was, “What about all the other kinds of testing?” They meant the Quadrant 4 (technology facing tests that critique the product) tests from the Agile Testing Quadrant model that Brian Marick defined back in 2003. Ten years ago, that model didn’t exist and very few people in the Agile world knew where that type of testing fit.
Now pretty much all the books recognize the need for test automation of functional tests, the importance of exploratory tests to find the issues that we didn’t think about up front, and the need for tests like security, performance, reliability, interoperability, compatibility, etc. I think part of the reason is the scale and nature of the products we are building now. Agile had its start in small projects where teams could control a lot of their environment. Now we see larger organizations using Agile, so the importance of the Q4 tests has increased.
SSQ: In your opinion, what is the number one skill that the average tester on an Agile team should learn?
Gregory: I’m not sure I can name only one, but I’ll try. In our Agile testing course, one of the themes throughout, is collaboration. We ask testers on Agile teams to be involved with the customer/product owner role to help get early clarification on the requirements and get acceptance tests defined. We ask them to collaborate with the programmers to give them story tests in an automated manner to promote ATDD. We ask them to collaborate with the programmers and customers to get feedback early. And then we ask them to put on their “critique” hat and think outside the box and explore looking for new ways to break the product or give feedback for new stories.
I couldn’t do it -- I have to give you two very essential skills: critical thinking and the ability to collaborate. We need both as testers on Agile teams. Of course, that doesn’t mean there isn’t a long list of other necessary skills.
SSQ: As a coach and consultant, what skills have you needed to learn in the past year?
Gregory: There are so many skills I have had to add to my tool box. I find I spend a lot of time of time reading and practicing new coaching skills. I’ve also gone back to some basics such as coding some automation tests. I like to keep my fingers in the pie, so to speak, to keep those skills sharp. I also work hard at improving my writing skills for articles and my blog.
One of the newest things skills I am working on, with the help of Ellen Gottesdiener, is understanding more about how business analysts work.
SSQ: Do the teams you work with tend to have the same problems around testing, or does each one have their own unique set of issues to overcome?
Gregory: I find that each team has different problems. So much depends on how the organization has developed over time, and how projects have adopted Agile. For example, if it is a mature product line and the project teams have been following a traditional methodology with a separate test team, there are many cultural issues that the teams have to overcome in addition to the Agile training.
Sometimes the tools being used are an obstacle in themselves because they don’t lend themselves to collaboration between programmers and testers. If the testers have never used automation, they have a huge learning curve, first helping the team choosing the tools and then understanding how to use them.
When I go into an organization, I look at the system as a whole to see what the real problems are. I like to start with retrospectives to get an understanding of what the team members think. The real issues almost always surface, and often it is not related to the testers. For example, a couple of reasons testers can’t keep up within an iteration, might be because the stories are too big or they aren’t testable. We need to look at the whole picture.