Photo credit: https://edubirdie.com/.
How to succeed when including developers in your testing approach
Developers can test. I was wrong when I wrote this some time ago, and with some additional years of experience under my wings, I now know for a fact that developers can be pretty good testers -- if they want to be and if you work with them on it.
The problem is that many (I don’t want to say most) developers don’t really want to test.
This is the real issue, and it’s hard to solve it. In the end, regardless of how much you try, you cannot force someone to do something she really doesn’t want to do.
Yes, we can force if we really need to. Mostly by asking management to apply pressure on the developers that will eventually make them test, or force them out of the company. But I do not want to talk about this today.
Let’s focus on those developers that DO want to test, and how can we effectively include them in our testing strategy and plans.
Developers’ brains are wired a bit differently
This is actually really simple and straightforward. The job required from programmers is different in approach from the job required by functional testers.
Let me explain, the job of a programmer is to take a complex requirement or feature, and to break it down into very simple and reusable functions and units.
From Complex > To Simple.
The job of a functional tester is to take a simple feature, for example, login into the system, and to look for all the complex and non-trivial cases that may be problematic around it.
From Simple > To Complex.
There are many other smaller differences, but I think this one is the most important to take into account when helping programmers to test. And what we need to work on harder if we want to train developers in the science of testing.
Testing is not Rocket Science, but we can still make it less painful for them
Let’s give our developers some credit. If they want to test they will be able to test and make the required mental switch.
Having said that, we can definitely help them make this switch faster and less painful.
Let’s review some ideas on how we can help them:
1. Pair testing
How do you teach someone to test? Why not test with them a couple of times while you explain what you are doing.The problem is that many people think pair testing is taking a test script and running it quickly next to a developer. But no, this is not Pair Testing.
Pair testing, in this case, is a training exercise where a tester (with enough experience) sits together with a programmer, and they test together one system, sharing a keyboard and mouse, while also verbalizing what they are doing as part of their testing.
The exercise usually starts with both of them defining what they want to test and achieve, reviewing the possible risks and areas they want to cover. Then they start the actual testing working together.
Usually, the tester will take the lead at the beginning, explaining out loud what she is doing and get feedback and ideas from the programmer. Then at one point, they switch places, and the programmer takes lead.
It is recommended to do Pair Testing a couple of times until the programmer is able to grasp the approach the tester is taking while working on the system under test.
2. Pre-briefing and Debriefing feedback sessions
This is also very useful when starting programmers into testing.
You cannot throw a programmer a feature to test, then point him to some test cases, and expect him to run them perfectly while finding all the major bugs in the area and reporting them correctly.
This does not happen in Nature (unless the programmer was previously a tester).
One of the things that work very well with developers (and actually with testers too) is to do short pre-briefing (or preparation) sessions to make sure that before the testing you are all aligned with the objective and the approach, and debriefing (or review) sessions after the testing is done to provide feedback on what was done and possible areas that might still need to be covered.
As I said, this may be critical with programmers, but still incredibly valuable with all levels and types of testers.
3. Adapting your testing artifacts
This one is a bit more time-consuming but still needed, especially if you are going to make your programmers a permanent part of your testing process.
The artifacts, mostly test scripts, that we use as testers may not be friendly to developers.
I believe this is mostly psychological, but in my personal experience when you give a programmer a low-level scripted test with steps and descriptions to run, they tend to feel the urge to get up and run.
Literally escape and look for other things to do.
On the other hand, again from my experience, when you provide them with checklists and heuristics (and explain how to use them correctly as part of their testing), they can do a very decent job at covering the functionality and finding the critical bugs.
And so, when you want to provide testing artifacts to programmers, it is a good idea to define them according to their needs.
4. Have ready-to-use environments & data for testing
This is another simple thing that can make a really big difference.
For a good tester it is obvious that in order to find real bugs we need to work with real data. In fact, many of the most interesting bugs will be directly linked to data in the system.
But this may not be so trivial to a programmer.
And the beauty is that today it is really simple to create complete testing environments in docker and make them easy for all the team to deploy and use them.
Just make sure to continue updating these environments whenever you get new functionality and configurations in the system.
5. Not every test can be run by every person in your team
Maybe the most important thing to remember is that not every test can be run by every person in your team.
You will have programmers who can test as good as your most capable tester, but chances are that some programmers will not be able to come up with exploratory tests on the fly to cover critical areas of the system, 30 minutes before you need to push to production.
Look for the strong and weak points of every member in your testing team (developer or not) and keep in mind that different people will be able to run different types of testing. Then adapt the tasks in your backlog accordingly.
In the end, it is a matter of Company Culture and management decisions
Everything I wrote up to now may sound very well in theory.
But in order to make it work in practice, you will need to change the culture of your team, sometimes the culture of your entire company.
The only way you will be able to achieve this is by making sure your Higher Management is aligned with this idea.
This is important because there will be times when not everyone will be aligned with this, and when you will need some with corporate muscle to play the role of the bad cop.
Having said that, as more and more teams really adopt Agile and start working within the DevOps mindset, we start seeing more programmers and managers who already understand that Quality is the responsibility of the whole organization, and Testing is a task to be shared by the complete development team.
About Joel Montvelisky
PractiTest Chief Solution Architect With over 20 years of testing experience, Joel is an expert with vast knowledge in various QA methodologies. A conference speaker, presenting in various conferences and forums world wide, among them the Star Conferences, CAST, QA&Test, and more.
Joel is also founder and Chair of the OnlineTestConf, the first 100% online testing conference. In addition he is also the co-founder of the State of Testing™ survey and report, the longest lasting worldwide testing survey.
