Recently, I led the team to push forward the iteration and new version of the PMTalk product.

Around their own small program, and PC, as well as the client app3 forms continue to do debugging and optimization. If you’ve followed PMTALk, you know we’ve changed a lot in recent years.

For small teams or entrepreneurial projects, product acceptance can reduce the waste of resources and time, but also quickly put into the next link of work.

How do I do product acceptance in a team? Share my experience.

1. Know the difference between acceptance and testing

This part actually confuses a lot of small teams.

Because there is no tester or professional acceptance process, the acceptance and testing of products are all mixed up. Each time is the end of development before testing acceptance.

Acceptance and testing are two completely different things.

1. Test work

Software testing is the process of running or measuring a software system by manual or automatic means in order to verify that it meets specified requirements or to clarify the difference between the expected results and the actual results.

Testing is a revert to the product manager’s requirements document or test case. Even if the requirements document is faulty, including a logical problem not described, the test’s job is either to skip the test or to describe the faulty requirements.

As requirements begin to move into UI design, tests are included in the requirements review. Once the background, purpose, and general scope of the requirements are known, the tests output test cases based on the requirements document. The product manager is required to read through the test cases to determine whether the description of the use cases is accurate and whether there are missing requirements.

▲ A test case

For example, the figure above is the description of the test case, which describes the operation preconditions, postconditions and basic operation process under the function.

A functional requirement can involve hundreds of test cases, written in advance by testers and evaluated by product managers.

2. Product acceptance

The purpose of product acceptance and testing is completely different, but the process of product acceptance and testing will be repeated, but the purpose of product acceptance is only one

Whether the current product version can be launched or officially released. In small companies, there is no explanation of the review process, and versions can be released with the approval of the product manager and business leader, or the boss.

The product acceptance phase can reveal many problems, such as design flaws in features, logic errors, and even the most fatal failure of features to address requirements.

Our PMTalk will sort out the acceptance sheet, which includes the serial number, problems, screenshots, optimization description and resolution status as follows.

Resolution states are marked and synchronized by development. The rest is filled out by the product manager

▲ Acceptance Documents

Locate the optimization problem by the serial number, the BUG is classified as the current version, the optimization is attributed to the next version.

Bring BUG pool

The following fields in the BUG document are as follows

Solution status:

Whether the current BUG is solved or not is the key criterion for reacceptance.

Priority:

According to the degree of urgency and importance, four priorities are built, namely P1, P2, P3 and P4

Module:

Where is the BUG function located

Platform:

If more than one product or system is involved, you need to locate the BUG on that platform or system. If iFlyTEK’s voice capability is invoked and the client’s voice recognition capability is blocked due to no recharge account, the third-party platform’s capacity is due to the arrearage.

Problem description:

It mainly describes the logic problem, UI problem and copywriting problem, and gives the correct corresponding description. If complex logic and complex effects are involved, the communication needs to be reviewed in person.

Man:

The person who flagged the problem could be a business, operations, or product manager. In short, identify the person who is directly responsible for the problem, not the person responsible. Because a lot of times the person who is responsible is not asking

Question type:

The types of problems vary greatly depending on the stage of acceptance. For example, incorrect UI restoration is a UI problem, inconsistent with the requirement description is a functional defect, and common problems such as no response when clicked and jump errors are bugs.

However, most of the time, if the team is relatively small, they can be referred to as bugs, only the optimized ones can be listed separately.

3. The most difficult part of online acceptance is progress and status update

Almost every company has this problem

It is the problem found in the acceptance before the product goes online. If the update progress is not timely, it will lead to repeated testing and waste of resources.

Therefore, it is highly recommended that product managers use collaborative project management tools such as Zen Tao and TB. Update the status and number of bugs in a timely manner, and keep an eye on the developer and UI executor of the corresponding problem. Note that the person in charge is not the first executor.

Of course, projects and systems still rely on human management. A good R & D management system can significantly reduce the time to solve bugs, and the people who play this role are almost all product managers.

If you leave it all to the project manager or the person in charge of research and development, in fact, it is not a qualified product manager.

That’s all for today’s share.