No requirement documents, a feasible approach to ensure test quality

The content of this article is: In the absence of requirements documents, what should a tester do to ensure that there are no problems with test quality, and how not to take the blame?

001 There are three possible situations when there is no requirement document:

1. The company does not have a product manager, and developers have insufficient awareness. After receiving customer requirements, they can directly start work (write requirements documents? Impossible).

2. The project progress is tight, the requirements are changing greatly, and the product is lazy and the original requirements document is not updated.

3. The project is developed iteratively from the original old project, and the developers believe that a requirements document is not needed.

For the above situation, the theoretical approach is as follows:

1. The person in charge of testing should adhere to his own principles: if there is no requirement document, he will not be tested.

2. The requirements documents must be reviewed, the review meeting minutes shall be kept, and specialized personnel shall modify, update and confirm the requirements documents;

However, the reality is.

Many times, the above theory cannot be implemented (of course, it is better if it can be implemented, and it should be implemented; this article is mainly aimed at feasibility suggestions for those cases where the requirements document cannot be continuously updated).

1. The testing team has no say at all in the company. It is difficult to write requirements to promote the product.

2. Moreover, many times, the entire technical team serves the business. Time is tight and the tasks are heavy, so everyone needs to be more proactive.

Therefore, it is difficult to implement the above theoretical situation in practice.

Without requirement documents, it is too difficult to write test cases (it is even harder to ensure the quality of the final launch).

As a tester, if there is no test requirements document, don't wait stupidly. You should take the initiative and learn as much about the project as possible. The more you know, the more test cases you can write.

Author: IDO Lao Xu

Source isTster.com

002 Implementation method when there is no demand

The following is the feasible approach given by IDO Lao Xu based on his own experience for reference:

1. Try to find other relevant documents, such as original fragmentation requirements meeting discussion minutes, planning documents, development documents, market research documents, feasibility analysis reports, etc.

2. Participate in as many internal discussion meetings (requirements, design, planning) as possible, participate in the discussion process, and further understand the requirements.

3. Consult relevant personnel: projects, markets, business, R&D, customers

4. If it is developed based on an old version, use the old version more and explore your own needs (you can also look at the historical bug library and use case library)

5. Refer to similar products from peers or competitors (in fact, product managers also refer to similar products when planning original requirements)

6. Finally, based on what you learned above, sort out the demand points you understand, gather relevant people, touch on them (projects, development, products, markets, business, etc.), check for omissions and fill in the gaps, and correct some of your mistakes. Needs understanding.

7. The next thing, the test students, should all know: based on the needs that have been sorted out and determined by themselves, sort out a reviewed test demand points, and finally design the test cases.

In short, one principle: when there is no requirements document, take the initiative to understand, sort out, and push back.

003 Many times, demand comes from customers

Customers reported to marketing personnel (or customer service personnel) that there was no product manager position within the company. After receiving the requirements, they could just rely on their own imagination and start work directly (this is a typical way of doing things for small workshops and small teams).

If it is a vague demand that requires customer response, you can either test the direct connection, or sort out the doubt points and let the market personnel connect them (maintain the original external process within the company, and it is best not to mess with the skipping process).

As for the method, it can be very flexible, such as (email, WeChat group, etc., offline appointments are also possible).

004 There are some feasible methods for quality assurance

1. Development self-test

2. Let the product manager join in to confirm and accept the requirements after the product is proposed and tested.

3. Design restoration after product testing, let designers join in, confirm and accept together.

As for, as mentioned above, how to implement it, this has to be done internally and added to the regular R&D process.

You can let the quality leader, R&D leader, or technical VP promote it.

This matter is feasible and can be implemented.

The following are supporting learning materials. For those who are doing [software testing], it should be the most comprehensive and complete preparation warehouse. This warehouse has also accompanied me through the most difficult journey. I hope it can also help you!

 

Guess you like

Origin blog.csdn.net/2301_76643199/article/details/133079254