At the Agile Testing Days Anko Tijman presented about mitigating Agile Testing Pitfalls. Here is my write-up from his session.

Anko started his presentation by stating that critical issues in agile testing are customer involvement, testing as a team, the test strategy, requirements and tools that aid with testing. He draw his view on testing in Agile, that involves teamwork, feedback, flexibility, and simplicity which self-influence themselves in a symbiotic manner. In a traditional project these values also help, but on a more traditional project these are seen as optional. Anko continued saying that on a Scrum team you get customer involvement right from the front, and is also helping with testing over the course of the iteration.

Anko presented five pitfalls. The first in this set is not testing with the customer. This is sometimes problematic since getting the customer’s buy-in for testing and acceptance tests is hard. The customers currently just have the view that they are just involved in the end, when the product is finished. This leads to problems with acceptance tests as well as acceptance criteria. During demos you also don’t get the feedback what you should build next. you can mitigate this risk by building a relationship, building trust, don’t rush through the demo or getting the acceptance criteria.

The second pitfall Anko presented was not testing as a team. On teams there is usually a lack of unit testing. The teams also have to realize that they got the responsibility of collective ownership of the quality of the product [though the ProductOwner may be responsible to others – MG]. Big bang integrations as well as testing on a too high level counter-act testing as a team as well. Finally a lack of knowledge about the state of the product is another driving dimension. He explained that they put up the essentials of their Testen 2.0 book on reference cards in order to share knowledge not only with your testers, but with the whole team. This yields a collaborative definition of done, as well as tackling risks. Working software in the end is knowledge sharing. The Definition of Done should be done by a multi-disciplinary team. He told a story of a team, which was over-pressured by the demand for automation that they were overloaded. They consciously decided to lower the quality criteria in their definition of done so be able to keep up with the work load.

Anko’s third pitfall is an unbalanced test strategy. Teams focus too much on unit tests or acceptance tests, and postpone test activities to the next phase. One iteration is not enough to build a test strategy. The problem with postponing tests leads to a lack of feedback. The Definition of Done should define your test strategy, but be able to grow over time. You can mitigate an unbalanced test strategy by sharing knowledge, putting things on a wiki or using share point. Also thinking in risks what to tackle as part of your strategy is a vital mitigator.

The fourth pitfall Anko presented is that requirements are too vague or even ambiguous. Controversy too many details may also hinder the problem solving process and lead to suboptimal results. Overcoming this pitfall, collaboration is necessary. Ask! Meet! Discuss! Even with the customer. Acceptance test-driven development can help with this, and there are more test techniques that can help you. The product is the solution, practices may help you to get there. He added that you should do all of this at the customer demonstration. Anko not only saw customers seeing the product, but testing the product, providing the feedback to the team how he uses it.

The fifth pitfall from Anko are tools. He said there are too slow or even too fast tools. There are tools that do not deliver any value to the team, or are not supporting the practices of the team. He mentioned that tools can overcome pitfalls, but tools are not always the answer to your problems. Mitigating the pitfalls from tools you should decide as a team which tools to use and which don’t. In addition you should make obstacles visible.

Anko summarized the bigger picture. The factors that make testing successful on Agile projects are to build strong relationships since software development is about people. This includes team members as well as the customer. Focussing on team work and collaboration makes Agile teams succeed. This includes commitment from the team and seeing the larger picture of the product. Sharing knowledge also helps in empowering the team. He stated that when we trained our football teams like we train our IT teams, we would get a situation where the front-players were not talking to the mid-field players, mid-field would not talk to defense, and so on. This would yield pretty much a dysfunctional team.