One of my current interests is to do with communication between testers and non-testers.
I recently heard some gems from non-testers, but there's always two sides to the story...
Assumption #1: "It's a known problem!"
Admittedly, I think I've probably said this in the past. However, my "rose-tinted memory" remembers me putting this into some context - it was in this situation, or it's known by X in your team.
But that's the problem with assumptions, it's such an easy trap, an easy place to fall over. So after a while an assumption is almost a known starting point - "oh, we've seen that so many times by now everybody must know about that."
But this is a great illusion. Just because one or two people have seen this (maybe they're in some fault report triage group) doesn't mean that everyone else has seen it.
When I dug into this particular "known problem", it was hidden in a email and referenced in an old report - neither were discoverable. So I make the distinction between a problem that is "known to some group of people" and a problem that "is discoverable by everyone".
If I now use the term "known problem" then I'm careful to attach which group of people I think it's known to. If I don't attach such a group (or context) then I assume it's discoverable...
Assumption #2: Troubleshooting - Best when the designer and tester are working side-by-side
The implication here was that they should be located near each other, that not talking face-to-face would not work.
I think this is a bias problem - either someone has experienced "one" way in which this can work. Alternatively, they've seen problems when not communicating face-to-face and assume that's the reason.
It takes maybe one or two additional routines when working remotely from a partner, but there's no reason why it can't happen.
I remember one time being located on a customer site 9 time zones from the designer that was helping me troubleshoot. We sorted our routines and structure out - we optimized the short time we were able to talk each day and the pieces fell into place. So I have no reason to think that it can't work - sure, it's more difficult, but certainly not impossible.
Assumption #3: Troubleshooting - Best when the designer can drive the activity (ie do the test) themselves
This assumption "seems" to take the view that the tester is a robot, that the feedback is exactly what the designer requests.
Maybe some testers work like this but the majority that are worth their salt or want to learn are constantly adding to the equation - making the some of the two (designer + tester) greater than the individual parts!
This assumption may be another bias problem - maybe a bad example that stuck in someone's head.
Overcoming this type of bias is a bit tricker - especially when acting as a third party. It's usually up to the tester to build their brand, but I'm still working on how to approach this problem as a third party!
If you've any assumptions that you've heard recently then drop a comment...
Remember: Assumption is the mother of all fudge-ups! (or something like that!)
No comments:
Post a Comment