Mark Levison has over twenty years experience in the IT industry, working as a developer, manager, technical lead, architect, and consultant. He discovered Agile in 2001 and is now a Certified Scrum Trainer and Agile Coach with Agile Pain Relief Consulting.
Levison has introduced Scrum, Lean and other Agile methods to a number of organizations and coaches from executive level to the individual developer and tester. Levison is also an Agile editor at InfoQ and has written dozens of articles on Agile topics and publishes a blog – Notes from a Tool User. Mark’s training benefits from his study and writing on the neuroscience of learning: Learning Best Approaches for Your Brain. To contact Mark Levison, please email him at mark@agilepainrelief.com.
Offshore testing teams are put between a rock and a hard place. By their very nature what they’re being asked to do isn’t Agile, at best it’s better waterfall. When work is offshored with an Agile team it would be better to have the whole team (developers, testers, ….) in one place.
Much of the magic that happens with Agile Software development comes from building quality into the code and not trying to test in after the fact. In addition, team members start to cross skill with developers learning more about testing and testers pairing with developers to complete feature work.
Much of that is beyond the control of the readers of this magazine. I won’t tell you to abandon ship or change jobs. I do suggest it’s important to have a good understanding on how this can work so you know what to advocate for. In the future, I think we will see more distributed Agile work and done well. I’m already starting to see teams at some clients with parts of the team in Canada and other parts in India. It works because everybody is working in the same body of code in the same sprint.
Testing is placed at the back of the bus but should instead be an integral part of the process. In addition, the Indians make a real effort to provide an environment where the people are well paid and want to stay with the business, reducing turnover.
1. Specific to testing, how important is it to have a process? Does testing only follow the development process?
In Agile/Scrum there isn’t a specific testing process, instead testing is part of every Sprint. The key here is to make sure that test occurs in parallel with development using techniques like Acceptance Test Driven Development (ATDD). Well done testing is really just an ongoing form of requirements elaboration.
2. Concerning “process” on testing projects, would you share with us some common mistakes & lessons learned?
As you see from the above note the most common mistake is to put testers on a separate team and try to test after the fact. The longer we wait between writing a bug/misunderstood feature, the harder it will be to fix. So efforts should first be put into the avoiding the bugs in the first place (writing tests first i.e. ATDD) and then finding bugs within minutes/hours of being written.
3. Do you see a big difference in process from in-house tested projects and outsource tested projects?
As I note above the difference isn’t so much between in-house vs. outsourcing as moving from having a combined team to separate teams working a sprint or more later. Assuming you’re working in the same cycle, there is still the additional overhead with the reduced communications bandwidth.
4. These days, in 2011, do teams commonly use or follow a formal process guideline, like TMM/TMMi or CMM/CMMi or TPI?
It seems not many companies actually use these. I’ve not seen any of these in use but that’s probably because my clients call me in to help transition them to Agile/Scrum.
5. Many companies call themselves Agile but have done nothing more than shorten the release cycles into sprints, cut documentation and thrown out process. When teams badly implement Agile, how can test teams work to implement team process improvement?
That is rapidly becoming one of the bigger problems in the Agile world, where companies think they know Agile but really its an excuse for cowboy coding. The key in this situation is to use the retrospective to ask questions. Questions that help focus on the underlying problem and not the individuals involved.
6. Sprint retrospectives have become a core practice in the Agile/Scrum world, could you share with us some retrospective techniques to make them most effective?
There are entire books devoted to Retrospectives: Agile Retrospectives: Making Good Teams Great. See also: Agile/Scrum Retrospectives–Tips and Tricks and Agile Retrospectives.
7. We know you are running some Agile testing UK user groups, could you share with us some realistic “best practices” in Agile testing process?
I’m unsure what you mean by realistic, that suggests a limitation I’m not aware of in the abilities of your team members. I’ve already listed the key areas for improvement when I mentioned development teams including testing, making testing part of the development process and ATDD. As for the “Best Practice” there are none, just good practices in the current context. (There are no Best Practices)
8. Test Measurement/metrics are often used in post-mortem meetings or for process improvement. Agile projects typically have much less measurement. How can we show or justify a need for process improvement with few or no metrics?
Agile Metrics are a difficult problem. There is really only one thing that matters, the high quality business value that we successfully put into use rapidly. That implies many things: bug free, rapid deployment (every 2-4 weeks is a good starting point). Focusing on anything else number of bugs, number of test cases, and percentage of code covered by tests will lead to behaviors that optimize for the measure not the delivery of business value. For more see: Agile Metrics and What is a Good Agile Metric?
9. Sometimes on traditional projects, test teams get a bad reputation for complaining because we are often under the harshest schedule pressure. Do you think this has changed on agile projects? Are our ”complaints” now heard as suggestions for improvement?
The key here is to use the retrospective as a conduit for issues, don’t focus on your problems. Focus on the effect on the customers. Instead of complaining “We were delivered very buggy code on Wednesday of last week” try “We spent alot of time dealing with unexpected problems on Wednesday of last week”. Change the focus from specific people to the problem and then ask your team mates to help solve the problem. Remember the goal is for the whole team to succeed in delivering a high quality application to the customer. We succeed in doing that as a team not as individuals.
In the next few weeks I will take some time to write more about the Testing on an Agile team, the item will appear on my blog.
