What is "review" in a software testing project?

Preface: You must have heard this saying: Every day is either in a meeting or on the way to a meeting. This sentence is actually a way of ridiculing the number of meetings, and at the same time it also has some disgust. Have you ever thought about why we dislike some meetings? Think about it carefully, are these meetings efficient? This article will talk about one of the more important types of project meetings - review

Meetings, the necessity of review meetings, and how to conduct review meetings efficiently.

1. What is review?

Review refers to evaluation, review, and deliberation.

So why review?

2. Why do we need to conduct evaluation

1) Review is generally a collective activity, which helps to improve the quality of the work product (i.e. the review object) from multiple perspectives.

Participants in the review may include project stakeholders, technical experts, business experts, and senior managers. Different participants have different roles and different perspectives on the work products.

For example, in actual projects, when reviewing test design documents, product managers are more concerned about whether user requirements are fully covered, developers are more concerned about whether their understanding of requirements is consistent with testers, and test review experts are more concerned about business functions In addition to whether it is covered, we will also review whether the test design method is reasonable and whether each quality attribute is considered.

2) The review meeting can provide an opportunity to discuss and align some controversial points and achieve unified thinking.

For example, when reviewing the requirements specification, multiple project stakeholders will be present. On the one hand, each customer requirement can be clarified. On the other hand, each reviewer can raise questions about the requirements or document from their own professional perspectives. Aspects not covered.

For example, for an APP , the product manager explains the requirements for user registration/login at the requirements review meeting. Because testers have rich experience in using APP, they will ask more detailed questions about this requirement: whether the user first registers and then logs in or logs in and registers, whether it supports both verification code login and password login, and the validity period of the verification code. How long is it, how long is the authentication time for a user to log in, whether there is a portal for users to cancel registration, etc. Subsequently, the participants will try to reach a consensus on these newly raised demand points. If they cannot unify their views at the meeting, the minutes of the meeting will be recorded and the loop will be closed after the meeting.

3) It is difficult for the author himself to discover problems with his work product.

I once saw such a point of view in a book, which I think is very reasonable: because you remember your process, you will think that your work is correct.

In fact, this is caused by people's specific way of thinking and output process when outputting products. No matter what the output is, your process is usually: come up with an idea, then follow this idea, and then implement the idea into results. Therefore, your way of thinking has always been positive and sequential, and you are so familiar with the whole process that you think everything is correct. Of course, this is also mixed with a preference for your "baby".

At this time, the role of the reviewer is to find some people who don't know what the output process of your product is like, and they won't be involved in emotions. At this time, their evaluation will be objective.

In addition, everyone must have had the same experience. How do you like what you just wrote? However, when you have passed 1-2 months and gradually forget about it and the process of producing it, you may find many unreasonable or even wrong places.

4) Review is a static test and is cost-effective. This activity can expose problems in advance, and the testing cost is lower than dynamic testing, and the repair cost is also low.

For example, if during the requirements review stage, it is identified that the customer requires support for two payment methods: WeChat and Alipay, and the requirements document only mentions WeChat payment, at this time, you only need to update the requirements document; however, if it reaches the coding stage If the vulnerability is not identified until later, it will cause coding rework and even architecture adjustment; if it is discovered later, during the testing phase, it will lead to a greater amount of rework and have a more obvious impact on the project progress, which is extremely dangerous. It may lead to the failure of the project; if it is later, what if the user raises the issue after the version is released for users to use? What will be the impact? What is lost?

It can be seen how low the cost of correcting mistakes in the review stage is!

So, under what circumstances do review activities need to be initiated? What are the types of reviews? Here are just some common examples.

3. Types of review

1) Work plan review

Mainly including project plan, development plan, test plan, etc.

2) Design document review

Outline design, detailed design, test design

3) Code review

Version development code review, automated tool code review

4) Management review

Version release review, defect review, risk review.

4. How to better conduct reviews

The review itself can be seen as a special meeting. If you want to be more efficient, it is very important to make adequate preparations before the meeting, efficient review at the meeting, and strict closed loop after the meeting. Listed below are several factors that are critical to a successful review:

1) The author of the review object has completed the first draft (the first draft that meets the review conditions)

Just like software products, if the review object does not meet the entry requirements, it is only a semi-finished product, which will waste the time of the review personnel and even affect the project progress.

2) The subject and purpose of the review have been clarified

If the subject and purpose of the review are not clear, you will end up talking about topics unrelated to the review object during the review meeting, which is a waste of time. For example, in a decision-making meeting to review whether a software product can be released, if the purpose of the review is unclear, development and testing may be discussing the causes of bugs, deviating from the theme of the meeting.

3) Determine the time and place of the review, as well as the participants, organizers, moderators, and record takers

The list of participants is inaccurate, and some important key personnel may be absent from the review meeting. If the person taking the minutes is unclear, important information at the meeting will not be recorded in a timely manner, resulting in an inefficient or even ineffective meeting.

4) Meeting materials are distributed to participants in advance and sufficient time is reserved for independent review.

You can imagine what a hastily organized meeting without enough time to browse meeting materials will look like: participants did not see the relevant documents for the first time until the beginning of the meeting; during the review, they often stopped to understand what the document wanted to say. Such a meeting, like the blind man feeling the elephant, is simply a waste of time.

5) At the formal review meeting, the review host must have sufficient organizational coordination and communication and solution capabilities to ensure the order of the meeting and control the efficiency and effectiveness of the meeting.

6) During the formal review meeting, all participants actively put forward their views and discussed actively, with the same goal.

7) After the meeting, send the meeting minutes to the participants. The person responsible for the recorded problems is clear and the closed-loop time is clear.

Although the review itself is cost-effective, an overly casual review is nothing more than a waste of time and a mere formality. I hope that everyone will make full use of the sharp weapon of the review meeting in the actual project, and be invincible!

2023 latest Jmeter interface test from entry to proficiency (full set of practical project tutorials)

Guess you like

Origin blog.csdn.net/mashang123123123/article/details/132153200