- This topic has 11 replies, 11 voices, and was last updated 2 years, 5 months ago by
.
-
Posts
-
As part of our Learning to Test Series, we are exploring communication in the testing environment. One that all testers will have knowledge on is how to talk to testers. As a tester how would you recommend for developers, clients and even management to communicate with you . Are there things that as a tester you are commonly asked to do but are not part of your remit? Or are there even things you wish others would ask you more often.
What are your experiences?
To paraphrase a classic JFK quote:
Don’t treat testers as second-class citizens! We’re not “just” testers; don’t assume we’re all failed developers; don’t patronisingly assume that we aren’t techincally-minded. This also means that we shouldn’t be a dumping-ground for tasks which are deemed to mundane for your developers.
Help us to understand what you want us to do. Speak plainly – ask the question that you want answered, don’t disguise it behind other questions. I once lost a tester for a week because my manager had asked him to build an intranet page which showed the current pass/fail status of our automated tests. Because that’s what they’d been asked to do, that’s what they diligently did. However, what my manager actually wanted was quicker news about failing tests; we could’ve achieved this in seconds by adding them to our build system’s existing email notification list! (Then there’s the question of why he felt it necessary to know about failing tests; what did he plan to do with this information? That was never made clear.)
Don’t view testing as a bottleneck for your project, or view testers as the gatekeeper for your release. Quality is a team responsibility. Although it’s inevitable that there’ll be a certain amount of checks to be done against your final release candidate, that doesn’t mean you’re “waiting for the testers to finish”. Don’t use phrases like “we’re done, apart from the testing”. (You wouldn’t say “we’re done, apart from the coding” after you’ve written a spec!)
Testers do not naturally cause problems. They reveal problems.
Recognise that testing can never be exhaustive, so questions like “When will you be finished” are the wrong questions to ask. I’ve found that it’s better to focus on uncovering risk and generating information which can guide a release decision.
Also use these better questions to guide your recruitment. Given the infinite possibilities of testing, if you ask a test team whether they could utilise more people, they’ll inevitably say “yes”! – but look first at whether the current team could work better, and ask them what they’d do with more people, and whether another tester will actually bring more value to what you’re doing.
Foster relationships between your developers and testers, to encourage cross-communication and prevent silos. If everyone feels that they are acting as a single team entity, they’ll be more naturally inclined to collaborate, which can lead to better testability (testers encouraging developers to add hooks and harnesses to assist with their test effort) and a more natural flow of bugs (testers aren’t afraid that developers will shout at them for finding problems).
Thanks for inviting me to the conversation, Ronan!
As a tester in a development team at the administration of a small university I would like to air a few thoughts. First some inside the team aspects:
- Our team is small enough to fit in a (large) car, but still we have some communication issues between us. Why?
- Team members have special skills that are not always shared. Out of modesty?
- News and current development in the software development world around us is rarely discussed. Are we sitting on an island totally cut off?
Solutions to improve the inner works of the team: talk more to eachother about what’s on your plate and how it’s going. Open up the dialogue when you see signs of frustration. Try to share news and do it with an idea of who’s listening.
Well, on the the aspect of how to deal with testers from a managers’ or clients’ perspective. As a tester I would like to improve a couple of things in the contacts
- Write clear titles and headlines for specs, please, think tabloid press and you’re close!
- Write user stories that are understandable and testable. Please fill in: As a X I’d like to be able to H, etc. thank you!
- Answering to requests for additional information when needed. Now answering drive costs along with me-nuts!
With regards / Johani Karonen, University of Skövde, Sweden
@johani Thanks for your thoughts. It is very interesting that even small teams have issues with communicating sometimes.
I find your suggestions on how to improve dealing with testers insightful. Do managers/clients really not bother with titles and headlines?
@neil I caught your view and I agree that testers are same-level specialists as others (e.g. developers), but I think that there was no suggestion that they’re not. Ronan wanted to get to know out thoughts about tips at work, how testers do, how to communicate in a team etc 🙂
Testers are people, as different and alike as everyone else. More curious perhaps,.. but really what is typical tester behavior is a stereotype. I’d rather have diversity.. as I wrote about here: https://jlottosen.wordpress.com/2015/09/06/most-of-all-people-who-knows-that-things-can-be-done-in-many-ways/
anyways. .. It depends
Don’t treat testers as second-class citizens! We’re not “just” testers; don’t assume we’re all failed developers; don’t patronisingly assume that we aren’t techincally-minded. This also means that we shouldn’t be a dumping-ground for tasks which are deemed to mundane for your developers.
Though now very people think of testers in that way. I liked the quote 🙂
I believe when a developer communicates with a tester, he should have one thing in mind – we are all part of the same team whose main and only objective is to deliver the product with highest quality.
it seems very interesting. forpc
Thanks for sharing this information, Apps for PC
- You must be logged in to reply to this topic.