Yah... itung-itung buat share ilmu
*berhubung yang punya PT M wong londo (a.k.a. bule), dan kebanyakan client nya juga wong londo, jadi kebiasaan disana ya kalo untuk komunikasi yg formal, terutama yg tertulis, yah harus pake bahasanya wong londo... jadinya artikel nya in english deh... belepotan dikit gpp yee, asal intinya tersampaikan ^_^
~~~~~~~~~~~~~~~~~~~~~ ** ~~~~~~~~~~~~~~~~~~~~~~~
Cem Kaner said that Bug Reports are Software Testers’ primary work product. The best tester is not the one who finds the most bugs or who embarrasses the most programmers. The best tester is the one who gets the most bugs fixed.
The question is how could we make programmers (developers) to fix our bug? It is by “selling” our bugs to them.
There were times where developers would make excuses or reasons for defending the code they built. Sometimes they might even argue about the defect that we found. This often happen when my team and I found a defect that only happened in a certain environment; for example, the application runs well in Mozilla, but not in IE7. Therefore, before the testing began, I confirmed the required environment (agreed by stakeholders) first; i.e. IE7. Many developers weren’t aware about this agreement at first, because they were developing using Mozilla as their browser. Therefore I motivated my team to always write the testing environment; the test site we use (because we have many application servers for testing and development purposes), the browser we use and give them the understanding about the agreed environment.
Testing a big system which has many integrated modules is quiet challenging. We often find defects that the main problem is not in the module (area) that we are currently testing. In this case, instead of just report the defect in that particular area, we need to trace the source of the trouble. For example, when I found a page that was sometimes becoming run time error, but some other times it worked just fine. Instead of reporting “if you lucky, you’ll find it” or “keep trying until the error happen” in my defect report, I put some extra effort to isolate the defect. And then, it appears that the defect was caused by the auto numbering feature that caused a SQL deadlock when 2 or more pages with auto numbering value are accessed in the same time. By knowing the exact way of how to reproduce the defect, we make our defect accountable.
Sometimes, in order to make our defects fixed, putting the impact (what would happen if the defect is not fixed) would make our defect report more convincing. For example, I often report defects that related to usability that could potentially be ignored by the developer because they would think that the defect is unimportant. One of my experience, when I was doing localization testing, I found that a description of an item is only displayed when user’s language preference was same as item’s language description that has been inserted. While user is not required to insert description in all language preferences, there is a chance that when user open an inventory list, the list would only display the number without description and it will be annoying for the user. By letting they know about the impact of the bug we reported, will add the “selling point” of our defect.
Talking about impact, it is closely related to severity level. In the beginning of our testing period, the development team argued about severity level that testers have set for several defects. It happened because every person might have different point of view in seeing a problem (defect). In order to minimize this kind of dispute, I decided to share a guideline (the related email is attached) for setting the severity level to help my team and to let the development team knows the standard that the testers follow.
In the current project I tests, my team and I often faced with the fact that the oracle (BRS and SRS) are not up to date; indicated by many functionalities that are not described in the BRS or SRS. When this situation is happening, I always motivate my teammates to confirm the feature to the responsible Analysts (I recommend to use the email, so we could have evidence) and log a requirement defect if the feature has worked properly but has not been documented, or create another defect if the feature is not working as it should.
Tester’s customer (buyer) is developer; therefore, we need to make a good impression to developers so they can trust us and willing to fix our defects. In order to provide a good and convincing defect reports, our soft skills as Software Testers are also challenged. We need to avoid embarrassing or offend the developer’s feeling, in the other hand, we also need to make them fix our bugs. How to convey the issues we found to developers through direct discussion, IM, email and also defect reporting tool are important. At first, we found it difficult to work with developers in this project because we have not got their trust yet. The developers (especially their ANs) often said that we had not tested the system thoroughly even though we had found many critical defects, etc. But our hard work has now been paid; it is a lot easier to escalate issues that we found during our testing and make developers fix our bugs.
Originally created on: 18 Nov 2010
by: Maria Christanti
~~~~~~~~~~~~~~~~~~~~~ ** ~~~~~~~~~~~~~~~~~~~~~~~
Semoga bermanfaat...
Cheers ^^
