In the last few weeks I have not taken the time to follow-up on the series I started some weeks ago. In the meantime Lisa Crispin had an entry on ten principles for Agile testers as described by Jeff Langr and Tim Ottinger. Since I took some of the principles from Lisa and Janet, you will find these as well on my list as well – though I recommend buying the book anyways.
- Respond to Change
Responding to change is critical in most software businesses. Customer requirements keep changing. Therefore the most valueable needs to be able to cope with that change as well. As a tester it is therefore counter-productive to act as a gatekepper with a conservative view towards change. Bach, Kaner and Pettichord were the first I read this about, though the underlying thinking clearly is not new. As testers we need to be able to respond to changes demanded be the business as well as changes demanded by technical constraints such as the programming language of the system under test or test automation tools. Insights from Refactoring and Design Principles such as the SOLID principles from Robert Martin are tools of knowledge that can help to adapt tests to the chaning business. As pointed out by Robert Martin
Knowledge of the principles and patterns gives you the justification to decide when and where to apply them. If you don’t know them, your decisions are much more arbitrary.
This applies to developers as well as to software testers.
- Self-Organize
Without self-organization testing becomes a tedious task. If your work is organized from someone else, your testing tasks become a job of a assembly-line worker and you could be replaced by the next student looking for a job. This might seem a hard statement and I’m exaggerating to some degree, but if a tester does not organize herself, then why not replace her with a cheaper student? As highly educated professionals we have to take care to do a good job and defend our position on what is to be done in order to work on the project at hand. This may mean to write a big test plan up-front, this may mean to find the proper amount of automated and exploratory tests or this may mean to bring together business people, developers and testers in order to improve communications. Of course our decisions are sometimes wrong on these items. In that case we need to be human enough to learn from our failures in this case in order to improve.
Probably the most common violence of self-organization lies in the fact, that most testers are waiting for something to be delivered to them. Even ten years after defining test-driven development and the Agile movement this is the case. Robert Martin raised the point of Never be blocked during his talk on Craftsmanship and Ethics from the JAOO Conference. The need to wait for something to be delivered means that you’re blocked. Prevent these situations by finding ways to work together with your developer. Maybe you will find that there is a vast amount of unit tests for your particular business rule and these are regularly run. Maybe you can improve the code before it gets to you. You need self-organization to see these opportunities and decide whether to take the next story or improve the software at the instance it is written.
- Focus on People
Regularly testers on traditional style projects complain about getting source code just thrown over the wall. While agile methodologies focus on the whole team participating in testing, the more general principle behind this is the focus on people. Testers not getting out of their cubicles in order to talk to developers, management and stakeholders cannot expect to get involved early in the development cycle. Did you ever try to talk to your lead designer before firing that blocking bug into the bug tracking system? When did you ask your customer about that edge case left out during specification gathering the last time? By letting the people around you on the project decide what to do in the situation at hand, you might be invited to the specifcation workshop the next time. Matt Heusser described this moment as How to be a first-class citizen as tester. Just when you have the intuition that something is broken and can show this to your stakeholders, you’re going to get invited to the elephants’ meetings afterwards – maybe. Focussing on people is the more general principle behind this and may get you on the road to the first-class citizen in your company.
- Enjoy
Based on my previous work experiences – not just in the software world – enjoyment matters most. An unhappy tester that just gets flooded by over-the-wall-thrown code is unlikely to deliver back value to the project. If the testers are filled with pride in their work, they will even enjoy their work and become an essential part of the project team. Some weeks ago I took a voluntary session with Michael Bolton. Michael had selected an exercise from his courses on Rapid Software Testing. We had timeframed our session previously to one hour, but ended up at 1.5 to 2 hours. We overdraw the session, but I did not feel to comply about it. I experienced so much enjoyment during the session, that I wanted to share this experience with my peers immediately. One week later I did. And they felt the same. While enjoyment cannot be mandated by a manager or corporation lead, if you’re in the situation to enjoy your work, your giving it a better care – which improves your enjoyment as well. Enjoyment prevents us from taken the next job opportunity, from becoming a developer, etc. Taking in the joy into our work helps to have pride in it. You shouldn’t live without it.
- Testing moves the project forward
Some months ago Cem Kaner wrote a rather long chain of replies on the Software Testing group on an article by Lisa Crispin and Janet Gregory that reminded me on this principle in Lessons Learned in Software Testing. One of the key points that Agile methodologies showed us is that tests really drive the development effort forward.
Test-driven development is more considered a design technique as a testing technique. Similarly Gojko Adzic redefined Agile Acceptance Tests as Executable Requirements in his book Bridging the Communication Gap. Both practices have somehow their roots back about 50 years in time, as I got to know by a blog entry from Jerry Weinberg. They all three have in common that these techniques have been motivated initially by testing needs. These are examples where testing moved the software development process forward and the same holds for each project as well.
- Testing is not a phase
In order to take proper effect, testing needs to be a continuous action. When testing is handled in a phase after the fact – after the software has been built- then all the made up assumptions during the earlier phases – like requirements, concept, design and code – sum up into one single point: the tester behind the wall. Have you ever wondered, how come you’re testers need so much more time than you to code? Fred Brooks wrote in The Mythical Man-Month that just a tiny piece of the time spent in a project is taking for actually writing the code. Requirements, concepts and designs give developers a good starting point on the business terms in the project. In order for testers to do their job well they also need to have this knowledge right from the start. By just giving them the code and the 500 pages of documentation, you’re not only treatening them as lessers, but also making their time spent on projects a hard deal.
On the other hand quality in software is not built, as James Bach lately pointed out. All practices during the development of the software need to ensure that the quality in it is kept alive. Testers and testing in general cannot bring back a dead body of quality in your product, if it’s decomposing there for months already.
- Everybody tests not just the designated testers
After the last principle this should be obvious. The whole team is responsible for having the product tested. Every code review, Pair Programming session, Iteration Demo, Specification Workshop etc. enables the whole team to participate in testing the product. Since everyone on a deveopment knows a tiny of the software, getting everything together in form of an executable specification of the product enables the team to deliver business value from the start. If everybody is part of the testing that’s happening, the Broken Windows Effect is minimised and bugs don’t start to pile up.
- Reduce feedback latency
Feedback is a core value in nearly all Agile methodlogies. Recently Robert Martin gave a key talk on Craftsmanship and Ethics where he pointed this out while referring to unit tests and code coverage.
Have ever looked on a function you implemented two hours ago and thought: “Oh my god, what’s this doing?”
Feedback latency is essential for testing. Just quick feedback on a broken build, damaged customer value and technical debt gives you the opportunity to learn from it. If two weeks of development passed by, you’re most likely to have lost the red line in the code. This is why feedback needs to provided immediately.
- Tests represent expectations
When dealing with Specification Workshops or in Acceptance Test-driven development the team defines together with the customer representative how the system should behave after the agreed on functionality is implemented. Test frameworks as FitNesse or Concordion shorten the gap between these examples or expectations and the tests used in order to drive your development forward. By being able to directly use the output from your requirements, you’re able to product the right code. Similarly unit tests focus more on producing the code in the right manner. Therefore they reflect more the design expectation in your development efforts. It should be obvious that you cannot live without one or the other.
- Tested is part of “Done”
A feature or story is just defined as being done, when it’s really tested. The feature is not production-ready when the developer has finished the coding for it. Instead it is finished when everything is in place to get the tests passing, the acceptance from the customer in the iteration demo and thereby the production ready configuration of the parts. Everything else is scaffolding and should be avoided completely. Particularly does scaffolding in the software business lead to higher maintenance costs for features that had not brought in any money. Just tested, production-ready software enables your company to earn money from your work.
Considering different your daily work, the motivation for team members will also change. Instead of sub-optimizing towards “but I’m finished” mentality, definining “Done” as “Tested” enables developers to look over their wall and see if the brick they just throw did any hurt. By moving the measurement on level up from “coded” to “tested”, there is call for all team members to focus on just this bit rather than sub-optimizing just their building lot. The project and the team is not finished with a particular piece of functionality, if the customer cannot use it – period. This is reflected in this principle.
