Testing is more than finding bugs. Most readers would agree with me that Testing is a multi disciplinary profession, Challenging in more than one way.
I remember once having a tester in one of my training sessions who explained to me, that she was really satisfied at the end of her working day with a huge pile of new bug reports. She was not really bothered with the follow-up and she was certainly not really aligned with goals of the organization she was working for.
An exotic example? Maybe, but I do believe that testers in general can increase their added value if they focus on their stakeholders a little more. If you want to increase your added value there are three things to keep in mind.
Design for traceability
The first tip is self-evident really. It is all about transparency and traceability. Even a medium size project has many systems, functions, interfaces that need to be tested. Just executing a lot of tests might result in great bugs being found, but that alone is not enough. If we as testers want to add value, we should be able to translate each single bug towards items that have meaning to our stakeholders. This translation should not be a tedious process that takes hours to figure it out, but we need to have an clear overview, dashboard so you like, that can be generated easily on the fly. Unfortunately many of the test projects that I see around are neither have traceability in their architecture, nor does the test department knows what the organization really wants.
Align with stakeholders needs
Testing is a risk based activity. Sure, but recent research learned that only 50 of the testers actually do RBT. For the other 50%, the ones that do RBT, risks might seem a nice translation of the customer needs. But, risks do not tell the whole story.
We should not forget that many decisions are not based upon rational arguments, but are in fact fear driven by Project Managers and stakeholders who aim for success, comfort and a feeling of being in control. Conversely, loss, pain and fear are strong negative drivers that determine our behavior to a great extent. We cannot neglect them. How do these key players act when they are pushed outside their comfort zone and the fear of failure becomes tangible?
If we really understand what drives our Project Manager and stakeholders we can design our tests in such a way that is provides them the comfort and takes away their fears. Luckily testing is a discipline that provides us with many tools to do so. With these tools we can improve our tests, and do better test reporting. Good test reporting requires good data and an understandable message. The first is created by having a good traceability. The second is achieved by telling a good tester story.
Tell a good testers story
Recently I coached a colleague of mine who was about to present the results of his test project to the senior management. His first impulse was to announce the number of executed tests, bugs found, etc. It took him some time to translate this data into useful information.
The useful information is of course strongly related to the comfort needs of the stakeholders and it tells a story. The story explains what you and your team did, the problems you had to overcome and the solutions you found. The story also justifies the effort taken, it clearly explains how this aligns with the needs of the organization and the benefits gained from the results. Important lesson learned is that a story is nice to listen to and it’s personal. You need to back up what you are saying by solid arguments, but should not blur your message by putting in too much details.
Combining these three elements will help you designing better tests, putting a focus on the right areas and make your efforts better understood. Doing these will make the difference between being one of those people in the office who cost money or one of those who matters.
—————————————-
Profile
Derk-Jan de Grood works for Valori as product manager and well known speaker at conferences. He is specialized in getting more out of testing by focusing on the value chain and business-it alignment. Recently he published a book in which he describes the human side of IT and explains how testing can help to increase comfort and grip for our Project Managers and stakeholders. This book is supported by a full day training that enables you to get commitment for your test activities, contribution to the project success and become the wing partner of your project manager.
©Derk-Jan de Grood
Derk-Jan,
At first glance this is a well written piece of sound advice that will help many testers. At second glance I have some concerns with your use of the terms “stakeholder”, “risk” and “fear”.
Stakeholders hold a stake in the product. They are not our stakeholders; they are the software’s stakeholders.
Among the stakeholders of a piece of software are all the people involved in the project that is making the software and all the people who will work with the software once it is released. The first category includes the project manager and the tester, but they are temporary stakeholders. Once the project is finished they move on. The people who will work with the software, hopefully for a long time, have bigger stakes in the software.
Fear is the anticipation of pain and as such it is a very useful emotion. We use it all the time in testing and call it “risk”. Risk or fear can and should not be taken away by testers. We should expose risks so that the other stakeholders can deal with them. Panic should be avoided, but fear is nothing to be afraid of.
Hierarchically we serve the project manager and we do so by telling him our truth and not by telling him what he wants to hear. In doing so we serve the most important stakeholders, the people that will have to work with the product.
I totally agree with your conclusion that a tester’s value is equal to the value of the story he tells. Michael Bolton calls this “test framing”. According to Bolton a tester’s story contains three elements: the quality of the product, the testing that was done and the quality of this testing. These three elements can be used in a simple bug report or in a presentation for decision makers.
So, indeed, testing is not all about finding bugs. It is also about not finding bugs and telling about what we did to look for bugs. Like it or not, we are in the bug hunting business. Everything else is telling stories and confirming that all is well.
Dear Bert,
Thanks for your comment. I do agree with you. You make nice additions as well that helps to make the message stronger.
One addition from my side.
You write: “Hierarchically we serve the project manager and we do so by telling him our truth and not by telling him what he wants to hear.”
I agree we should not compromise our story because it is bad news. But there is an underlying assumption that “uncertainty” is worse than “bad news”.
Among the product-stakeholders and our project manager there is often fear that the product will not satisfy their needs on certain aspects. The testers job is to “investigate” this and come up with a answer. In this case the fear is reduced by providing information about that concern. “Yes, you do have a problem and measures need to be taken”, or “we think you are save on this one”. But whatever the message, it is regarded as valuable because it aligns with information need of the stakeholder(s)