Basic process of software testing

foreword

"The sooner you intervene in the test, the lower the cost of solving the problem." With the development of software testing technology, the testing work has gradually developed from the original single defect finding to the process of preventing defects, exploring testing, and destroying programs. Testing activities run through In the whole software life cycle, it is called the whole software testing

Whole-process software testing, emphasizing the testing activities at each stage in the entire software life cycle. Whether it is the requirements stage, development stage, or testing stage, it is necessary to determine the content and Chengdu of the testing activities in the current stage to ensure the quality of each stage in order to ensure the final quality of the product.

Full software testing

Full software testing diagram

According to the timeline diagram of the whole software testing, we can find that testing activities run through the entire life cycle of software development, and the content of testing activities in each stage is as follows:

How is each testing activity carried out? What skills or methods are needed?

If you want to learn more about software testing, please don't worry about not having "software testing" self-study materials. Now I will offer you a 13G super practical dry goods testing learning resource, which involves very comprehensive content. [Private chat reply 1 to receive]

demand stage

1. Test requirements analysis

Personally, I have always believed that requirement analysis is the most important part of the entire testing activity besides test case design.

The purpose of requirements analysis is to understand the requirements and understand the business.
Find out what features our product has? What are the non-functional requirements?
Understand what our user group is? How will users use our product?

So how do we conduct needs analysis?

The specific implementation is as follows:

2. Formulation of test plan

After we have a complete and comprehensive understanding of the requirements, we need to develop a detailed test plan to make adequate preparations for the upcoming test work. For the understanding of the test plan, I have been divided into two work scales (personal understanding, please forgive me if it is incorrect)

small company team

The test team of a small company may not have many people. According to the traditional theory, it needs to consider all aspects of the test activities. It feels like killing a chicken with a 3-meter-long machete.

My understanding is that the test plan of the small team should clarify the following four elements.

Time: Estimate the time based on past experience and demand understanding (Small suggestion: 1 to 2 more days to buffer the time node, accidents will inevitably occur during the project)
Tasks: Split testing activities into specific tasks
People: the executor of the task and the person in charge of quality control
risk control

Big workshop team

　　The test team of a large company is often involved in multiple projects, and the allocation of resources such as hardware, time, and manpower for the entire company is more complicated. In this case, more detailed planning is required in all aspects.

Resource Estimation: How many resources will be required for the entire project? Hardware resources, manpower, time resources, etc.
Progress control: time point control of each test activity
Risk Control: Solutions for problems that arise during testing activities
Resource allocation: how to use resources more efficiently
Acceptance Criteria: Definition of acceptance criteria for documents, projects, testing processes
Test Strategy: The test strategy used in the test

summary:

In the requirements analysis stage, the testers must not only understand the product needs in detail, but also analyze the imperfections in the requirements from the user's point of view, and also coordinate development and testing for the consistency of requirements understanding, so as to ensure that the requirements information is in development. and test for unity in both sides.

This is to expose product defects as early as possible and effectively prevent defects.

development stage

After the preparatory work in the requirements phase, entering the development phase means rolling up your sleeves and working harder. The development phase is the most important phase for the software life cycle. So at this stage, how to carry out testing activities?

1. Test case design

Test case design is the soul of software testing.

The core of any testing activity is testing thinking, that is, how to conduct testing. The test case is the embodiment of test thinking. The test priority of the function, how to operate, what data to input, what result should be, etc. are all reflected in the test case. Then here comes the problem

How to design test cases?

(Due to space reasons, this time I will mainly introduce the interface test case design method)

First, let's take a look at the implementation process of the interface

Any interface is actually composed of these three parts, so we can consider this aspect when designing test cases.

Design for the input conditions of the interface:

Design the processing logic for the interface:

Designed for output results:

Other considerations:

Interface timeout processing
Obsolete interface processing

2. Test case review

The review of test cases is undoubtedly to check for leaks and fill in vacancies for test cases.

Evaluation method:

Test internal review
Project team review: project stakeholders participate in the review (development, testing, product)

Notice:

When the project team reviews, it is usually in the form of a meeting. Due to the number of test cases, the review at the meeting will take a long time, resulting in a waste of time and resources.

It is recommended that you send the test case email to the relevant people in the review meeting before the review, so that they can understand and be familiar with the test case in advance. Give feedback during the meeting, record it, and revise it after the meeting.

3. Test execution

If the previous work is done enough, it will be very simple when the test is executed. You only need to execute the program one by one according to the test cases. If a defect is found, submit the defect, and if the test passes, continue to return.

All the judges should have 10,000 XXX roaring in their hearts now~~It's not as simple as it is said.

In fact, the process of test execution is really simple, but in the process of execution, the collaboration, communication and output of various documents are very complicated. Let's talk about several aspects that should be paid attention to during the test execution process.

1. Communication between testing and development

"XXX I have a problem here, come and have a look" "What's the problem? Let me show you" "This is not a problem, this place can only do this" or "This is not a problem, I just confirmed with the requirements" "It's illogical!" "Then how do you deal with it?" "I think it should be... dealt with" "You should confirm with the requirements first."

This should be the daily life of test engineers. Communication between testing and development is undoubtedly about a certain function or product, mainly around the following points:

There is a problem somewhere in the program
Product requirements information is not unified in testing and development
How should a function of the program be handled
Verification after bug fixes

Now that we know the core of the problem, we have to find ways to avoid these problems. Assuming that the characteristics, location, operation steps, and screenshots of the question are submitted to the development at a glance when the question is first asked, will it greatly save the time for testing and demonstration?

Another problem that is most likely to occur is the inconsistency of information. This requires the entire project team to consciously cultivate a sound workflow, and use the workflow to avoid this information asymmetry. This situation will greatly increase the communication cost of testing and development.

2. Communication between testing and requirements

The difficulty in communicating between testers and requirements is mainly reflected in unclear requirements or changes in requirements.

In many cases, the requirements documents of the requirements personnel are not comprehensive. When writing the test cases, the test personnel need to confirm the requirements again and again. After going back and forth, the requirements are estimated to want to put a 40-meter-long knife on the table.

On the other hand, during the project process, there will inevitably be changes in requirements. As long as there is a change, it means that the previous test preparation work will be invalidated.

Therefore, the communication with the requirements is very frequent and sparks are scattered, so how to better communicate with the requirements?

Remember not to stay in verbal communication, confirm
All requirements confirmation or requirement changes need to be documented, and if it is not possible, you need to send an email
Every confirmation and change needs to be approved by project stakeholders
Establish a complete demand change system to control demand changes in the process

3. Feedback on test results

I believe that everyone should have encountered occasional defects, and they disappeared when the development reappeared. After working for a long time, I was disgusted by the development

The problem with the feedback of test results is that the results are not clearly described, which increases the time and communication costs of the project. The best way to solve this problem is to describe the test results as clearly as possible.

There are two types of test result feedback:

Feedback bugs to developers in communication tools
Submit a defect in the defect management tool

How exactly do you file/describe a bug? In the following, I will introduce in detail.

4. Defect Management

During the development phase, the most important output of testers is defects. Defects are not only more in number, but also more valuable. More attention should be paid to defect quality, defect management, and defect analysis.

How to raise high-quality defects? How to manage and analyze defects? See below

Defect Handling Flowchart

Defect management is an extremely important part of software testing activities. In many cases, many defects are not found in the test cases. Instead, many defects are found in the process of running the program. These defects are the supplements to the test cases. can provide ideas.

summary:

In the development phase, the main job of testers is to find defects, but this process will be accompanied by many other problems that we need to avoid in the workflow. The most important thing is to put the test in the whole project, which is the teamwork of various departments.

The problems of many teams do not lie in test case design, test execution, and defect submission, but more in the communication and collaboration between various departments.

release stage

Entering the release stage means that the product has passed the test and can be released online and delivered to users. So how to confirm that the test has passed? What tasks do our testers need to complete during the release process?

Test Pass Guidelines Specification

Before going online, it is necessary to confirm that the test has passed. Now that the program is getting more and more complicated, if there is no quantitative specification, it is difficult to determine when the test can go online. So we need to set the criteria for passing the test, and only when the criteria are met can we go online

100% functional coverage of test requirements
The test case pass rate is over 95%
Remaining defects have no defects of severity level 3 and above

testing report

After the test is completed, submit the test report and give the data during the test, such as: the number of test cases, the total number of defects found, the number of defects of each severity, the total number of repaired defects and the defect repair rate, etc.

System rollback scheme

Every release cannot be said to be 100% problem-free. If there is a problem, how should we deal with it?

If the online problem is not very serious, try to deal with it at that time and then go online
If the online problem is serious, the system must be rolled back to ensure the normal use of online users
The system rollback plan must be confirmed with the development/project manager

Online function check

Regression testing of the original function of the program
Comprehensive testing of newly launched functions

summary:

After each release, testers should continue to give feedback, improve and summarize the problems encountered in each version, whether it is a defect or a process problem, sum up some experience from the problems again and again, and improve the quality of the entire software life cycle

Routine maintenance phase

After the product is launched, users can use it stably for a long time, which means that the released functions have entered the stage of daily maintenance. And this is not the end, this stage will always exist.

At this stage, the main work of the tester is relatively simple

Continuous testing, no product is without defects
Even collect user feedback problems, and organize personnel to fix them as soon as possible
Long-term stability test (automated test)

Summarize

Whole-process software testing focuses on testing activities at various stages throughout the software life cycle.

By controlling the quality of the process at each stage, the quality of product testing can be improved. The quality of the product is not determined by the test, but by the entire project construction process, through the optimization process again and again, and the continuous summary and growth is determined by the entire project team.

Different types of work play a pivotal role in this process, and the whole process of software testing emphasizes continuous improvement of the quality of each stage, and ultimately improves the comprehensive ability of the project team, thereby improving product quality

Seeing this, thank you very much for your patience. If you feel that you have gained something, please remember to share it with me.