Plan Test Series (6) -- things

I slept late last night and lost my mind. I had a whole piece of unknown things and added chaos to the garden. Now, let's calm down and write the plan test series.

 

The previous "plan Test Series (V)-time" in this plan was a weakness of Aaron, which was poorly written. But to maintain integrity, Aaron posted it, looking at the visits of a few people, Aaron felt that he should write better things. Start to talk about the things in the test series.

What does the test do? The test is ...... Hurry up. Aaron refers to "things" that are specific to a test project, rather than reading sentences with "software testing" or other classics. According to Aaron's understanding in the previous article, the software project process or an iteration must go through the stages of planning implementation summary. For testing, we can further split each stage into the following:

 

Develop Test Plan

As for the purpose of the plan, we should not go into details again, and the test plan should be taken seriously as the crystallization of the planned test activities. In the actual project, Aaron found that the test plan he wrote was not significant, at least not as meaningful as the test plan process. In many software workshops, the test plan has been put into the cold room since its birth. The significance of the test plan is only a method used by the writers to post gold on their faces. The recommended method for Aaron is to maintain a document named test plan, which is essentially more like test design spec, after completing a Failover test plan, this document serves as an outline throughout the test execution process, and any reader can use this test design spec to understand Aaron's ideas and ideas for project testing. Aaron earned the test design spec review opportunity in his project team. Aaron told them like this: Aaron worries that he understands the meaning of PM wrong. Aaron is worried that he wants to think differently from Dev. Aaron wants to clarify things first, so Aaron wants to review them.

Aaron also talked about the test plan in the second article in this series --《Plan Test Series (II)-test plan.

Test software requirements

Software requirements are what testing should cover, which is one of the reasons why many software methods advocate early intervention in the software development process. We should be skeptical about the feature list or feature spec provided by PM. PM is not an expert in the project object field. He will make mistakes and he will be careless, he also has a short-circuit head, so at this time, many project members, including testers, need to check this list or spec together, which is called review. Testers and other personnel involved in review should read the document and understand the project-related fields. The review of test design spec mentioned by Aaron has completed the task well. Of course, due to the business knowledge and experience, the quality of test design spec is high and low, the reivew effect may be very different. Aaron recommends that you review your test design spec and submit it again. Aaron will not be able to share it with PM and Dev until he reaches v1.3 ".

Test Case Design

With regard to the design of test cases, such as equivalence classification, boundary value analysis, and even demand matrix methods, Aaron will not talk about them here, the existing documents on these things are more professional than Aaron. What's more, these contents are not the purpose of this Article.

Run the test

It mainly refers to the execution of test cases, but should also include updates to test cases, bug submission and management, and so on. Aaron also sends a weekly Test Report to the project team members in a slightly longer iteration to help them understand the progress of the week's testing work (by the number trend and distribution of test cases ), the current bug-related information (bug count, trend, critical bug distribution, regional distribution, etc.) will also be reported, which is helpful for the smooth development of the project.

Report test results

Aaron sends a weekly Test Report to the project team members in a slightly longer iteration to help them learn about the progress of the test in the week (by the number trend and distribution of test cases ), the current bug-related information (bug count, trend, critical bug distribution, regional distribution, etc.) will also be reported, which is helpful for the smooth development of the project. Of course, we also need to submit a test report after an iteration or after the project is over. This is a summative report.

Installation test

Consider the various hard software environments used by the software, not only in the planning process, but also check whether the deployment documents or product manuals contain the definition and introduction of the installation environment.

Automated Testing

The scope and content of automated testing are many. introducing and implementing automated testing based on the actual situation of the project team is the development trend of software testing.

Performance Testing

Performance tests include stress tests, load tests, performance tests (in a narrow sense), and large-capacity tests. These tests must be selected and arranged based on actual needs, and reflected in the plan.

Update (software change) test

It mainly refers to version upgrade tests, especially for Software of the product type, which should be paid more attention.

 

The test itself includes a lot of other content, such as failover and switchover tests. Sometimes we need to test the logical and physical relationships of the software, more common interface tests, availability tests, and acceptance tests are also available. The trade-off between these tests and the test degree depends on the actual project (time, cost, etc.) and the individual experience of the test personnel.