Feel the hardships of the project and desire a happy project-H Project Summary 5. Project Quality Control

Project Quality Control:
The system test of Project H started from to. The full-phase participation includes: Project Manager, Technical Manager, 5 developers, and 2.5 testers. 2.5 people/month in total
User testing started from to. Full-phase participation includes: Project Manager, 2 testers, Technical Manager, and 4 developers. A total of 28 months. Two months in total, on-site implementation and testing were conducted. The following problems exist in the test phase:
1. there is no effective quality monitoring means in the development phase. Most of the quality problems are found and solved during system testing and user testing, so that the total duration and workload of user testing are too large, this reduces user satisfaction.
The causes are as follows:
1. The Plan formulated in the preliminary contract is too idealistic. By entering the coding stage, the progress will start to lag behind. We are required to work overtime, close development, and other measures. Although the progress has been accelerated, at the same time, it also leads to a decline in quality control in the development phase;
2. No code is executed during development. This is also a stage of quality compromise under the pressure of progress.
3. In the development stage, the developer's self-testing effect is poor, and the code cannot pass the smoke test in the development stage (that is, the tester will encounter a problem that causes the test interruption when testing, unable to continue testing); in the system test and user test phase, developers solve old problems while generating many new problems, and did not find and correct the problems during self-testing, this reduces the efficiency of quality improvement.
* *** Suggestions (the following suggestions do not involve the preparation of the plan, because the questions about the plan have been discussed in the previous summary, but only the methods for improving the quality are described ):
1. Emphasize that developers must pay attention to self-testing. The technical manager should also monitor the code quality of developers. It is best to organize code details and identify and correct quality problems early through code review.
2. Add a smoke test to the daily build. Developers are required to arrange the development work according to the standards that must be passed in both the daily build and smoke test. Emphasize that developers must pay attention to solving the problem of smoke testing. It is best to require Smoke Testing every day (at least twice a week). It is best to automate smoke testing.
3. We recommend that you use test-driven development and perform automated Unit Testing in a small project led by the technical backbone. And then gradually promote other projects.
 
2. Test cases are not continuously improved, resulting in uncontrollable quality of test work and reduced efficiency of software quality improvement. After the outline design is complete, the tester starts to write test cases in TD. Because of the lack of experience of testers and the lack of software that can be run at that time, the quality and enforceability of the test cases written at that time were not high, and the actual test software was used during system testing, I have a better understanding of the software and test cases. However, due to time constraints, I have not improved the test cases. As a result, the subsequent rounds of System Tests, there is no basis for measuring and evaluating the quality of testing, making the testing work in a chaotic state.
* *** Suggestion: test cases should be continuously improved during the test process. Only by documenting test cases and recording the execution results of test cases can the quality of test work be measured and improved.
 
3. No performance tests were conducted during the development phase, and serious performance problems were exposed during the first round of tests. The negative feedback from users was strong. The data size of the most commonly used basic material information in the user-tested database is 30 thousand. A public view of the system accessing the material information has a low performance when the data volume is large, this results in poor performance on many interfaces of the system.
* *** Suggestion: in the development phase, testers need to work with developers to simulate the establishment of more data in the Development Library. Perform stress testing in a dedicated stress testing database. If this work is done, although the development stage needs to increase investment by 10 person-days, but it can improve user satisfaction.
 
4. Insufficient testing manpower during coding, system testing, and implementation. During the entire project cycle, there were only two full-time testers. The Project Manager focused on communicating with the project team, compiling the code for settlement and bar code import, and communicating with the customer on-site, write entrance review and acceptance review documents with less effort allocated for testing. Therefore, from the development stage to the end of user testing, the testing team has invested less than 2.5 people. Insufficient testing manpower leads to unsatisfactory overall testing quality and progress. It is reasonable to test the manpower of four persons in Phase II of Project H. In the future, we recommend that you test the ratio of manpower to development manpower.

This article from the CSDN blog, reproduced please indicate the source: http://blog.csdn.net/pekingsun/archive/2007/04/24/1583413.aspx