There is one simple and straightforward practice that I have seen helping testers and teams all the time, but in most organisations it is something that is not used at all.
Debriefing your testing.
Debriefings should be simple and quick
In principle and in practice debriefings are easy implement, they do not take a lot of time and require close to no efforts.
The main steps of testing debriefings are:
- Make sure you are done with your testing task, or at least with a complete section of what you want to test.
- You (as the tester) choose one or two people who can provide feedback on what you just tested. Usually it make sense to call the person or people who were part of the definition and development of the functionality, and you may also want to add another tester with some experience in testing this area or similar aspects of the product.
- Go over the stuff that you intended to test originally, what you tested in practice. Remember to cover what you did not test, as well as what you added along the way and why.
Go over what you found during your testing.
If you came up with questions or concerns they should also raise them at this time.
- The other participants ask questions and provide feedback on the things that you tested, with the objective of thinking about additional aspects or angles that should be tested before setting this task as done.
- If there are additional things to test, make a quick list of them and go back to reviewing them in the system.
Debriefings are not retrospectives! They are not certification processes. They do not require hours of preparation or commitment.
Some of the best debriefings usually are over before your coffee gets cold (and always before you manage to finish your cup).
What’s the issue with debriefings?
Us, of course!!!
We do not like getting feedback, because we hate being told about things we did wrong or did not understand in the first place.
It is even worst when you think you are done with something, and then you realise that you forgot to do something important and now you need to go back to complete your task.
I am not calling you a smart-ass / unprofessional / unreliable tester, please don’t misinterpret me.
I am calling you a human being, and most of us humans are flawed by our own egos. I am pretty sure it has something to do with evolution and natural selection, but it is not very useful today.
We need to make sure people realize that debriefings are not here to harm them. They should help us ensure we do our jobs right.
But how to achieve this?
Some ideas to make debriefings work and stick
Point 1 – Teach by example: if you are a senior tester, start by making it a religious practice to perform debriefings in your testing tasks. Invite other testers to give you feedback and approach the hole process in a positive light.
Point 2 – Show the benefits to all: during your team meetings bring up the experiences you had with your debriefings. Show the ways they showed areas that were not covered originally, and found important issues during the second pass over the feature.
Point 3 – Make it part of the formal process: yes, in the end it comes down to making them a formal step. Hopefully it will show value soon enough so that people will want to do them, but a small push is needed to get started.
Point 4 – Pay special attention at the way the feedback is given during the actual meetings: One of the biggest issues with feedback sessions is that the person asking for feedback is putting him or her self in a vulnerable position.
Even without meaning to do so, others may provide the feedback in ways that make the tester feel unprofessional or unreliable.
It is really important to create an “open feedback atmosphere” during these sessions so that people look forward to them, instead of being demoralised by the fact they need to perform them.
Point 5 – Ask your team how they can make them work better for them: What I wrote up to now refers to things that worked for me and in my experience, but every team is different. It is smart and even imperative to ask your team to make debriefing sessions work for them in their way.
What about test briefings before the testing operation starts?
I will leave that for another time, but once you have mastered feedback sessions after the testing is done, you can experiment with similar sessions before you start your testing.
The biggest surprise about these meetings is that they are great for finding bugs in the code even before you start your actual testing, but I will leave that for another post.
Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.
Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.
With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.