Priority division of Test Cases

Excerpt from Network: http://www.educity.cn/se/523513.html

The priority level of the test case

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

The-in-a-small version confirmation test (Build verification Tests (BVTs): Also known as a "smoke test", a set of test cases that you want to run first to determine whether this given iteration can be tested. If you do not have access to each functional area or perform the basic operations of other test case dependencies, it makes no sense to try to do any of the other tests before executing this first test case, because most of them will definitely fail.

High (highs): The set of test cases that are most often performed to ensure that functionality is stable, that the behavior and ability of the target can work properly, and that important errors and boundaries are tested.

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

4– Low (lows): This is the test case that is usually executed at least. This does not mean that these tests are not important, but that they are not often run during the life of the project, such as GUI, error messages, usability, stress, and performance testing .

We divide the test cases into 4 categories: BVTs, High, medium, and low. The problem now is to divide the test cases into different priority levels.　　After all, the priority level will indicate which test cases are considered to be more frequently executed and which are not. How to get started assigning priority levels

1) Randomly assigned:

Based on the idea that if you don't have enough time to test and at least make sure that all the product requirements have been identified to work as they were expected in good condition, the first 3 steps will let you arbitrarily group the test cases, and if you stop to think about the content of each test case test, they will become very important. So you only need:

I) Mark the tests of all your functional validations (or basic paths) as high priority levels (Happy path)

II) Mark all your errors and boundary values or validation tests as medium priority

III) Mark all your non-functional tests (such as performance and availability) as low priority.

2) Promotion and demotion:

Not all functional tests are as important as the boundary and non-functional tests. Think about the importance of testing and the tests that are relative to other levels of priority, and you want to check The frequency of this feature-consider the quality goals and requirements of your project.

I) The functional verification test is divided into two groups: important and not very important.

II) Downgrade the "not very important" performance verification test to the medium priority level

III) Divide the error and boundary tests into two groups: important and not very important

IV) Upgrade "critical" errors and boundary tests to high-priority levels

V) split the non-functional tests into two groups: important and not very important

VI) Upgrade "important" non-functional testing to medium priority

VII) for each set of high, medium and low priority test cases, repeat the division and upgrade/downgrade process until you reach a point where the number of test cases that can be moved between different priority levels is minimized.

3) Identify the minor version verification test case (Build verification Tests):

Now, to make sure that the iteration is testable and ready to start testing for the rest of the team, which test cases must be checked in each iteration?

I) Divide the test cases of good priority into two groups: critical and important

II) Upgrade "critical" high-priority test cases to BVT priority

Note: Do not identify BVT test cases first! BVT are just a selection of high-priority test cases that have been identified as important for systems and testing.

At the end of this process, the percentage distribution of the priority is to be checked : BVT for the 20-30%, high for the middle, and in the case of the low.

When you upgrade and downgrade test cases, the aspect that you need to consider is how often users will require this functionality or functionality. Similarly, the severity of this behavior is for the user's daily or month-to-month activities. Robyn Brilliant provides a checklist in the test progress report that you can use when considering downgrading or upgrading test cases

Using a scale from one to five, from the most severe to the least severe, quantify the reliability risk as follows:

I) The failure of this feature will affect the user.

II) Failure of this function will have a significant impact on the company

III) Failure of this feature will cause a potential delay to the customer

IV) Failure of this function will have a lesser impact on the company

V) The failure of this function has no effect

This and its similar scale can help you reach the final step in your test case prioritization.

Summarize:

This is an example of a simplified procedure for dividing test case prioritization. However, it can give you a lot of help in the areas of quickly organizing test cases and scheduling test progress and workloads, and what test cases you need to complete to develop your project plan.

Remember, how you prioritize your test tasks and how you execute test cases will depend on where you are in your project cycle. You may re-prioritize your test cases as you move forward and determine where hazards and defects arise through investigation and observation. Building up your test goals for each stage and ensuring that they are reflected in the priority level of your test case will make your life much easier when it interprets and executes your plan.

Finally, having a prioritized test case gives a good starting point for your potential, pending Automation project. For example, test cases in automated BVT, measure revenue, improve test automation, automate high-priority test cases, and more.

Priority division of Test Cases