This question came from an interesting discussion that I had done in the Automation Advocates Virtual Coffee Meetup # 1. The topic for the meetup was a good tester developer relationship. We all shared our views on the importance of a good tester developer relationship and the tips, traps, and possibilities on this topic.
There were some fascinating points raised during the discussion. One such point was that it could be sensible to share the bugs directly with the developers if it helps save time going back and forth. Another view was that if this practice of healthy collaboration is brought into place, this could also help the testers get some respect credit from the developers.
Post meetup, Fenil Vaswani raised an interesting point:
As a developer, they have their database, APIs, and most importantly UI to showcase.
As a tester, to showcase my work & quality, I have my bug count and bug quality.
That is why I am not keen on sharing bugs with developers without posting them first on my test management tool.
Before I share my views on this topic, I must admit that this is an interesting question in many ways. Let me tell you why?
- The majority of the industry thinks that a tester’s job is to find bugs in the product.
- Most testers also look at their work as a bug-finding activity.
- Bug Reports are one of the most important artifacts (or output) from a tester.
- Many companies (and teams) still use bug count as one of the major factors to determine the credibility/rating/review of the tester. Sad but true 🙁
- Linking bugs to defined test cases or adding test cases for every new bug is a standard practice in a lot of places.
However, is a tester’s primary work role really about just raising bugs, writing tests, and creating bug reports?
For this, let’s revisit the definition of testing: “Testing is a process of gathering (meaningful?) information about the product that can help its stakeholders make well-informed decisions.” In short, Testing is an information-gathering process.
Bugs, Tests, and Bug Reports are certainly one way of finding & representing some valuable information but are these the only ones? NO.
Apart from the above three things, here are some things that can be done and used to showcase a tester’s work:
- Risk Analysis
- Root Cause Analysis
- Product Coverage Outline
- Test Notes
- Test Summary
- Test Planning
- Session-Based Test Report (Refer to SBTM by James Bach for more details on this).
- Competitor Analysis
- Test Strategy – Document / Overview
- Requirement Review – Questions, Notes, Ideas, Bugs?
- Pair Testing Sessions / Session Notes
- Debriefing Reports
- Testing Story
- Analysis of Test Tools
- Analysis of Dev Technology – Limitations, Traps, etc.
- Bug Prevention Checklist / Common Issues to avoid?
- User Persona Analysis / Understanding Users
- Advocating for customers
- Biases to avoid?
- Discussion with Customers, Sales, Marketing, and Support Teams
- Investigation of popular use cases
- Questioning the product about its mission, risks, threats, future, etc.
- Cost vs Value Analysis?
- Highlighting Assumption List
- Researching known issues
- Checking for compliance and statuary issues – Data, Accessibility, Security, etc.
- Contribution to Product Documentation, FAQs, etc.
- Understanding Business Flow
- Assisting / Pairing with Developers for Corner Cases, Retesting, Test Ideas, etc.
- Coordinating with other teams.
and this list can go on and on. Yeah, I know there is a lot that we as testers do 😀
In short, a tester is like the headlight of a car. They can lighten up any dark spot in any direction you turn them to.
But the problem is that to do a lot of the points mentioned above, we as a tester would need a lot of time and how can we get that time?
I have found these two things to be very helpful in utilizing my time well as a tester:
- Bug Prevention – Catching early bugs is great, but what if you can help prevent the bugs in the first place! That’s a super time saver as you will save your and the developer’s time in finding the bug, investigating it, reporting it, retesting it, and closing it.
- Sorting out issues that can be sorted out directly – Creating a new issue each time will end up adding noise to everyone when things can be sorted out.
- It can also lead to frustration, and embarrassment for the developers in some cases if you are raising obvious issues like build issues, wrong configuration, incorrect versioning, etc.
- There are also strong opinions across the industry that every bug should be reported and not sorted out with developers like this as it might just go unnoticed or ignored or invisible to the larger group.
- But the counter-argument is – if the reporting becomes an overhead and there is a way to get it resolved, why not do it?
- NOTE:
- Of course, this does not mean that rush to the developer first for every issue instead of raising a bug or not raising any issue at all.
- It just means that for basic things, that can be sorted out, this strategy can be used sapiently (with context and care).
- Also, it could be a double-edged sword as some developers may want to crush down your work by settling issues off the board. But that’s a poor culture and non-professionalism problem first and a reporting problem later. In such cases, such progressive strategies might not work.
Hope this blog gave you some ideas on various areas that can be used to showcase the tester’s work beyond bugs, tests, and bug reports.
Signing Off!