The book Provocative Therapy has had a big impact on my life as a tester and a consultant. Also I want to discuss the Tester’s Role in Modern Software Development and the current vogue for Quality Coaches (that might be a bit provocative)
TLDR; Provocative Therapy is a great study area. And Quality Coaches might not be the best cure for what ails your modern software development process.
Provocative Therapy
-
Find the book on [amazon.uk] [amazon.com]
-
What is provocative therapy?
-
The Goals of provocative therapy
-
Humour in provocative therapy
-
How to use provocative therapy as a consultant
Tester’s Role in Modern Software Development
- What is the tester’s role in modern software development?
- Why are people confused about a Tester’s role on Agile?
- Why is Agile Testing Hard?
- Why will Quality Coaching help?
- What does a tester really do?
- What makes a good tester different from other people on an Agile team?
- What are the dangers with Test Coaches?
- How do we define our own role on Agile Projects?
- What does a tester do on Agile Projects?
- Can programmer’s test their own code?
Tester’s Role
- if testers are confused about their role, why would we expect anyone else to understand it?
- roles come with expectations
- expect programmers to program better than other people on the team
- expect managers to manage better than other people on the team
- expect analysts to analyse better than other people on the team
- expect testers to test better than other people on the team
- if testers are not doing that, we could
- assume that testers are not needed
- assume that other people are testing
- assume that testers are not good enough
- assume that something is stopping the testers doing that on this team and this process
- or something else
- conduct experiments etc.
Tester’s role is to find opportunities to test that other people don’t see.
A good tester takes advantage of those opportunities better than other people.
Because… skills, experience, attitude, etc.
Agile has not really changed the tester’s role.
It has offered a new system within which we have to work. So we work differently. So the ’trappings’, the externally observable parts of what we do have changed.
Internally:
- we look for opportunities to test - risk, functional coverage, system flows, whatever.
- We take full advantage of those opportunities - exploration, tooling, technical knowledge, testing knowledge, making notes on what we do.
- We communicate the results of having taken those opportunities.
- We learn from those opportunties to generate more opportunities to test.
Agile. Small team. TDD (mostly). Stories. Some pairing. 2 week sprints. Go. I had to create my role.
I had to improve my programming so that I could pair on TDD. That was good for me. I think it helped writing code.
But we weren’t very good at estimating so we couldn’t pair, and cover all the stuff we said we were going to do.
But we didn’t fix that.
Instead, I changed my role. So that I could hunt down risks and issues as we were building the software. Tested as we went through. Flagged up issues.
In planning, the stories weren’t very good. I pointed out ambiguities, asked for clarification, asked:
- “how will we know?”
- “What if?”
- “When?”
- “can you give me an example?”
- “does that imply?”
I wrote code to help automate the execution of the application so we could use that during our development process to assert on conditions and I could use to boost my testing.
You could generalise that into “On Agile A Tester… blah blah”. I’d rather look at what I did and what led me to doing it. Because I can then do something different on a different project.
I think a tester has a very fluid role on an Agile project and that is why we find it difficult.
Therefore we have to own the role. And we can only do that within the capabilities that we have. And the opportunities that we see.
I think because of the confusion, and because programmers are now doing more testing.
And they are doing testing.
They might not be identifying all the opportunities for testing that a tester can identify. But that’s what a tester is for.
But we have the system dynamic issues that.
Sometimes.
If you have testers and programmers on the team. Then programmers do less testing. Even they can see opportunities for the testing, and can take advantage of those opportunities perfectly well. Because testers are there, the testing falls on them. And then you have the usual:
- not enough time for testing (because fewer testers than programmers, trying to cover the work of all the programmers)
- testers just do basic stuff, don’t need testers to do that (because only have time to cover the basics, which the programmers could test)
Testers very often are not using their skill sets effectively within that environment and so their value is obscured.
The temptation then is to get rid of testers. and Create Quality Coaches or Testing Coaches or Test Mentors, or Internal Test Consultants, or SWAT Teams, or whatever.
Basically - take the testers out of the team and make them some sort of advisory capacity.
We change the dynamic on the team such that the programmers then take responsibility for the most obvious testing.
There will still be gaps because they won’t see all the opportunities for testing.
So we will have these advisors work with the teams to fill the gaps.
Sounds great.
Devil’s advocate question time - why do we need a new role to do that?
- why didn’t you just do that before, and then have the tester on the team fill in the gaps?
- What prevented the tester from filling in the gaps before and the programmers doing most of the testing?
- What makes you think this will work better?
As an experiment it might be worth trying, but I think people are jumping to a solution to a problem that they created but don’t realise what the problem was and might cahnge the system dynamic to one that does not support this new role.
I’m not against this role, because I’m a consultant, I perform a very similar role.
Question then what is a coach vs a mentor vs a consultant?
When would you use one and not the other?
I get nervous when we take words that have dictionary definitions and then use them differently, and we seem to do that with ‘coach’ ‘mentor’ and ‘consultant;
Dictionary:
- coach - “an instructor or trainer”
- mentor - “an experienced and trusted adviser”
- consultant - “a person who provides expert advice professionally.”
I’ll generalise and say that we now have a mixed set of attributes that this role might have:
- experience
- ability to ask questions
- to trigger action
- to model the actual process
- ability to suggest solutions, experiments
- ability to sublty lead people into taking action
- ability to bring people together
- etc. the list goes on and it is a long list
This is a challenging role. So are the ‘coaches’ you are creating:
- getting the training they need?
- are you treating them homogonously, even though they all have very different skill sets?
- danger is you just want ‘coaching’ skills, rather than the skills they have developed years of experience with
The coaching, mentoring, consulting role, is hard.
I caution you, if you can’t get small teams with people with specific skillsets working effectively together, I’m not convinced that creating a coaching role and moving the people who currently perform a testing role into that role is going to save you.
I’m concerned that we might be setting people up to fail. And fail spectacularly.
Think about it carefully. Train your programmers to test. Train the coaches in how to train, coach, mentor and consult.
I think its actually a harder path.
There is no generic solution.
- Some people will make great coaches.
- Some people will be able to fit into a team and craft a role that adds value.
Recognize that people are individuals and create teams of individuals that work together where their unique skills can blend and all can add value.
As an individual. Identify what your skills sets are. What you are good at. What makes you different. And if you are not working as an individual on your team. If you are working as a generic cog doing a generic role, then stop, because you are not adding your value. Do that. And regardless of what happens, you’ll be able to make the most of it.
It puts the responsibility back on each one of us as individuals to do the best we can.
Books Shown or Mentioned
- Provocative Therapy by Frank Farrelly and Jeff Brandsma
Find the book on [amazon.uk] [amazon.com]
- Dear Evil Tester by Alan Richardson
Find the book on [amazon.uk] [amazon.com]
