Get rid of your dedicated Testers, your SDETs, your dedicated Test engineers, and your dedicated testing teams. Because you (probably) don’t need them.
When you go ahead and shut down those teams some people will say you’re mad, but others will pat you on the back and say “Excellent! Good decision.” That will make you feel good and we all want to feel good.
”Why would you do that?”
What problem are you trying to solve by removing the dedicated team or person? If you have individual members of your technology team whose focus is one thing, who form a key function in your process, then they are quite possibly a constraint. If nothing gets deployed until it’s been through the tester (the gatekeeper), then you can’t move at pace. Reducing handoffs will reduce lead time and cycle time, and you will move faster.
I’m NOT saying “don’t test stuff”
I’m saying make testing and quality part of what you do. Do it all the time and don’t make it a separate step. I’m saying don’t have a role dedicated to testing the output of a second (or first) person.
When an individual is solely responsible for testing and quality you have made it a separate step, and in doing so are supporting a culture that’s about shifting responsibility and accountability, with an “it’s not my job” ethos. Having a dedicated testing team or tester is a comfort blanket, but you can’t run in a blanket.
Disclaimer: Without a doubt there are industries with critical life and death systems that believe they need a secondary dedicated testing facility for their software. It could also be that they could do things another way. This post is not aimed at those specific cases. But it’s still worth looking at where and how you test.
Responsibility, ownership and accountability
If you have a team (or an individual) dedicated to testing the software development output of another team (or individual), you are denying your developers the responsibility, ownership and accountability for their work. And there’s a lot of value in giving people responsibility.
“You mean expect and trust the developers to be responsible and do the right thing?”
Yes. Design a system that encourages accountability and address issues when and if problems arise. Don’t stifle the opportunity to take that responsibility by avoiding it.
Developers need to be explicitly given ownership and responsibility for code they write from the moment they think about it until well after it’s in production. When it’s in production, it’s theirs. When it’s giving problems, it’s theirs. When it’s generating great results, plaudits, or just smoothing the road with elegance and grace, it’s theirs. When you do this, you will find fewer bugs in production, more issues resolved early, and overall, an increase in the deployment of production code. You will also find that sense of ownership encourages pride and when people are proud of stuff they tend to try to make it bullet-proof.
Everyone is responsible for quality. It’s never ‘someone else’s problem’ because if it’s someone else’s problem, you’ve got a bigger problem.
Test Tennis - Pressure, attitude and blame
Have you ever heard of Test Tennis? It’s a fun sport whose participants are skilled at deflecting the stress of deadlines through the (possibly/probably inadvertent) serving of features to a dedicated tester who will serve back with a list of faults, thus buying time. Depending on fear-level, pressure and hopelessness, this game can continue for quite a while.
This also highlights other issues like a lack of acceptance of the uncertainty inherent in software development. It’s incredibly hard to accurately estimate how long a feature will take to develop at the beginning of the process, so you shouldn’t be trying to perfect the meeting of those kind of delivery deadlines.
If, as part of this game of test tennis, a bug gets through the testing team (because it’s their responsibility to catch it, not the developers), then you end up with a bug in production.
In the real world
If I do some technical work for a client, I don’t hand it to a dedicated testing team, I test it myself because a) I am responsible, b) I am accountable and c) I own it. If I don’t test stuff and it’s wrong, my reputation goes through the floor and I end up with no clients.
If my car needs a part or a repair, I take it to my local garage. The mechanic who works on my car doesn’t have a dedicated test team. She tests it herself because a) she is responsible, b) she is accountable and c) she owns the problem. If something significant, but avoidable, goes wrong after the repair/addition and I crash my car as a result, her reputation goes through the floor and she’s on a criminal negligence charge.
I own a property in the middle of nowhere. It has no piped gas supply, no mains water or sewage. Sometimes I need to mess with the water supply (switch boreholes or rainwater reserves). I don’t have an in-house testing team, but I test everything myself as I go along, because a) I am responsible, b) I am accountable and c) I own it. If I don’t test and things go wrong when I have guests staying, my reputation goes through the floor and before long I have no more friends.
I could go on…
”But testing software is a different skill!”
There are lots of ‘different skills’ in life. If a developer is not good at testing then they just need to learn to get better at it. Analysis and problem solving are two of the cornerstone skills for a good software developer. And, that’s another plus, your development team should get better at what they do and their skill level should improve through the removal of your dedicated testing resource.
I don’t buy the argument that testers are a different sort of person. The kind of analysis whereby ‘types’ of people are best suited to certain ‘types’ of jobs is, in general, bogus - It might be appropriate to make an analysis and decision based on ‘type’ when a person is significantly impaired in some way, but even then, it’s pretty bogus. Every individual brings something different to a task/role. No one is born a ‘this’ or a ‘that’. And everyone is different.
“A tester will discover bugs a developer won’t spot.” Sure! But forget the role ‘tester’ because person A will find something person B will miss. That’s why it’s not one person’s responsibility. I’ll say it again: We are all responsible for quality. It’s certainly true that some people will find problems others won’t but that’s why you are going to start to build acceptance tests before you write your code and why you also pair program.
What should you do to fill the gap?
Although it feels destructive and risky, shutting down your dedicated testing resource is aimed at improving things and smoothing the flow. Of course there’s more you need to do. Nothing works in isolation.
Acceptance tests in the form of behaviours and use. And be test driven! You need a product owner. The product owner, along with the developers, needs to write acceptance tests, and to make it easy, those acceptance tests should probably be written using a framework that encourages automation: I like Gherkin and Cucumber, but there are other alternatives. Acceptance tests should follow the sad as well as the happy path. When you involve developers in the process of writing acceptance tests, or reviewing them, you end up with a greater understanding of the problem and early insight into potential gotchas.
Write tests that focus on behaviour and use, not on units of code. I’m not suggesting you don’t do unit tests. If they are the right thing to do, do them!
Make everything small and merge with master all the time. Continuously integrate your code. The smaller your commit, the lower the risk. Don’t eat the elephant in one go. If you aren’t going to write it all in one go, why would you want to wait to test it all in one go?
Test continuously. Like everything else, don’t make this a step.
Be aware of the risks. Bring the risks to the forefront, make sure you understand them. Make sure you’ve identified as many as you can and, if possible, turn them into tests.
Eyeball the end result. Look at what you’ve done. Try out the feature, play with it, mess with it and try to break it. Don’t be caught out by the obvious.
Canary release. Use canary releasing to test features with a limited set of users. Nothing beats real-world use to test features.
Make testing part of the development flow, not a distinct step. There shouldn’t be formal handover.
Measure failure and examine it. Track MTTF (mean time to failure) and MTTR (mean time to recovery) and conduct post mortems on significant issues. Use all of this information to get better at what you do.
Pair program. If you have effective pairing in place you will also get a reduction in bugs and issues because you’re working with a second brain and second set of eyes.
This is not an exhaustive list or a 10-step guide to removing test-teams. You need to work out what works for you and how to implement the necessary changes.
I’ll say it again…
Get rid of your dedicated testers, your ‘Software Development Engineers in Test’ and your Test engineers.
Don’t fire them, constructively dismiss them, or ‘terminate’ them. Don’t get rid of the person, just get rid of the role.
Make testers redundant within your organisation and find them something else to do. You’ve obviously hired smart, technically-able people, with a propensity for problem solving, tenacity and focus. That sounds like a set of skills perfect for software development. Getting rid of ‘x’ software tester roles could give you ‘x’ more software developers!
If they don’t want to become software developers, there will always be plenty of other places where testers are wanted. Just not in your organisation.
There. I’ve said it. Actually, not only have I said it, I’ve done it too. No one died, the defect rate didn’t rise in any attributable way and the world didn’t end. It certainly encouraged a higher level of ownership, made it a lot easier for us to get to a happy world of continuous deployment, removed a constraint and, I believe, improved the flow.
And things got better.