Did you ever felt like this “Why managers and developers want to teach me how to test?! I’m the tester. I know how to test!”. Ever wanted to
teach the cook how to cook to satisfy your taste?
The trick I’ve learned is to let stakeholders influence what I test but decide how to test it myself. However this is not so simple: to let them influence I must make testing process crystal-clear for them. And it means different things in different contexts (and you know - context changes in time).
Stakeholder assumptions about testing
Developers do unit tests, some managers love to do bug-hunting and observe UAT. They have their past experience with testers in other projects (we could only guess how positive it was) and they may assume testing is the same all the time. The stereotype is strong, no matter that we have different customer, technology, goals, team or even engineering methodology.
They all have seen some
part of an elephant .
I don’t pretend to see whole elephant. I also know only a part of it. I know it is only a part. Only together we will be able to really understand the whole picture.
Let’s discus testing with them
Michelle Davidson
counted at least 10 things software testers can be thankful for. Well, I only have one, but a complex one. I’ve made-up following sentence as a summary of what I’m thankful for: “I’m thankful for stakeholders who are ready to discuss testing in details”.
Here are some tips on what to discuss.
As a
context-driven tester I want to change how we do testing. Some stakeholders blindly trust my experience and are ready accept whatever change I suggest, well – that works, but sometimes I want anyone to challenge my ideas as I make mistakes just as anyone else does. If I would have to work with stakeholders that say – you must do as we always did testing, just because we always did it that way…. I would most probably resign.
A few mistakes I made: fit myself
Let me start with mistakes. I used to try to minimize testing effort while developing my testing methods. I missed to minimize teams’ effort. And I missed to enable team to providing useful feedback about testing.
For example, I try to avoid duplication. If I have detailed test cases, it is enough to refer test cases from “Features to test” chapter in a test plan. I’ve learned that this is wrong if I want anyone but myself to read test plan. I’ve learned the power of a chapter called “executive summary” (in a test report) which basically repeat all the information in the report but much shorter. Table of content is just another example of repeated information, isn’t it? If you have time you must describe what are you going to test twice or more – at different level of details.
Another mistake to believe they can’t extend my test coverage. Yes, I’m experienced, professional tester who knows more about test techniques than they does. But I don’t know about software internals as much as developers, about business aspects and risks as managers, about technical risks as architects. Developers and architects help me to do grey-box testing (i.e. let’s test what if we restart the service while session in progress).
One more mistake is to ignore our stakeholder concerns. Let me take an example. We once wrote a smoke test plan by listing test cases to cover features critical for continuing testing process. Developers requested us to add feature X to smoke tests. I resisted initially. I knew feature X is localized and should it fail it have no consequences on my testing process. Only a few test cases would be blocked. But developers knew that failure of X would cause unpredictable issue because most of the components are integrated with X feeding information to X.
Summing up: tips on written communications
For some reasons this blog appears to be somewhat limited to written communications. Maybe this is related to my skills: On the review meetings I sometimes appear to be the only one to asking challenging questions. But I know my best questions arose only the next day. So here are some tips for writing test documentation:
Don’t just write: think about the reader. I try to be as detailed as the reader wants it to be, and skip what they wouldn’t read (or move to appendices). I try to be quite detailed describing project specific assumptions, risks and issues and decisions I’ve made so far.
But I don’t copy-paste risks or issues that are common for our culture, company, technology used for years…
Tip from James Bach: write the most concise text you can. They (developer and especially managers) don’t want to waste their time. Managers low a few paragraphs of “executive summary”.
Write it in your own words. This may not work in certain contexts, but I generally don’t recommend using abstractions and terms. Instead of writing “Validate Authorization Negative Cases” write “will try to use feature(s) restricted by security”. You may even use first person “I will remove user X from administrator group, log in with user X and try to add/edit/delete users”.
As you document or tell some decision, describe (at least in short) your reasoning and/or alternatives if you have considered them. we will only do happy-path testing of X because it takes so much time to prepare test data
End note: seek the feedback
It is sometimes hard to adopt based on the feedback, but it is even harder to get
feedback regarding the testing I’m doing. It is not easy: managers want to control, architects to provide ideas, analysts to describe cases, developers to demonstrate functionality, peer-testers to criticize. None is actually willing to learn details of testing I’m doing. Everyone is ready to
feed, not to
feedback . I have changed my methods and am still improving them to enable more feedback.
I have discovered that even exploratory testing could be
reviewed and feedback used to improve coverage. More over because of dynamic nature of ET it is even better suited for getting feedback than scripted. No more I believe in myth that only scripted tests could be reviewed.
However I’m still not perfect in getting feedback and adopting based on feedback…
