Bug Reporting is an Art – Idexcel Testing Roundup

1. Why Bug Reporting is an Art That Should Be Learned by Every Tester

When it comes down to it, a tester’s primary responsibility is to test an application or project and report back on the issues. But it isn’t here that the responsibility ends, from here, the real work begins. It’s absolutely essential for testers to understand why their bugs are being rejected or being marked as “not reproducible” and how to react in these situations. Read more…

2. How Was This Tested?” Providing Evidence of Your Testing

Many testers have a tendency to minimize the information they record when testing. The challenge comes when problems are found later, possibly after the software is in production. How do we remember what we did, and when? What records do we have to refer to? How do we, as testers, answer the question “How was this tested?” Read more…

3. The Advantages of Utilizing Formal Test Design Techniques

When it comes to test design, there are those who firmly believe in the use of formal test design techniques and those who believe that those same techniques cause rigid thinking and limit creativity. I believe formal techniques have value as a basis for formal analysis and design as well as for creative thinking. Read more…

4. Discussion: Should Trivial Bugs Be Logged?

A poster to the Test Huddle forum referenced this blog from Eric Jacobson in which he argues that reporting trivial bugs tends to waste everyone’s time and that testers shouldn’t log them. The forum poster’s question: Do you agree or should all bugs be logged despite the severity?

Reponses from both sides have already been submitted to the thread. Contribute your own thoughts on the matter here!

Improving Testing Effectiveness

Organisations spend significant money, time and effort in testing their applications so that they can get a good return on their investment, and earn goodwill of the customer by providing them a product that offers a flawless experience. This experience can only be assured if the product has been designed well that matches with the customer’s expectations and requirements, and has been tested comprehensively, covering most real-life scenarios.

If the product is released by the company and any bugs are reported by the end users, there is usually a feeling of disappointment, and testing team feels the pressure as they now need to answer several questions from the management regarding their testing procedures and methods. This happens mainly because when the requirements are given to the testing team, the team members tend to intuitively think about the features and start writing their own perception of the functionality and features as test cases. Hence, test cases are entirely based on the level of knowledge and thinking capacity of the testing team, or a testing individual. The reviewers have also limited scope to correct these test cases, or add something substantial to them. The derivative is quite limited, with the possibility that the testing team might have missed or overlooked some important aspects of usability or behavioural issues.

At times, this intuitive or exploratory testing can be quite effective in bringing out quality bugs; however, it is beneficial only when there is expertise in technology, domain and other factors. Additionally, exploratory tests are not documented for regression and the bugs can get re-introduced in the later stages without getting noticed. Hence, it is essential to follow a systematic testing approach to have efficient and effective test cases that can be executed regressively.

This improvement to testing processes starts by providing a complete understanding of the project to each stakeholder. As a part of testing strategy, the best practice is to form a team, comprising of Subject Matter Expert, Product Architect, Senior Developers, Product Manager, Developers, and Automation and Manual Testers for the given product. When all these people work together as a team, more perceptions come out based on the expertise of each, and these perceptions can be documented, that can be used as a reference by the Requirement managers to write the functional specifications, by developers to design and develop the features and by testers to make their test cases.

The quality of testing to a large extent depends on the quality of these test cases that are documented and tested automatically or manually. Although there is not a linear relationship between the efficiency of tests and number of bugs found, however, by adopting the well-defined and documented processes and procedures, the developers become more efficient in reducing the number of bugs, and testing teams can become more effective in finding the bugs at the right stage of development cycle. However, documenting each minor detail can be quite inefficient, and pounding the same path with automation or regression scripts may only give little of any new information. Hence, add deterministic techniques to the testing, and make a practice to communicate and collaborate early. This gives the chance to find most critical bugs. Output of the session based test management of the exploratory tests can be used for regression, and if any bugs are found, they can be turned into automated tests.

To improve testing processes, the testers must also be involved in all the discussions, conversations and meetings regarding the project. QA must be made a part of the software development life cycle, and there should be continuous improvement in the testing processes and testing skills. The testers must be flexible and receptive to the change, and there should be willingness to try new methods and latest cutting edge technologies of testing.

The testing quality definitely depends on who looks, and when and where. It is impossible to have 100% bug free application, however involving several teams in user cases/acceptant tests design or review helps QA to have more comprehensive coverage. This does not mean that everyone should leave their work and get involved in testing. However, some key people can add value to the tests, and participation from the experts reduces lots of rework and penalties that companies have to pay at the cost of goodwill.