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

The main reasons for frequent changes in requirements are:

1. The preliminary demand research work is not in place, and there is no real in-depth understanding of what users need during the demand research. What is the purpose of the user doing this? Why would you do that?

2. The project manager has sufficient control over the project, and does not adopt centralized change or phased change under certain project requirements;

3. The client didn't know what to do at the beginning? As the system takes shape and goes live, some new ideas are proposed, etc. resulting in changes in requirements.

4. The customer is God, so some changes are necessary.

How do testers respond to change?

1. Coordinate change specifications, such as e-mails sent by requestors each time, so that developers and testers can work on them. If this is not possible, it is recommended that the change information sent to the developer be copied to the tester at the same time, so that the tester and the developer keep the information basically consistent;

2. Understand the scope of requirement change, organize and record test requirement change in time, record requirement change information in time no matter what way, and notify relevant personnel for confirmation in time;

3. Ensure that the team understands the risks involved in requirements changes, especially in late iterations.

4. If possible, keep demand changes to a small margin by negotiating or implementing changes for the next iteration;

5. Before each test, a more detailed test task list should be prepared, and the focus of this test should be indicated [which requirements are changed and which requirements are added], and relevant personnel should be asked for confirmation.

6. Keep a log of test work every day, mainly including [1. Problems encountered in testing and their solutions (which can form a test knowledge base), 2. Record test tasks and their work results (mainly record what you did today? What was the result? 3. Record the progress of the test (record the progress of the individual or team; this way, after a long time, you can basically evaluate the test module, the process, and how long it takes for which type of problem, so as to make a plan for future work), 4. Record test problem summary, etc.(classify and summarize problems, knowledge base for a long time, places that need to be strengthened in the future)]

7. The tester should treat the requirement change as a normal project and deal with it normally. It is almost impossible for any project to install the expected development plan, so change will be a normal part of our work.

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.