Testing experience for a successful project

Sympathy tests during product development: Therefore, tests during product development should not be blunt. In fact, at this time, the program staff also know that the product is not mature, so they should tell the test execution staff:

● Do not submit simple UI errors or usability bugs at this stage (you can record them and submit them at the end of the project). Otherwise, developers may question the tester and only find simple bugs.

● Empathy, understanding that what developers are most concerned about at this time is whether the functions can run correctly, and testing the basic functions.

Positive product maturity testing:

As the product continues to mature, the implementation of the main functions has become more complete, and the testing of key paths is no longer a problem. At this time, the pressure on programmers has been greatly reduced, and their focus has also shifted from "building" to "fixing bugs". At this stage, programmers have the highest acceptance of bugs, the Bug fixes and feedback are also very positive. Therefore, the testing work at this time should cover all the details and paths of the entire product, ensure the comprehensiveness of the test, and thoroughly test each part of the product that is worth testing, discover as many bugs as possible.

Various tests of stable products:

At this stage, you can report product usability and interface bugs to developers. You can give full play to the imagination of each tester and build a test scenario based on previous testing experience, construct test data. You can perform diversified tests through different operations in different business scenarios, special test data, and a relatively complex cluster test environment. Why? At this time, you must test more deeply to find more in-depth bugs. Therefore, diverse testing and exploratory testing are essential. Careful testing during the product release period is approaching the product release day, and much of the work involved in the test has become cautious: the code submission permission is under control and only one entry from the Development Manager is retained; the focus of the test is more defensive. To test each change carefully, you can also organize a "pair test" to increase the test guarantee. The test Manager should be knowledgeable and considerate. To ensure the quality of the test work, the test Manager should first have a professional test team. In many small software projects, there are often no dedicated test teams. In this way, when the code is basically complete, you can only pull some staff from the customer support department or the R & D department to piece together the "test team" for weeks of testing, the test quality is hard to guarantee. We plan the testing team's staff structure as soon as possible to improve the configuration of the testing team. The characteristics and strengths of each tester are often different. For example, testers who are good at testing data quality may not be competent to configure complex test tasks in the system environment. In short, it is very important for the tested manager to be knowledgeable. At the same time, it is also necessary to make timely adjustments during project testing. The workflow system tested in this test requires the tester not only to have certain workflow business knowledge, but also to have strong logic thinking ability. During the testing of this project, I found that a tester was too concerned about the details of the function, but never understood the entire workflow. Obviously, the designed test cases cannot meet the workflow test requirements. As a result, the division of labor and testing tasks were adjusted immediately to ensure smooth testing. Adhering to our stance, our company has a strict testing process. All the software versions submitted for testing must complete the necessary smoke Test before submission ). Smoke Testing is a testing package that aims to check the basic functions of the version. This test package is extracted by the Tester Based on the test cases with the "Basic" Level in the test cases. if the version does not pass the smoke test, it indicates that the version is not stable, it is not worth submitting to the tester for system testing. Some companies perform smoke tests manually or automatically by testers. In our project, developers are responsible for ensuring the smoke test quality of each beta version. They knew that the test team would reject the version if the program could not pass the smoke test. Therefore, they enter a test application form to apply for a system test. In this table, not only the version number, modification or new features are described in detail, but also the testing focus of this version and the functions that may be affected are provided to the tester. These contents are of critical importance and benefit to testers.

During the project test, we also experienced a version call back and refused to perform the test. To sum up, there are basically the following situations:

● Due to the technical difficulty of task query, the development progress has been extended for five days. The tester is anxiously waiting for this part of function testing. However, this function cannot be used in new beta versions. If further testing is a waste of time, we immediately recall this test version.

● The agent function is added, but the Agent Function added in the past cannot be used normally, and the agent function added is the basis of the agent function, that is, in this version, the agent function can be tested in a timely manner, and the agent function can be removed. It is meaningless to perform the agent test.

● In the regression test phase, the submission of Beta versions is frequent. Once a developer solves a part of the bug, a beta version is submitted. If the tester does not need to change the version, and the other version will be completed in a few hours, we can skip this version. In order to better complete the key phase of Smoke Testing, testers actively cooperate with developers:

1. Provides smoke test cases.

2. If the tester is in the version wait stage, take the initiative to perform a smoke test with the developer. Effective tests and effective test cases are critical to the success of software tests and help improve test efficiency and test coverage. In this workflow software Test project, we start with the Test Model and combine the rich Test experience and professional knowledge to select effective use cases from a wide range of Test cases, use as few test inputs as possible to cover as many software requirements as possible.

3. gain the trust of programmers and communicate with developers in a timely manner. Do not form unnecessary hostility with the tested programs. Testing is more effective if you can share information with programmers, such as their plans, early drafts of design documents, and early prototypes. The sooner you get in touch with programmers, the better the situation. Give your comments and feedback as soon as possible to understand the work done by the programmer before submission.

4. Take the initiative to provide services ○ provide services directly to developers in the early stage of testing. This not only establishes trust, but also proves that testers can work with them. Services we provide to developers during the project process: ○ operational logic for workflows? The component is tested to facilitate the later development of workflow client applications. ○ For internal versions and original versions? Type. ○ Review the testability of the requirement documents. Like testers, developers have a headache for ambiguity and they are eager to get involved. ○ Help programmers establish a test environment to facilitate testing.

This article from the CSDN blog, reproduced please indicate the source: http://blog.csdn.net/zxz1337/archive/2008/12/18/3540261.aspx