“A tester ensures the quality of the product.” — Probably just as much as my donations to wwf are helping me to “save endangered species.”
The other day I listened to a podcast by the Bach brothers. One of the things they pointed out as needing improvement is the accuracy of testers’ statements. As an example, they cite — and question — the familiar statement “a tester ensures the quality of the product” which many of us use to describe what we do. But then I guess it can’t be helped. Someone I follow on twitter shared that a book on software development described the tester’s task is to verify that software is correct.
Is that really what I’m supposed to do? Ensure quality? Well, it does make my work sound more powerful. It sure makes for better marketing than “find bugs”. And probably for more attractive hiring. But there’s a shred — ok, a tiny sliver — of truth to it albeit so indirectly (just as i am saving endangered species… somehow).
In the podcast, Jon Bach suggested the term “assistance.” Between “ensuring quality” and “helping” to do so, what we do comes closer to the latter. We help our SAs by spotting design holes. We help our devs by spotting errors and misses in their code. We help them when we give clear and concise bug reports — all the more when we do bug isolation and provide accurate reports. We help our team leads by providing information on the product under test. Et cetera, et cetera. Sometimes it may not be quite obvious but we, testers, are a very helpful bunch!
We do our bit, we play our part. But no matter how well we play it, by ourselves, we (testers) cannot ensure quality. I reckon it’s a team thing. What we do as members of the project team (be it testers, devs, SAs, etc), how badly or how well we do it, can either make or break our software product.
This evening, I received an exclusive pre-release article from [the] new Marcum and Smith book, “Momentum”. They’re the same guys who wrote Egonomics. Anyway, part of the article is on the ultimate team player — which I’m sharing here.
According to our work and research, the ultimate team player has certain characteristics that set them apart and make it easy (at least easier) to know who they are when you see them. Here are some key questions that distinguish a great team player:
- Do they make the people around them better?
- Do others offer better ideas because of their questions?
- Do others work more passionately because they’re around that person?
- Do others pay attention more when they’re in the room?
- Are others more engaged because they’re on a project with that person?
Here are 12 characteristics of a great team player that feed into the five questions above:
- We, then me mindset; works with a team first approach without losing sight of his individual talent, confidence and contribution.
- Devoted to progress; committed to a cause or purpose beyond himself.
- Speaks her mind boldly and diplomatically.
- Listens to feedback carefully and anxiously, especially when it’s difficult to hear.
- Constructively discontent; not pessimistic, but not relaxed about status-quo.
- Inclusive; loves diversity and talent, especially those with talents and history different than theirs.
- Insists on debate, and debates ideas effectively; doesn’t care who has the best idea, as long as the best idea wins; doesn’t take things personally.
- Open minded; not change or new idea resistant.
- Doesn’t allow the early warning signs of poor communication and teamwork (defensiveness, showcasing, excessive competition, seeking acceptance) undermine team dynamics and individual talent.
- Sees people as equals, not as superiors and subordinates. Only in accountability and performance are those hierarchical relationships visible.
- People trust your intentions; people know where you’re coming from when you challenge ideas, share new ideas, etc.
- Desire to make a difference, not just “do your job.” There is a clear performance difference between “job-holders” and difference-makers.