Shulou(Shulou.com)06/03 Report--

Follow the documents around the content project test in the previous section, and share the release application list and defect tracking management form today.

For small projects, the release application list is completed and reviewed by the project manager, and then delivered to the deployer for direct release. However, in the strict project specification, this method is not feasible, especially for large projects, if it involves external customers, the release of the application list needs to go through layers of review before the release action can be carried out.

Issue a list of applications

First of all, let's take a look at the whole process of release in the project, and many traditional testers generally only follow up to the test delivery or the end of product acceptance. The release process is not clear, or the project manager will notify you of the need for online testing after the release. By analogy, testers have been working passively. For the overall specification of the project, the release process is as follows: test team system test delivery-> UAT test team pre-release test pass-> product manager acceptance-> R & D manager fill in the release application list-> submit it to the project manager & QA manager to sign and confirm-> R & D manager sends the application release email-> the functional department head agrees before performing the release action, otherwise the reason for refusing the release will be given.

In general, the list of published applications mainly consists of the following:

Project name

Current version

Release version

Applicant

Date of application

Version description

Test situation

Fallback mechanism

Remarks

Relevant auditor

Fill in the current application version number, the applicant is the first responsible person for the application for release, and also the person who fills in the release list. The version description is the content that is about to be launched at present, which can be divided into add and delete, optimize functions; fill in the test results of the application release version, such as SIT/UAT test pass, XXX product team acceptance, etc.; remarks and relevant auditors can be configured according to the needs of the company. Generally by the project manager and QA manager, functional department responsible person audit; fallback mechanism according to the nature of the project and company requirements, fallback mechanism and risk identification is equally important, once released abnormal, need to do a good disaster recovery test proposal. Here is an example:

Trial run: 2 days

During the trial run, internal users conduct system function acceptance and online routine testing by the testing team; if problems are found and there are a large number of problems (more than XX) or serious problems, the fallback version is returned to the previous version; fallback needs to be carried out before XX confirmation and the problem is repaired immediately; if a small number of problems are found and the severity level is low, follow-up arrangements will be arranged to fix them step by step.

Even if we don't need testers to get in touch with release-related work in our current work, we need to learn actively to integrate us into the project, rather than simply "performing tests."

Defect tracking management table

Defect tracking management tables are still common in work, and defect reports generally use defect management tools to maintain and track. The defect tracking management table here is generally used in the late stage of the project and the end of the test. for the tracking and maintenance of legacy defects, the defect tracking management table will be used in test reports, release application lists, and customer project weekly meetings. It is inevitable that there will be some time-consuming and energy-consuming problems in every project, especially the performance testing problem, the average repair period is about 1 week. However, when the test delivery time is over according to the test plan, the tester is required to sort out the legacy issues and maintain them in the form of tracking management tables.

The defect tracking management table mainly contains the following:

Defect number

Defect category

Emergency degree

Use case number

Problem description

Solution

Proposer

Handlers

Resolution time

Above, you can also filter and export from the defect management platform, it should be noted that the use case number is the test case number corresponding to the defect, if it is found in exploratory testing or internal users, and there is no application case path, you need to add the use case to the use case and update it to the use case base, which is also what you should learn and pay attention to in the future. The solution can be filled in flexibly, but the solution cannot be empty when it is delivered. There can be multiple handlers. Defect tracking management tables are generally placed in collaborative documents.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.