Can Developers test? I guess we’ve all been asking this question for a long long time.
Back in the long passed Waterfall days the answer to this question was simple. We would ask “Can developers test?” and the answer would have been “WHO CARES?” Since the people who had the job and responsibility to test were the testers (well, this was true in almost all cases, but let’s not get into this now)
But, fast forward to the days of agile and devops, and now the question is very relevant. “Can developers test?” I truly hope so since for many teams today it is simply impossible to assign all testing tasks only to testers and expect to release the product on time and with the desired levels of quality.
And so, the important or maybe the interesting question now is “How can we help our developers to test and to test better?”
So let’s start reviewing this, but maybe let’s start by understanding if all our assumptions are correct.
Is it mandatory in all teams that developers test? Or can we still have teams where testing is the exclusive responsibility of testers?
It is not a law that software can only be released if developers are part of the testing process. And there are still many teams where developers will not run any test that is not defined as unit test (and somewhere even this doesn’t happen!).
But we are seeing more and more teams that either have only a handful of testers and way to many developers, making it impossible for a tester to even try to perform all the tests needed before releasing the product to production or shipping it to customers.
So, it is not mandatory, but it is becoming more and more of a necessity.
Why do you think devs cannot test?
- Lack of motivation
How to teach / train them?
- Pair testing
- Constant feedback
- Light scripts / checklist
Is testing in production related to this?
Yes and no, this is a topic for one or even two episodes in itself. But what is true is that once you get developers to wear their testing hats you will start looking at many additional things coming out of them. Stuff like more instrumentation for automation and monitoring (both of them linked to Testing in Production), as well as improvements to the process to review user stories, more bugs being fixed, additional empathy with the rest of the team, etc.
I think it is the old idea of walking a mile in someone else’s shoes as a way to identify more with their pains and needs.
What if they do not want to test?
You can’t force them. But their management can.
They need to understand it is their responsibility
What are testing coaches?
This is a term that is becoming more and more popular, we may need to do a whole episode on it, but in a nutshell the coach will train and then advise the team on how to test correctly the stories or features.
In a sense, this is what we’ve known all our lives as test architects… but with a fancier name 🙂