The Ultimate Tester: Value Creation

Once upon a time, when project managers still thought that building software was a completely manageable and predictable activity, and testers were put in a seperate team to ensure independence, the result was shitty software and frustrated people. Even though the rise of the agile way of working has improved some aspects of software development, the journey will never end. We still have a lot of work to do. Creating good software starts with the people making it, the team. As an agile tester, a tester 3.0 if you will, you are a frontrunner of this paradigm change. 

No longer do you have to sit in a seperate team, crunching requirements to make test scripts that you then manually execute, pretending to be a human computer (how silly is that!). No longer do you have to fake your belief in a Master Test Plan that your test manager urges you to honour. No longer do you have to put your defects in a defect management tool, and then wait for a couple of releases for your findings to be solved.

It is time to take matters in your own hands. It is time to start creating value from the start.

Before we discuss what this ‘value’ is, lets make clear what it isn’t. Adding value from the start in an agile context means: not writing a detailed test plan, not making a huge risk assessment up front. The beauty of agile is in keeping things small and open for change. The value lies in creating working software and to try to eliminate waste.

Before Coding / Building the Right Thing

Why not start by exploring the requirements you find in User Stories or Use Cases? Try to make them as clear and concise as possible, so you have a shared understanding in your team. If you then write down your requirements as test cases (that you can automate), you have created value in more than one way: you have shortened the feedback loop, created testcases that the developers can work with and you have hopefully weeded out a couple of unclear requirements in the process. This way of working is not new, but very rarely is it executed properly, so it is wise to invest time in learning to get better at this. Want to improve yourself in this area of expertise? Read Dan North’s take on BDD and this blog post with an example on how to work with Behaviour Driven Development. Also, the book Specification by Example is a great way to increase your knowledge about this topic. 

However, having perfect requirements won’t get you very far if they aren’t helping the product forward. Say you’re working on a mobile app and the Product Owner wants a new feature built in a way that is not using native components of the Operating System, would you not say anything? Being proactive means speaking up when you think, based on expertise and facts, that another solution would be better. You can do that by asking a very simple question: ‘why?’ Using techniques like the 5 Why’s  or the Socratic method are excellent ways to uncover an underlying problem. 

Another common problem with agile teams is that they focus completely on the implementation details and forget what they are doing it for. As a tester, your position in the team is perfect to involve yourself in technical decisions and programming, but also to help the Product Owner with the overarching goal. You are able to put yourself in their shoes and see things from a business perspective. When you increase your knowledge of planning techniques like Impact Mapping, you can really help the business create an awesome product. You can do all this before any coding happens, with the overarching goal to ‘build the right thing’ and to achieve the business goal.

Example of an Impact Map

After coding / measuring 

Of course, achieving the business goal is not completely possible up front. In the end, you need to build, test and measure the success of your software. So don’t forget the value of metrics! In a lot of cases, measuring how many users you have, how they are using your product, where they come from and how much money they spend, are very helpful metrics to determine how successful the product is. From a test perspective, it is also wise to measure if the software crashes, or if the user sees errors. Analytics are very important these days, and you can use many of them to improve your understanding of the user (helpful for testing with persona’s) and to improve the way you test (A/B testing, for example). If you want to learn more about metrics, the book The Lean Startup focusses on the ‘why. The ‘how’ is beyond the scope of this blog and is very contextual. My advice is: be very careful with metrics, because you probably know the saying “There are lies, damned lies and statistics!”.  

To conclude, testers no longer need to wait until coding is complete before they can add value. The role of the tester has changed drastically in the last few years and it can feel a bit daunting; so many things to learn! I hope this blog post has given you a few ideas on where you can improve your skills in this area. Please share your ideas about how testers create value.

In the next blog post we will discuss the unique curiosity that testers possess and how we use that for critical thinking about the product and exploratory testing. Hope to see you back here next time!