Have you ever been on a situation where you need to test 10 things but you have only the time for 6 of them, and on the other hand you look at your development team and 2 programmers are done with all their important tasks and started working on stuff that sits under the “nice-to-have” list (or even worst, they went to the game room to “test the Wii“)? What do you do?
The answer will depend on how you have prepared your team and your testing infrastructure to delegate part of the testing task, in other words on how have you EMPOWERED your developers to be testers when needed.
But developers can’t test!!!
I know programmers are not ideal testers, I even wrote about it in the past. But when the alternative is that the features will go out untested or that to run a sanity test on all the features you will risk not running critical tests on more important parts of the system you may be willing to compromise.
The important thing then becomes how well have you built your testing infrastructure and how have you prepared your programmers so that they can lend a helping hand when needed.
It’s like teaching a dog how to fly
You cannot teach a dog how to fly, but you can train him to jump far enough. In the same way you cannot train a developer to become a star tester, but you can give him the ability to go over the system and find the “critical bugs”.
How do you do it? It’s not rocket science, although if it was it might actually be easier for them to understand it! Start by describing what you do when you approach a testing task.
I usually do 2 main things with my developers when I prepare them to test:
1. Explain about testing principles. How to look at the application from a user’s perspective and disregard as much as possible the internal architecture. I explain to them about building end-to-end workflows, about working with user profiles, thinking in terms of negative scenarios, and using extreme and wrong inputs in order to find for bugs.
I find this can be easily done by gathering them in a conference room and doing a quick presentation that will show them the different techniques and examples of the type of bugs they can expect to find with them.
2. Run Pair-Testing sessions. When I want to help a programmer understand how I think when I test I invite him to do a 30 to 90 minutes pair testing session. During this time I grab the mouse and explain to him how I think and what am I looking for as I test a part of the system. About half way through the session I switch places with him and ask him to “test out loud” so that I can help him and give him ideas and guidance.
These 2 activities help my programmers to embark on testing tasks with enough self confidence in order to take ownership on testing tasks.
Preparing the grounds
Another facilitating factor to empower your programmers to test is how ready your infrastructure is to support and guide them as they test. Is you test plan and your test-ware ready to be used by other people?
It is easier to go and tell a programmer to go and test Feature-X if you also provide him with some sanity tests and/or checklists that will guide him through the main parts of the process. For this you need to write these tests or checklists ahead of time.
Personally I don’t think you need to create extremely documented steps, but it will certainly help if they have the main business scenarios available and they can go over the basic coverage of your application in a structured way. Just make sure to explain to them that these scenarios are only a guiding path and the most important bugs will usually be found on the areas that are “on the sides” of the way and not necessarily along it (this is something that is easier explained as part of the pair testing walkthrough).
Another important aspect that is not always trivial is whether you have enough testing environments to accommodate all your new testers? Do you have enough licenses to test your external integrations? Are your systems configured, up and running?
If you are not prepared to “host new testers” sometimes it may take even more time to set up these environments than what you can save by getting the extra help, so better be prepared ahead of time.
Lastly, how will your “new testers” document and report their tests so that you can review them after they are done? It may sound trivial but you want to make sure you can go over what they tested, review their work and provide feedback on additional stuff they may want to test “based on your professional experience”.
If you have a test management system (like PractiTest ) it may help, but if you don’t you can use text documents or even hand-writen notes. The important thing is that you can go over what they’ve done, understand what was achieved, and provide feedback if necessary.
In short, make sure your infrastructure is in place to incorporate more testers on-the-fly.
Understanding what to delegate and to who?
An additional point to review on this subject is related to understanding what parts of your testing tasks you can delegate and which ones are simply out of you “new testers” reach? What is complex and what isn’t? Where are the highest risk? etc. As much as you want to relay on your programmers they simply don’t have the experience and in some cases the mind-set to test complex stuff and find all the issues in there, so better make your risk assessment correctly.
Also, you need to check who is going to be testing what feature or area of the system, for example you cannot give a feature to the same developer who wrote it (and you can check some of the reasons why on this article I mentioned before).
Learning to work with compromises
In the end it is a game of trade-offs, preparations and compromises.
It’s always nice to know you can call on additional resources when you need them, but understand they will be able to help you only in limited ways. Also understand that in order for this to work you need to prepare the infrastructure ahead of time and have “trained testers” who will be able to step to plate and help you out when you need them.