Improve productivity and use bug classification lists for better software testing

In the work of software testing, it is very important to do the bug classification. It first needs to define the feature of each bug category, then collect the bug according to this feature, and finally form a list of bugs that belong to you.

Such a list would give some inspiration to the freshmen in the new testing industry, or to other testers who may have the experience/thinking that others lack, and that they will have my division; This list is in hand and can be used for completeness assessment of your own testing work.

All in all, having such a list is always good, whether it's on the internet to get out of the box, or keep summarizing the accumulated (obviously better).

by Michael Stahl

Even a member of the Research and Development department, the daily work is not to continuously create new products. I believe every person who has worked in the research and development department knows that, in fact, a new job is less pitiful, and more still do the things that have been done.

For example, you have launched a new project to create an embedded system that can solve the world's hunger problems. The final product must be upgraded onsite to solve the 2.0 ozone depletion problem, so you need a "firmware update" feature.

No one has ever done this before. How could it not have been done. Any embedded system has to have this function.

Yet the project team, which is tackling world hunger, is once again facing the same challenge, or the same mistake. If the "stuff" is not developed by your own development team, other teams have made similar mistakes. So now we have to re-build the wheels.

The experience of others/the experience of the team/human experience, can be shared, you do not have to re-build the wheel.

This is completely superfluous and inefficient. There should be a way to pass on a list of knowledge--bug accumulated by humans (development testers) between projects, between veteran and novice, between organizations, and even between different companies.

Start using bug taxonomy

One way to share test knowledge/experience is to create a list of bug classifications. The general idea is to define the feature categories and collect the possible bugs in each category.

These lists give experienced testers more information on what needs to be tested;

Give inexperienced testers a list of projects that need to be tested, and provide suggestions that they may not be aware of the product aspects they need to test, such as performance and availability;

Evaluate the integrity of the test case list by checking that all list items are covered in the test.

Here is an excerpt from the book "Test computer Software" from Cem Kaner,hung Q Nguyen and Jack Falk:

Performance testing

Slow Program Slow

Slow echoing response slow

Poor Responsiveness Response Difference

No Type-ahead no prompts or data/input prompts when users fill out a form

No warning that's an operation would take a long time when an operation takes too long without warning message

No progress reports no progress report

Problems with time-outs timeout problem

The above section is an obvious feature point to test, and another part to remind us of the possibility of missing certain points in the test.

For example, "when an operation will take a long time without warning message" This bug triggers many verification ideas: whether any feature in our product can take a long time. is under what conditions. Whether we provide progress tracking. Tracking is accurate.

It can also trigger the idea of redundancy: whether there is a short-time operation that pops up a window at the moment of completion and disappears so that the user is completely confused about what happened.

One interesting thing is that some of the ideas in the list have shelf life. For example, when the input prompt function appears in the first generation of computers, it is easy for the user to enter too quickly to exceed the screen's update speed, but it is usually not a problem for the current CPU.

Create your own bug categories

The thought process of a bug list written by someone else is not necessarily the same as the way you think. The result is that the items you expect to find under a category appear in categories that now seem meaningless to you.

For example, someone would place a "no progress report" under the category "Performance", but another person would expect to see the project under the "User experience". At the same time, because the description of the nature of the list is generally concise (many people write documents only for their own understanding of the good), so others will find it difficult to understand.

The consequence is that you have to browse through all (if not all, a large part of) the pick and then summarize the list of items that fit your project.

So creating a personal list and then sharing is really a good idea, but the process of implementation is not as easy as saying ... Should we give up?

No. One of my experiences is to summarize the bugs that you will often encounter as a list, because you write them, so your organization will highly recognize it, and its content is very clear to you, and the list will be highly multiplexed.

I have a list that was prepared a long time ago, outlining all aspects of the API test. Whenever I learn or discover a new API test project, I add it to the list. But I'm not going to share this list because of the reasons I've said: It's written in a format I understand, and it's not easy to be understood by others immediately. So when I share it, I need to do it personally with the recipient and make sure that they really understand the meaning of each item. For me, this list is very valuable and I have used it many times.

This anecdote is not a sample of a rigorous statistical survey, but I think it points to a possible direction: A bug list is useful, especially if you write a copy yourself, it will play a bigger role.

Over the accumulated day, this list will evolve and become a valuable resource.

You can do it yourself or a group, but if you choose the latter, I recommend that you not only invite testers, but also invite developers and product managers to provide some more creative ideas. Even if you can't directly find anything that can be reused, it's likely to trigger some new and valuable ideas.