Today let’s talk about Derision, another topic in the
Mock Turtle’s “new maths” education.
While we all hope we never have to deal with colleagues or
co-workers who are intentionally trying to undermine, insult, or sabotage your
efforts as a member of a testing team,
or “have it in for you”, such situations do unfortunately exist. Our
recommendation in those situations is to have a frank talk with your manager,
and if this fails, to get out. Fast. The longer you stay in a situation where a
coworker is actively planning to discredit you, the longer they have to
potentially taint not only your own self-confidence, but also the opinions of
others. We’ll deal more with the topic of active hostility under Uglification.
In the world of software testing, one is far more likely to
encounter the more subtle, sometimes unintentional or unconscious problems of
Derision. To start with, testers are coming from a perspective where their job
is to find places where software may be broken, inconsistent, confusing, or just
potentially improvable. This inherent
approach of “looking for fault” starts us off at a disadvantage. Much of our
language can easily be phrased in negative terms. Take these two defect summaries of a user
interface fault:
#1 – Subscriber information frame is poorly aligned and looks sloppy
#2 – Subscriber information frame alignment does not match standards
Summary #1 uses subjective language and imprecise adjectives
“poorly” and “sloppy”. It is always
better when possible to remove any emotionally laden words from communications,
including defect summaries and descriptions, using objective comparisons to
established requirements and standards instead of words that sound like
personal judgements.
But what if you don’t HAVE a requirement or standard, and as
a tester you are using your experience to suggest improvements in your product
that will increase acceptance, clarity, and usability? It is possible to handle
these “suggestions” in a few different ways. If your defect management system
allows suggestions or enhancement requests to be shared with product
stakeholders, that’s of course the easiest way. Or, you could have an informal
conversation with development or product, provided you have a relationship that
will allow you to express opinions AND a timetable that will allow such
opinions to be entertained. Often a project is so time-crunched that anything
that isn’t strictly defined in requirements has to fall to a later
release. This leads us to another possible
source of Derision.
A tester can get so focused on the Rightness of their own
bugs that they refuse to be reasonable about limitations which may be in place
for a given effort. In any development life cycle, there may be time built in
for iterative small improvements to a product’s user interface. Or there may
simply be no time available for development to code anything beyond a very
basic presentation, due to complexity of the integrations. If a tester cannot
compromise on the superficial aspects of the product in order to make deadline,
it could be argued that this doesn’t help the company reach their goals. On the
other hand, if the product is absolutely solid and there are no other bugs to
find beyond the minor, improvement-level defects, it could be argued that
fixing these defects will take the product that one step farther to delight
customers. This behavior could earn the
tester the reputation of being “detail oriented”, or it could earn them the
reputation of being “nit-picky” or “irrelevant” or “distracting” or even
“lazy”.
The hope is that the tester will not focus on improving
their numbers by submitting many small defects while ignoring work that could
uncover large defects. A good rule of thumb is “One high severity defect equals three
medium severity defects or nine low severity defects”. Accordingly, the tester
probably ought to spend only one-ninth of his or her time actively hunting in
areas that will yield low severity defects. Doing otherwise (unless specifically tasked) will lead others to question your priorities. We'll talk more on this subject under Distraction.
You’ll almost never hear direct feedback from developers to
testers on the presentation and tone of your defects. You might hear feedback
on content – and if you do, you should absolutely provide whatever detail the
developer needs in order to help him or her understand the nature of the issue.
It might take step by step screenshots, or even a live walkthrough together.
The developer however does have a responsibility to initially attempt to reproduce the
issue given the verbal directions you provide, which should be complete with
ALL pieces of information they need. A developer should not have to look up
login and password information for a particular user role, for example, nor
should they have to refer to an uncommented video playback or unannotated
screenshot document to try to determine what the issue is. As per standard,
your defects should always compare the expected result to the actual result.
Failure to provide clear, complete defect detail will decrease development
confidence in your abilities and affect your reputation as a test resource.
If you’re one of “those testers”, or even if you’re not, you
can bet that your professional skills (including the way you write up defects!) may be the subject of commentary or
conversation among people you work with. Gossip and venting is common to EVERY
workplace. It’s important to remember that as cathartic and human as it is to
vent your frustrations about people, there are always consequences to doing so,
more so if you vent or gossip with the wrong people.
- Never gossip or vent about coworkers to their manager or yours. Even if you have a personal relationship with either, you cannot ask a manager “not to listen” to comments about their staff. They must take them seriously on some level, and you cannot undo what you have said.
- If you must vent or share a story, choose a single confidant for your incident. Sharing with more than one person becomes news and not a one-way, one-time episode.
- Avoid gossip or venting with the person who has the best stories about everyone. You’ll only add to his or her collection.
- Should you be the recipient of venting or gossip, just listen and sympathize, and take it no further. By no means, however, should you allow the discussion to continue if the conversation begins to make you uncomfortable, or if the comments would constitute racist, harassing, or discriminatory speech in a public forum. Such complaints may be necessary to share with management if they continue. Do not allow yourself to be complicit in a prohibited behavior.
Finally, I’d like to touch on some tips to avoid Derision in
your conversations and communications.
- Use inclusive language to share wins, and use personal language for fails
- Use “we” for referring to team accomplishments and goals – share the credit
- Use “I” for referring to questions or mistakes – don’t share blame
- Avoid “gaslighting” – use open-ended questions with positive language
- Right – “I observed behavior x when I tested item y – did you see the same result?” “What were your observations when you tested item y?” “Tell me your thoughts about this result – what do you think?” “Did we receive this result in last build?”
- Wrong – “Didn’t you test item y?” “Isn’t this the test case you failed? It worked for me.” “Don’t you think this is wrong?” “Don’t you remember seeing this result in previous builds?”
- If you must offer criticism, try a “Criticism sandwich”
- State appreciation for something the person is doing right
- Explain the behavior that the person could improve
- Offer specific ways they might improve this thing
- Express empathy for their feelings and response to the situation, and your willingness to provide appropriate support if requested
- Always remember to criticize concrete behaviors - not intangible personal qualities
- "When writing emails, state what you need in the first paragraph", not
- "Your writing is too long-winded"
What are some other ways to avoid Derision and increase
positive feelings amongst your colleagues?
