How to Rate a Bug?

After the bug report is completed, rating a bug is also an important task, it determines whether high- priority bugs can be fixed in a timely manner, and whether low-priority bugs have wasted the valuable time of the team. For distributed teams, it is necessary to ensure that everyone works on basis of the same standards. The evaluation of a bug usually depends on two dimensions, one is severity and the other is priority. The severity level reflects the impact of the fault caused by the bug on the software product, as shown in Table 3.6; all the indicators are specified by the tester. Priority refers to the urgency of the bugs that must be fixed, as shown in Table 3.7. and the indicators are specified by the bug allocator (project manager/test manager).

Each bug must be marked w'ith its own functional module, just as every story card has its own functional module. This is helpful for the team that locates the bug quickly, and it is also an important indicator for defining whether a functional module is completed. We need to maintain the configuration of the task management system so that the results used by all users can be more accurate and better guide the work of the entire team.

After the rating, these indicators can guide our follow-up work from the following aspects:

■ Agree with the customer on the conditions for going online or the conditions for applying the patch. In this way, when we get the bug list, we don’t need to discuss the bugs one by one, but just have them filtered according to the conditions.

■ Analyze quality trends. Before the software is released, serious bugs should show a downward trend until they reach zero.

■ Expose areas of poor quality. We can know which functional module has the most unstable quality, fix the bugs in a more targeted manner, and easily grasp the key points.

TABLE 3.6

Severity of Bugs

TABLE 3.7 Priority of Bugs

Test Strategy

The test strategy/quality assurance plan is the issue that we need to consider carefully at the beginning of the project. This plays a directional role in the quality culture established by the offshore team. Generally, our delivered software does not have a contractual quality indicator. As a delivery party, our quality commitment to customers should be implicit, that is to say, it is included by default. Therefore, in the process of cooperation, customers often ask us questions like this: some directly ask us “do you have any test plans? .” Some care about quality may ask us “how can you ensure the quality of products?” The former question often comes from a traditional customer team that adopts a waterfall development model and runs a test at a relatively independent stage. What he wants is a plan for testing stage. The latter problem is often from the customers with agile development background. We have to explain to them how the test runs through the entire development process, everyone will be responsible for testing, and how to realize built-in and built-out quality.

These contents are recorded in documents, which can make customers feel more comfortable. Customers can review the team’s test strategy, and end-to-end test cases also require customer review.

A formal test strategy needs to include the following:

■ Development and test process: A good process promotes the guarantee of both built-in and built-out quality. During the overall process, there are clarified actions and participants at different stages, preparation and maintenance of the test environment, bug tracking process, the principle of bug prioritization, and the statistics on the number of bugs.

■ Quality-oriented practices: TDD, code review, development environment acceptance, automated test, and exploratory test.

■ Scope of test: According to the different nature of each test, such as normal function acceptance test, smoke test, regression test, we are able to define the scope of each test. Doing so is conducive to balancing human resources to achieve the greatest test effect, especially regression test.

■ Security test: This is an area that is receiving more and more attention. Customers in finance, insurance, and other fields often have more specific requirements for security test.

■ Performance test: Whoever we are in the team, tester or developer, we must always pay attention to whether there are potential performance problems in the daily function development process. As a developer, we can better understand the code implementation, so we can discover some data processing bottlenecks from an implementation perspective. Testers need to fully understand the business usage scenarios and find some scenarios that require performance monitoring from a business perspective.

■ Prioritize test objects: The determination of the priority of the test objects is conducive to the final determination of the priority of the bugs. Since the priority of the function is also one of the factors that determine the priority of the bugs.

■ Criteria for system going online: Define the type and number of bugs that can be tolerated for going online.

Standardized Automated Test

Automated test is a prerequisite for continuous integration and continuous delivery. If this is not possible, we will spend a lot of energy on nonbusiness code. In the process of doing automated test, I have encountered the following problems:

■ It is hard to read the test code written by another team or someone else.

■ Is this really the code we wrote before?

■ We have already implemented the test code method they used.

■ New functions developed invalidate the test code.

FIGURE 3.13 Automated test process.

For the above problems, specific solutions are as follows:

• (1) Standardize the test process: Standardize the test process to ensure that each test case is independent and does not affect each other. We need to make each test follow the process shown in Figure 3.13.
• (2) Standardize the input and output of test. It is better to carry out centralized management of data input, so that it is not easy to cause any omission or inconsistent data types.
• (3) Modular expansion. Considering the reusability of test code, when continuously accumulating test cases, reuse existing methods as much as possible to reduce future maintenance costs.

Summary

Normative approach means generality in this industry, which is also the cornerstone for the collaboration between teams and something that can be directly used for reference. Of course, these norms are not necessarily universal. We still need to combine the characteristics of our team to find the norms that our team should have, so that our team can focus on valuable and creative things. Rather than spend day-to-day communication and quarreling over things beyond value.

Normativity often means automation and routinization. The purpose of these normative work is not to stifle creativity, but to reduce communication costs, improve efficiency, and avoid “reinventing the wheel” without affecting creativity. The best job is definitely manual work, this is the case with cars, since all racers are driving the cars with manual gears; the same is true for driving ships and airplanes. Although there is a convenient automatic system, it is still necessary to switch to manual mode at critical moments. This is true for the landing of ships and the takeoff and landing of aircraft.