The normal reaction I get when I tell someone outside the industry that I work in software testing is, “isn’t that really boring?”. Well, it certainly would be if software testing involved what most people think it is, however, the industry has moved on and so has the role of a tester.

When most people think about software testing, things like specifications, test cases, verification, logging bugs etc. spring to mind.  Now clearly these are facets of testing, however, that isn’t where a tester really shines. Traditional approaches to software development involve compartmentalising the development process, often with separate teams working on say, requirements, development, testing, deployment, support and so on. I have worked in many of these roles during my career, however, one thing stood out, it rarely went smoothly!

So what was the problem? When you break the development process up, you start introducing communication barriers, for example, the stakeholder with the requirement and the team building the solution may never come into contact with each other, and communication is only through documentation. This can quickly lead to slow feedback cycles, miscommunication, poor assumptions and misinterpretations. Additionally, this approach can often foster a blame culture, where as long as a given team has covered themselves, what happens further down the chain isn’t seen as there problem.

So how do we make sure we are “building the right product, and then building it right…” – Essentially to me, this is what a good software tester does.

Over the last decade or so, many software development companies have moved towards agile development methodologies, at the foundation of any agile technique is what is known as the three pillars “transparency, inspection and adaptation”. Typically any agile development technique aims to achieve a cross-functional, self-organising team, capable of delivering a given set of features within a given cycle of time. Now there are lots of approaches to achieving this, and this isn’t the place to discuss them. However let’s take Scrum as it a popular approach and one I have worked with.

So essentially the idea of scrum is, it is a set of meetings (ceremonies) and roles (product owner, scrum master and development team) which help foster better communication and reduce feedback latency. Now scrum itself is not a silver bullet – it is purely a framework to ensure stakeholders and the development team are communicating, and that the team is constantly learning how to deliver features better by achieving transparency, inspecting frequently, and adapting based on the information learnt. It is important to understand in the context of Scrum the development team is essentially everyone involved in delivering an iteration e.g. it is not just coders, it could be UI/UX experts, testings, graphic designers etc.

So how does a tester fit into this? Well firstly in an agile world testing is now longer a phase, it is a continuous process. Testers are no longer just verifying functionality against a specification, they are involved right from the beginning of the process, for example helping to define acceptance criteria and really understanding the business value behind a feature way before any code has been written. But why does a tester need to know this, I hear you ask? For me, it comes back to “building the right product, and then building it right…”  – the true value of a tester is not just verifying a feature has been built right, but does the feature actually deliver the business value the stakeholders wants? In order to do this, the tester really has to understand the value of the feature and the users who will be using it.

A testers role really involves understanding the users, being able to assume their persona and exploring a feature in the context of a solution, yes a tester will still be involved in verifying functionality, however wherever possible this is automated. The true value of a tester is the human element which no automation tool can replicate. A key technique a tester will use to achieve this is what is known as exploratory testing, which is a self-perpetuating learning based approach to explore a solution. Essentially you are observing and inspecting as you go along with your direction steered by the analysis of your findings. So I appreciate to some, this might sound like chaos, however there are a number of techniques which testers use to help focus their testing, for example, time boxing exploration, using charters (explore X with Y to discover Z) or touring guides (using metaphors to chaining features in the context of a role or persona).

What I really enjoy about agile development is, it is a collaborative process. No one person can be an expert across the entire solution, however through collaboration and context-based learning, complex problems can be tackled. A tester’s role involves working across the delivery process, with the walls between stakeholders, development, operations, support and testers being broken down. Agile development has evolved from just Dev + Test working together too much more, for example, you will often hear about DevOps now which is next natural evolution of agile development and is essentially Dev + Test + Operations, but really it doesn’t stop there – the idea is we are trying to bake quality into the whole process through working cohesively, collaboratively and continually inspecting and adapting to find a process that works even better than before, whilst developing valuable quality, features as quickly as possible.

Hopefully, this has given you an insight into what I do, and maybe even persuaded you that there is more to a tester than executing test cases : )

I always enjoying hearing from fellow testers, or if you have got questions or feedback, please get in touch.