This content is not necessarily a pet peeves, rather more on improvement suggestions for communication and education on testing to non testers. However, this statement alone seem sound like a pet peeves itself , right ? Testers are sometimes mistaken for what they do, and what they can do, and resulted in frustrations from other team members.
I did a survey with around 100 developers how to improve communication between the QA department and individual development teams in 2019.
I believe in a team (whether you are Agile, Waterfall, Scrum , or any methodologies) , every team members play an important role to quality. Once of the biggest challenges in quality is that the expectations are different.
Here are some of my conclusion from the survey how to improve the communication between testers and developers
- Lack of clarity of Bug (Defect) Reports
There are times the bug report have no substantial steps that can folks outside testing can reproduce the issue. Maybe it is only reproducible in the tester’s machine or test environment
Suggestions to testing folks
Read your bug report from different perspective. If a team member need to come to your desk to clarify with you about the bug report, it means the report is not good enough. Make sure that the steps are simple enough to be followed (by any team members) with the type of environment (test/development/ OSes). If need to be, attached images, videos, logs , test media to be clearer.
In addition, I would ensure that the defects are reproducible in a virtual image or docker image. I have a dedicated machine to reproduce defects so that the developer can remote in.
This does gets on developers’ nerves especially when a team member discover a Heisenbugs bug report filed in. Imagine the frustration when the poor developer cannot reproduce.
See link how to do a better bug report
2. Demanding developers to fix a bug on spot
This is a pet peeve to many developers and it gets onto their nerve when testers ask them to fix some defects within the sprint or immediately. Context switching is hard for some folks , and it is particular hard if you are deep in some level of writing a features, and working on other tasks may cause you to loose the context of the work you are doing. This is challenging for many developers — especially if they are working on feature 2, and the tester is asking them to fix feature 1 right now.
Suggestions to testing folks
Do report any critical / showstoppers defect on the daily standups, unless the business is losing huge amount of revenue per seconds due to this bug (or this bug is causing an injury / death to someone at the moment). Make the stand as a team , not as a tester alone — the decision to fix the defects lie in the team.
I have a shared document daily on the types of findings I have. The bugs in this document is not officially filed — it is an informal sort of documentation to communicate with team. I encourage the developers to look at it. Many developers I talked to prefer this method where testers will write findings in this doc daily. It is like a journal. I will feedback on the shared document daily.
However, that does not mean you should not file a defect in a defect tracker.
3. Testers seem to complain they have no time but it is all about clicking buttons, right? No?
Testers know that is absolutely not true, but not every member of the teams know that. This is surprisingly when I hear from other members do not know what testing team do. This lack of understanding does not restrict to developers only, it happens for non technical folks such as Project Managers, Business Analysis , Product Owners. Some of them feel that testing is an easy job or it is just scripting.
No, testing is challenging in many levels, resource intensive and testers get the blunt of blame when things go wrong sometimes.
Suggestions to testing folks
Be clear on the tasks. I do this in a few ways — In Jira (or any project management tool), I will mark out (or log tasks) all testing activities — whether it is exploratory , or automation related. Yes, some folks may complain that it will flood the dashboard — but it shows the transparency and accountability that there is a list of testing activities that need to be conducted in this sprint.
Mindmap — I print out a A2 size mindmap on the current features / tasks (or activities) to be tested , and marked it out (with a highlighter pen) what is done on every sprint. This is usually tag in the main wall of the team. The advantage of this is that the whole team becomes aware of the gaps the testing activities, and I have gotten quite a few volunteers within the team to help out in testing. Team members start to appreciate what testers do when they see this mindmap, and also helps to find ways to make it lighter for the testing load by sharing critical knowledge that testers may not have thought of, or help out especially during crunch period.
One way to help other team members to understand testing itself is to do an education. In the retrospective, team members will do a short demo of what we have done. It is crucial that testers participate educating the team during retrospective meetings. Teams members will become aware that there are more to testing than mere button clicking. Moreover, team members can suggest improvements in what areas may be cover in future
Pair testing. I encourage developers to do occasional pair testing with the tester. It can be a short period of time (example an hour) to test on certain features together. In this way, both sides can expand the scope wider. This applies to other roles beside testing.
4. Testers have the heck of finding edge case bugs that is not relevant
Some edge cases are difficult to work on, and sometimes bugs get reported. When this happen, developer do face a challenge and wonder why testing team spend so much effort on chasing edge case bug. For some bugs, they are not easy to reproduce even with a proper bug report.
Suggestions to development and testing folks
Do a risk analysis. One way I do is key stakeholders will input their weightage what should be cover in testing. The PO , dev, marketing , testers or anyone in the team may have different inputs to the risk and this should be taken down.
Additional improvement is that developers should highlight the technical risk in features. Example, in some features, there are higher risk of bugs due to the complexity in third party libraries dependencies. This should be raise in the risk assessment.
Any bugs log or discover during testing is still a bug found, it should be log in. Finding a bug does not mean that it should be fix now. Fixing a bug is the team decision (or depending how your team policy goes). I would conduct bug scrubbing meeting regularly with key stakeholders within the sprint to decide on priority, schedule and assignee on the fix itself.
5. It is the tester responsibility to ensure that bugs do not reach customer
When the customers find a bug that is not reported by the team, it is tester fault. Testers should be finding all the bugs, before it reach the customers.
Suggestions to testers
We know that is a misconception. Testing does not prove that there is no bugs.
Testers need to proactively educate the team. Beside the above points, I include ad hoc exploratory testing activities that involves everyone, including the CEO to finance , customer supports. This helps to bring awareness that testing not only can be fun, it involves everyone’s attention. Testers themselves like everyone, have certain perspective on how the features will work / or not work. By been inclusive testing (involving everyone), this helps to include testing as a common activities as everyone responsibilities and broaden the perspective of usage.
This does need senior management support. Most employees can participate in some form of testing activities such as ad hoc exploratory testing in different business functions, usability focus group testing with customers etc. The internal stakeholders will know how reliable (or fragile) the products / services when they participate in using the products actively. It is important as tester, the role of education comes here — there will always be bugs somewhere — but we are more prepare as a business together rather than as only a tester. Get everyone to involve in testing as much as you can.
Conclusion
Above are some of the improvements that I felt can help in communication between testing and other team members. I believe you can find many other ways to improve the gaps between testing and other team members.
There is a saying in a Chinese idiom -
唇亡齿寒
Pronunciation : chún wáng chǐ hán (chun wang chi han). Link
Translation : If the lips are gone, the teeth will be cold (both depend on each other to function well)
Meaning : If one falls, the other is in danger. Two parties share a common interest. If one is hurt, the other will, too.
This goes the same for testers and other team members. We are all interdependent on one another.
Within a team, everyone plays an important role to understand each other expectations and work towards common goal. Although each team members have different roles, but we share the quality objectives. Every members are critical. Quality is more of a mindset of acceptable standards towards common goals. The different stakeholders within the team who understand each others’ expectations and work towards bridging the differences tend to achieve greater quality attributes across the business functions.
