A perspective on Lesson# 67 and 75- Bug Advocacy

Yes, I am talking here about the book that must be on every Tester's desk for myriad of reasons. It's "Lessons learnt in Software Testing" by Cem Kaner, James Bach and Bret Pettichord. I have been following this book for a while now and have experienced that this book not only provides valuable Testing lessons by super experienced trio of authors but quite a few lessons in effective book writing.
This book is all about Context driven testing approach and summarizes valuable lessons in different areas. The best way that i have found to enhance learning from this book is to read a particular lesson and then close the book and co-relate the learnt lesson to your experience or context. Here's some of my comments (based on context of my experience)-
Lesson# 67: Report Defects Promptly
Lesson# 75: Do follow-up testing on seemingly minor coding errors
Both these lessons are self-explanatory as the title suggests but a particular thing that i wanted to highlight here is that in some of the situations that i have been-it is typically challenging to get both these lessons going together in a context. Take a look at following experience snippets-
1. In the past, i have been involved in testing a networking product that had a huge dependency on setup and at the same the product had a very short release cycles. In such a product, the testing involved used to be quite setup intensive and understandably it was very time consuming. Every bug found would involve a lot of investigation which would typically take a lot of time (running into hours and sometime a whole day). And since the release cycles were short, everyone expected test team to report bugs as early as possible to give development team ample time to fix it. And to further add to this situation, the development and test teams were located in separate location geographically (separated by almost 12 hours time zone wise).In this situation, following the above lessons(#67 and #75) used to be quite challenging. Some of the challenges include-
a. If a tester is new (i.e. hasn’t yet established a reputation with the developer), then it was imperative for him/her to write complete bug report with all the investigation. If he/she fails to do so, it would result in damaging the equation with developer who sits remotely. This is a typical issue with a "faceless culture" i.e. the organization culture in which you need to team up with people who you haven’t met or seen. In such a culture, a tester would be judged solely on the basis of his work products i.e. Defect report. So a new tester would typically need more time thereby, delaying the defect logging time.
b. Even for an experienced tester in such a situation, it would take more time if he/she comes across a non reproducible kind of a bug which would take a lot more Investigation.
In such situations, we found it to be typically wise to contact developer with all the details. This has a people management challenge as It definitely means the tester work late hours to contact with offshore development team and have a talk and get into agreement to report a bug with available information and continue with further Investigation the next day.
If the development team and testing team work in the same time zone, it becomes easier to collaborate in these situations.
2. There is one more situation in which i have found the follow-up testing to be typically time consuming. This situation occurred during the Internationalization testing of a Client/Server product in 5 languages. As a part of bug information, sometimes the developers would expect the testing team to report results of the bug in all the 5 languages. What this would mean for testing team is to prepare a setup in all the languages under test and reproduce the defect 5 times and report in the bug. Being a client/server product would make preparing such a setup even more time consuming, thereby increasing the bug
logging time. It is always good in these situations (typically Internationalization testing) to get in the agreement with developer during the planning phase to understand the expectations because such a testing is indeed time consuming and would have impact on test schedule.