Talk about software testing

During the recent group discussion, I made some conclusions on the project work process. I also made some thoughts on the projects I have experienced.
The success or failure of a project is measured by the software quality. Software testing is related to the software quality, so I will talk about the software testing I have experienced.
(Note: it is purely a personal opinion. Different companies, projects, leaders, and software processes are different)
In a software project I worked on earlier, it was still a strict cmme process. A project team is divided into two groups: Development and combination test groups; development and test teams perform their respective duties. The test and development process goes hand in hand: Requirement Analysis (requirement analysis)-> test specification (design specification)-> Test Plan (development plan)-> Brief Test Plan (outline design) -> Test Solution (detailed design)-> test cases (coding, unit testing)-> integrated testing (joint debugging)-> cycle (system testing (bug solving )) -> regression testing (patching)-> acceptance testing...
In today's era of agility, project processes have basically entered the Agile Model. In agile project teams, development and testing are simply mixed into one team, and there is no obvious development test, only different members select different tasks according to their preferences. Agility usually takes three weeks (two weeks or one month) as an iteration cycle. The testing work is divided into small tasks based on requirements, usually completed in one or more iterations. The purpose of iteration is fast delivery, and the testing tasks and product quality are also enhanced with continuous delivery.
As the process continues to be standardized in the industry, the processes at home and abroad are basically the same, but they will be different in implementation.
Let's talk about the advantages of the process: the process must be a summary of experience, and it is better to go through the process. The most memorable process is writing test cases. In a project, the project manager strictly requires writing test cases (based on the estimated code ratio ), seven or eight use cases (null value, boundary value, extra-long margin, garbled characters, etc.) are required for verification of a single parameter ...), At first, I thought it was time-consuming and meaningless. When testing was really executed, I realized that many previously written use cases could not be imagined, and I was inspired to create new use cases, as the coverage rate increases, I feel more steadfast.
Sometimes, in the face of progress and quality games, the process is often abandoned. In my above-mentioned standard cmme project, the detailed design review has not passed, and the planned time has arrived. The project manager gave a single order: the detailed design has passed for now, so start writing code. In the subsequent testing phase, a pile of bugs are traced back to unsolved issues in the detailed design. Later, I wrote a document, changed the code, and tested it.
Agile, sometimes also changed. Each Agile cycle has A goal. When the cycle ends and the goal is not reached, I have experienced two completely different ways: Company A, working overtime; I can't make it, continue working overtime; sometimes, the three-week iteration ends after six weeks. Company B should end as usual and summarize the reasons for failing to reach the goal.
Regardless of how the test process changes, the test method will not change: manual, reference model, automation, continuous integration, performance, real-time testing, and so on. Here we will mainly talk about the reference model, because the reference model is very "expensive" and will not be used in general projects. The reference model is to select a group of developers or testers to implement the same system in different ways during the development process. During the test, the tester enters the same interface and compares the outputs of the two systems. The output results are consistent. During the development process, the primary development team and the reference model team are isolated.
In a project, the quality of projects with strong automation capability must be better than that of non-automated and semi-automated projects. Today, more and more companies are focusing on automated and continuous integration testing. In a project I have worked on, functions, systems, performance, and continuous integration have been fully automated, and the test code and application code are linked together, every change to the application code, and every incomplete consideration may lead to a full-blown change to ensure the absolute security of the basic version.
The advantages of automation are self-evident. However, it is difficult to maintain automation and to have a sufficient understanding of the system. Testers must be stable in order to communicate effectively with developers. The quality of non-automated testing products is determined by people. The randomness of people is too strong. Loss of data and resignation will lead the test execution to another place.
As testing is becoming more and more important, testers are increasingly demanding. The software testing engineers and software testing engineers have a wider path to development because they need to contact customers to understand the system business, system operating environment, and the relationship between coordination and development and O & M, it is easier for testers to go to the market and manage in the future. The most basic qualities of a tester are: rigorous, detail-oriented, but not perfect, perfect, and continuous learning.
In the era of high cost savings, the test process is often determined by your mind. Many project managers, regardless of the thinking and willingness of the test and development personnel, are in the initial stage of the project, testing is often used for development, and later development is used for testing, regardless of the process. However, in a mature team project, the process will never change. The process will only be optimized and improved. In the face of problems, we have been summing up, solving, and moving forward.
......
I wrote this article because I used to perform tests for a while. I vaguely remember that I was in a mobile machine room surrounded by hundreds of servers that year, it is accompanied by cold, noisy, and radiant performance tests.

 

Talk about software testing