Product testing based on user usage scenarios

Product testing is generally based on demand-oriented product requirements design specifications PRD documents to expand the test, for each function point to write test cases, to verify the correctness and integrity of the function. This way in the normal development of the online progress will not be a problem, on the contrary is a good way to verify the implementation of functional requirements. But in the agile development model or because of the reason for the progress, the product testing time is very tight, in this way will be a little stretched.

User-centric product design has gradually become popular, product theme features to meet the needs of users or to solve some of the user's pain point, but also said to be the user pain point as the center of the product design. In this background, after the product development, if the test time is very tight, can not guarantee the product no problem but must be on time on the line, we must ensure that the product in the user's use of the scene without problems, that is, the priority to ensure that users use the product throughout the process will not occur, This is the product testing method based on the user's use of the scene.

In the actual testing process, the most common is based on product functionality testing, which is based on user scenarios of product testing what is the difference between the two? The difference is that the latter test range is smaller, ignoring a part of the product background function test or implicit functional testing, that is, only to test the surface operability of the process, There is no underlying function of the test; the second is that the latter test is to transform the product function into the actual user to use the scene to test, which requires the tester to start from the ordinary user's operating angle, and can not be affected by the developer, to a first-use product user angle, To verify that the functionality of the product can provide a normal service during use.

The point to note here is that, in the case of time schedule, it is also necessary to test the product functionality in order to be able to cover all aspects of the product to ensure that the product can provide a complete service. The product testing based on user scenarios described in this paper is built on the premise of very tight test time. Because of itself this test method because the test is not comprehensive enough, there is a certain risk in the inside, to the product is not necessarily good, just to ensure that the product release time, and take a more eclectic test method. The use of this test method requires the following two elements, otherwise it is best to do a comprehensive product functional testing.

Very tight test time

In fact, this scenario is very common, the project schedule, often because the demand analysis of the time is too long, or the development of time delay, resulting in a very small number of time to leave the tester, then if you have to ensure that the project on-line progress, you can not complete the comprehensive product functional testing, You can only test the process of the functional modules of each product used in the user's operation process. Sometimes it is due to the lack of testing resources caused by the test time is tight, testers in these situations can be considered based on user scenarios, but must be with the project manager or leader of the leadership to clear, is to ensure that the project progress of the priority test users to use the product process function.

Test from a fool's user's point of view

In this way, testers must start from the user's perspective, not from the developer or product manager's perspective. It is also that testers must maintain the relative purity, can participate in the product functional requirements of the review, but should not participate in the development of the system design review, or will be affected by the way developers implement, resulting in subsequent testing is inaccurate. Should be on the basis of ensuring understanding of product functional requirements, as far as possible from the common user scenarios, to find out the use of process issues, so that the developer priority to solve, this time testers do not need to talk to developers and the problem, just tell the scene of the problem can be as far as possible from the impact of outside information.

Under the conditions of the above two factors, testers have to put aside their own computer professional literacy, as a popular user, so that the results of testing closer to the real use of the scene. Since this test method does not cover the full functionality of the product, will result in a certain risk after the release of products, since the knowledge of such risks, we need to try to avoid or reduce the corresponding risk, which requires the entire product team, but also need to test the personnel have a complete set of test system.

Self-Test and code Review for developers

After development, developers need a round of self-test to reduce code risk and functional flaws, and to reduce the time for subsequent test validation and bug modification. Self-test in the process, need to be combined with product manager's needs, in order to achieve the first round of functional verification, once there are problems in the timely solution. Developers are also the most familiar with the underlying structure of the staff, some of the underlying functional problems can be detected in the self-test process to find solutions, as far as possible to ensure that no major problems left to the test phase. Self-test is also a developer's ability to improve the level of a good opportunity to improve the quality of the code, but also to improve their own code to write the degree of responsibility of a way. Self-test is based on the ability of the developer's own level, in addition to the cooperation of the team, such as the agile development model in the emphasis on the development team's internal code Review, a developer of coding, by the other two more experienced developers to jointly check, This can also reduce the code defect to a large extent, and discover the problem as early as possible.

Testing from the perspective of user use

Based on user scenarios can not guarantee that the product is not a problem, but must ensure that the product in the user's use of the process is not a problem, which requires testers from the user's point of view, really according to the user's operating procedures to operate the test product function. And then the time to write the test case, set aside to understand the functional requirements of the product in order to identify the functional points in time that do not meet the requirements in the course of the test, because this type of function point in the test will not be wrong, but it is not designed in the requirements specification, which requires testers to fully understand the requirements. It's not that test cases don't need to be written, but in the process of testing, relying on the test tools to record the process of testing, and later to organize this part of the use case. Since this test phase is over, the follow-up will continue to verify the overall functionality of the product, including the underlying functionality, at which point the test case documentation can be written together.

From the user's use of the scene to test the need to test the user to use the product of the way there is a certain understanding, such as the financial system and ordinary business system in operation when the difference is relatively large, because the financial system by foreign mature financial system product impact is relatively large. This requires testers to more understand the user's use, of course, the process is also based on the product's own functional structure design, do not rule out some need to cultivate user habits of the function, this function requires the Product manager to do some special instructions to enable testers to understand the intent of product design, It is best to provide a product operation manual.

It is also mentioned earlier that this type of testing is risky, requiring that the remaining functionality be tested after the release of the line, rather than the end of the test process. In the subsequent testing process, you can verify the remaining issues, and in the next rapid iteration of the online solution, so that the product's functional risk to the minimum, so that products provide a stable service.

Tests based on user scenarios are not currently applied in many ways, and there are applications in fast iterations of entrepreneurial products or agile testing in agile development mode. Although there are some flaws in this way, but is a very good alternative, can guarantee the project progress in the case, can also ensure that users in the use of products without problems, so that the product in the hands of the user no problem, this is a product to release the purpose, in line with the requirements of product release.