General bug classification of software testing

First of all, the test case comes from the analysis of the requirements. Whether the most suitable or critical requirements can be selected for the test is related to the success or failure of the project.

Thinking method 1: positive and negative thinking

Develop at least two test cases for each test requirement: positive test cases and negative test cases

Positive test case: used to prove that the requirement has been met; negative test case: reflects an unacceptable, abnormal, or unexpected condition or data, used to demonstrate that the requirement can only be met under the required conditions

Basic flow: the easiest path through a use case

Alternative stream: executed under certain conditions

The pre-condition is the system state that must exist before the use case is executed, and the post-condition is the set of states that the system may be in after the execution of use case 1.

There may be different ways for different projects (or programs, software) under test. Due to different projects, it is possible to overwrite the use case coverage, detailed procedures, and so on. The evaluation indicators are also different.

In the review of the use case, in addition to going through the basic business flow, the most important thing is to review the use case in combination with the risks of the project (system, security, application risk), etc.

Priority of the test case

First, you have to determine what your priority type is and what it implies. For our purposes, we will start with the assumption that the severity of the defects we may find is parallel to the priority of those corresponding test cases.

1-Build Verification Tests (BVTs): also known as a "smoke test", a set of test cases that you want to run first to determine whether the given small version is testable. If you cannot access each functional area or perform the basic operations on which other test cases depend, there is no point in trying to do any other tests before executing this priority test case, because most of them are bound to fail.

2-Highs: a collection of test cases that are most often performed to ensure that functionality is stable, target behavior and capabilities can work properly, and important errors and boundaries are tested.

3-medium (Mediums): this is a test case that makes the given functional area or function more detailed and examines most aspects of the function, including boundaries, errors, and configuration tests.

4-low (Lows): this is usually the least executed test case. But this does not mean that these tests are not important, just that they are not often run during the life of the project, such as GUI, error messages, usability, stress, and performance tests.

We divide the test cases into four categories: BVTs, high, medium and low. The problem now is to assign test cases to different priorities. After all, the priority will indicate which test cases are considered to need to be executed more frequently and which are not.