When this Company started, there were only two developers, so they had to be generalists, able to build everything, in no time, and make the business exist.
The next hired developers were generalists too, but after four years, we found out that we needed more specialized roles, so right now:
We have a Frontend Developer, who knows a lot about building user interfaces.
We have a Systems Administrator, who knows a lot about making machines work and makes easier developer’s daily work.
And also, there is a place for a dedicated tester, and that’s me.
Our development process is simple. We think what we want to do, we build something of it, we see how it went and then we decide what to do next.
The complex part comes when we do this with many stories at the same time, so at a certain point, we are planning some features, developing another, testing what’s done and learning about how something we put to production is doing out there.
Looking at the process, these are the ways I can provide my services to dev team, product team and the rest of the company.
When we are thinking about what we want to build, I can help by:
Exploring definitions of done, making questions when assumptions are spotted.
Engaging with different users, curious about the problem we are trying to fix.
Specifying product with rich examples, asking “And what happens if…”
Exploring design trade-offs, and asking if these can be a problem for anyone.
Refining user stories, to make things clear as for many people as needed.
When the feature is being developed, I can:
Prepare test infrastructure so that when the features are ready, I’m ready to test them too.
Make sure the product will be easy to test, and suggest ways to make this happen.
Identify and explore product risk.
Minimize disruption when changing the product, asking who needs to be aware of these changes, or at least asking if we have a plan for this, or if somebody is taking care.
Remove obstacles and distractions to testing. Anything that could get in the way or slow down the testing of features.
Test while features are being coded.
At some point, the feature is Dev Done, and it’s my turn to experiment imaginatively and suspiciously (yeah, that’s the testing part) by:
Assessing whether we are done, trying to find anything that would question that we're not done. That could be any problem that threatens the value of the product, or that threatens the value of my testing, or the value of the business, or the value of the project. That´s what I want to find.
The methods vary from feature to feature, but they include:
Modelling [1] in diverse ways, explaining complex things in a simple way so we can learn, study or evaluate them.
Developing rich test data.
Testing and checking against risks.
Telling compelling bug stories.
As we deploy the feature, I can help with:
Automating the smoke suite.
Assisting the deployment driver with any exception the issues to deploy could have.
Iterating product features and investigating bugs.
This is pretty much what I do.
When you grow an agile development team, perhaps you don’t need a dedicated tester. However, we think it’s a good idea to have one!
Jokin Aspiazu.
Fellow tester at peerTransfer.
* This post was something I wanted to write time ago, but it wasn't until I saw Michael Boltons webminar "New Agile Testing Ecosystem" that I was able to produce a first draft. You can get a short version of this talk here or a longer one here.
[1] The Modelling part got us forth and back while we were reviewing the text, so finally I went and asked M.Bolton, who kindly wrote an explanation here.
