It is fair to refer to testers as “QA”?
- One test manager talked about how he has renamed his test team as the QA team
- He has found that it has changed how his team are regarded by their peers (in a positive way).
- Interestingly, he doesn’t call it “Quality Assurance” just “QA”
- His team have bought into it.
- Role titles are a lot about perception: one colleague told him that “QA” feels more like “BA”.
- Another suggestion that “QA” could be “Quality Assisting”
- We covered the angle that (traditional) QA is more about process and compliance than what most of us generally call testing.
- We didn’t discuss the fairness aspect of the original question.
What books have you read recently that contributed something to your testing?
- The Linguamatics test team has a reading group for Perfect Software going on at the moment.
- Although I’ve read the book several times, I always find a new perspective on some aspect of something when I dip into it. This time around it’s been meta testing.
- The book reinforces the message that a lot of testing (and work around the actual testing) is psychology.
- But also that there is no simple recipe to apply in any situation.
- We discussed police procedural novels and how the investigation, hypotheses, data gathering in them might be related to our day job
When should we not look at customer bugs?
- When your product is a platform for your customers to run on, you may find bugs in customer products when testing yours.
- How far should you go when you find a bug in customer code?
- Should you carry on investigating even after you’ve reported it to them?
- In the end we boiled this question down to: as a problem-solver, how do you leave an unresolved issue alone?
- Suggestions: time-box, remember that your interests are not necessarily the company priorities, automate (when you think you need lots of attempts to find a rare case), take the stakeholder’s guidance, brainstorm with others, …
- If the customer is still screaming, you should still be working. (An interesting metric.)