I have been working for two years, and I have always hoped to deepen my understanding of testing every year. This year, although I have strengthened those concepts, my self-feelings have not changed qualitatively. A few days ago, I heard a test manager from our company talk about "Agile Testing". He's learning to build an airplane, and I've been learning to build an engine in an airplane. I never thought about what the architecture of a complete aircraft should look like.
If you want testing to play its greatest value in the company's projects, it is not to recruit two testing technology experts or introduce several testing technologies, but the penetration of testing technologies into the project process, as well as the improvement and perfection of the testing process. Although, of course, the testing industry has an optimistic outlook, and many small and medium-sized enterprises are also introducing testing, but there are 100 types of testing in 100 companies. Each company has different views on testing, and companies have different positioning for testing. I have experienced two companies before and after, and I will talk about my views on the testing process with my own humble opinion.
In the past few days, I have sorted out my thoughts and reviewed the process and structure of the first two testing jobs.
Simple testing process
Let’s talk about the first company I joined. I am the first full-time tester to join the company. I believe that there are still many companies with one or two tests. After joining the company, various projects are in progress. The position given to me above is not fully integrated into the project. And by assigning tasks.
Here is the crude flowchart:
Requirements analysis and architecture design :
What we are doing is a project used internally by a mobile company. The requirements analysis and architecture are all completed by the project manager, and then the project manager assigns tasks to a specific developer to implement a specific function module. This requires a lot of experience and technology for the project manager. Since he has served as a requirements analyst, he also serves as an architect.
Programmer coding :
Because our development language is JAVA language, the IDE uses the CVS version management tool that comes with myeclipse. After the developer completes the code, it is submitted to the repository.
Test :
The first task of the author after entering the job is to build a defect management tool, Zen Tao project management, and track the problems found through promotion. Later, the effect of Zhengming was not good, because for a development team project of six or seven people, developers prefer that testers can give feedback in person, which can improve efficiency. A small bug can be fixed through face-to-face communication.
For the environment at the time, there were no test lines. The developer deploys and runs the project on the local machine. The tester accesses the developer's machine through the local area network. Or deploy testing on the tester's local machine. This is also a fatal flaw. Because the computers used by developer testers have too many instability, these can cause problems, and sometimes it is difficult to determine whether it is a system problem or an environmental problem.
Online :
After the tester passes the test, the developer deploys it and goes online.
A programmer process
You will find that in the flowchart, programmer A is the first to go online, and then to test. This is our website for general users. The positioning for testers is testers and user experiencers. Testers submit the bugs and experience problems they find to the defect management system, and the manager analyzes the problems and assigns developers. solve. Update the system regularly.
Process analysis:
The only advantage of this process is that it can quickly find and fix problems.
There are many disadvantages. I believe that many small software companies have similar processes.
In this process, the project manager is the core, and the project manager is indeed an expert with many years of development and project experience. He likes to share some cutting-edge technologies from time to time. I adore him.
For testing, the requirements are very unclear, and test documents and use cases are also dispensable products. There is no requirement document, or it is very simple, and it is impossible to write use cases according to the requirement document. The author can only collect some general test cases, such as login, file upload and download, list page turning, date selection, input box verification, search, etc. There are some "universal" use cases for reference in the testing process. There are more functional tests, and when you get a function, the test idea will come out.
Standardized test process
Giving up my last laid-back job, thanks to the company that brought me into the business, I want to know how the real testing works in public. So, here comes this company. I'm glad that this test has its own team, professional (for me at the time) process, and equal status to development.
Current testing process:
Demand analysis :
Requirements analysis is formulated by product personnel. What they need to do is not a simple document, but to refine the details of each function, the location of each button, and model slightly larger or more complex requirements.
Requirements review :
Here, all the people involved in the project will be called to carry out, developers, testers, QA personnel. Testers put forward requirements, developers consider the plan and feasibility of function implementation, and of course the development is responsible for participation. Testers mainly question the understanding of the requirements so that they can write use cases according to the requirements. QA personnel are the ones who ultimately verify the software quality, so they also need to understand the requirements
The developer writes the schedule :
Developer requirements are scheduled according to the required function points. The open plan is then passed on to the tester.
Test Plan Schedule :
According to the development plan, the tester conducts several rounds of testing for the specific test time of the test, that is, the time after the development function is completed. Then, send the development and test plan of the project to the heads of departments and all the people involved in the project.
Write a test case :
According to the detailed requirements, start to write the use case.
Use case review :
Before the use case is reviewed, the use case is first sent to the relevant people in the form of email, so that they know in advance which functions are verified by the use case and the details of verification.
Then, the tester group conducts a use case review, the developers know what the use case does not conform to the actual function, and the product personnel grasp the specific implementation of the function through the use case, and so on.
Submit a baseline :
After developers complete all functions, they will conduct a self-test on their functions. Submit the tester for baseline after the self-test is completed.
Specific test process :
The developers test the functions from the base to the test line, and the problems found are fed back through the defect management tool. The developers fix the problems, and then prepare for the second round of bases.
After the testers complete the first round of testing, they need to write test conclusions and send them to relevant personnel. A second round after the baseline is then tested, which focuses on regression to the issues found in the first round.
Test passed :
After two to three or four rounds of testing, until no new problems are found, or problems that cannot be solved temporarily, or problems that are not urgent. Confirmed by the superior, you can pass. Write test report and acceptance plan.
The acceptance scheme is submitted to QA for verification. In the current company's process, testing is separated from QA, and the testers focus on whether the function is working properly. QA is concerned with the quality of the entire process as well as the quality of the end user. In some companies, QA and testing are indistinguishable, but this has higher requirements for testing. In addition to functions, it is also necessary to care about the overall process and quality.
Process analysis:
For me who just came into contact with this process, this process is standardized, testing is really integrated into the whole process, and it also plays a very important role, thus effectively ensuring the overall quality of software products.
So is this process perfect? No, this project process is too intensive with various documents. Let's look at the work content of the test, test plan, test case, test conclusion, test report, acceptance plan, and problem submission tracking. In fact, we really have very little time for testing. In a week, maybe only one day or less is in testing. A tester only shows his worth when he tests. And most of the work does not reflect his value.
Of course, I will omit things that have nothing to do with the main process of testing here. There are a lot of trivial things in the real testing work.
Agile testing process
Let's take a look at agile testing. I have not been exposed to agile, nor have I spent time learning and researching agile. The only contact was to listen to our test manager talk about the measurement process for two and a half hours. There were many people listening, and I stood and listened. Benefit a lot, just talk about it from memory.
The first process or the second process mentioned above are both waterfall-style. Strictly speaking, the first simple process cannot be called waterfall-style. For a three-month project, the product will be developed after analyzing the requirements. , and then the product will be fine; after the development is completed, it will be tested, and then the developers will not be busy. Go online after testing is complete. Then in the stage of product analysis, development and testing are nothing to do (only for a single project here). In the development phase, the product and testing are basically fine. Also in the testing phase, the product and development are nothing to worry about.
A core of agile testing is iteration, where all project personnel have something to do at every point in time.
1. The following is the flow chart of agile testing in my understanding:
Phase 1 :
Through the above flow chart, for a month's demand analysis, in agile, it may be determined in three or five days. This requirement will be very vague, but the overall framework is determined. The product confirms the function of one of the modules, and the developer begins to code the confirmed function. During the coding process, the test decomposes the function. Because it is difficult to write a specific use case according to the fuzzy requirements, we can only try to use the function as much as possible. Make the analysis more detailed and mark the content that needs to be verified.
Second stage :
After the development is completed, it is handed over to the testers for testing, and the developers continue to develop new functions. So what about the problems the testers found? A person is drawn from the development team to resolve issues found by testing. But development progress didn't stop because of testing.
Process analysis:
In this process, the documentation is weakened, and the communication between various personnel is emphasized. Through this iterative method, a three-month project may be completed in two or two and a half months.
But this process is not perfect, adding a function in the requirements analysis stage is wrong, because it is an iterative and gradual process. You can only go wrong all the way.
2. Handling of test problems
The above figure can clearly see the processing process of the problem.
The first panel is for the unimplemented functions of the developer, and the second panel is for the completed functions. Testers test them. If they find that they do not pass, they will be put back into the undeveloped panel. Those who have passed the test will be placed in the first panel. in three panels.
It should be noted that agile testing is very process in foreign countries. In terms of content, there is a lot of thunder and rain, and many people implement it, but few companies actually introduce it. Our companies are very different, and our testing procedures can be very different. For a tester who has been working for two years, never paying attention to the test process and structure should be a tragedy. I hope not to be limited by my thoughts, so I try to break through one limitation after another.