I am a test manager for the past two years to do two things, build a team from 0-1 and the transition from QC to QA. This year is no great stories, it is again attempt - failed - the process of trying.
COMPANY BACKGROUND
past two years, the main job of outsourcing. The customer is the central level, we finish the project had to be checked and accepted their test, the test more than two should be fine. They are the standard by no more than three general questions, no more than five minor problem.
The first failure - aggressive left
team building, I wait until the first new project A. This project for me and my team, is critical, we need to give this project a benchmark for their own tree, a good beginning.
So I put the past two years, I think the most effective test solutions to your project - testing left. In cooperation with the project manager, the project will be split according to the module, and in line with the development plan and developed a test plan, everything is orderly progress of the. As the project progresses, it exposed a fatal problem out - rework. The overthrow redo a lot of work, the project cycle was delayed more than a month. , Test and development team spent constantly reworked in more than a month in. The final project delivery quality is dismal - Acceptance of five.
After the end of the project, I reflect on the reasons for failure:
1. Test radical solution : where there is sufficient awareness of the overall difficulty of the project team and the project's ability before, hastily chose the most radical left, resulting in test work rhythm disorder, continually rework late in the process, also a member of emotions great influence.
2. Split scientific milestone : after making a good development plan, matching the test plan, simply consider only the completion of which will test what. It did not take into account the problem of coupling between modules, without considering the effects of the bug behind the development and modification of the work has been completed, also contributed to the return to work of the main reasons.
3. Change out of control : the needs of this project back and forth dozens revised edition, part of the customer is frequently put forward new demands, partly because during the pit were found myself in the project, had to pit again and again fill . Change out of control, it is bound to cause endless rework and delays.
4. underestimated the difficulty of the project: the initial project test data for a logical aspects of the project design of the data model, but with the deepening of the project, testing and development agreement reached being constantly overturned, even before the final delivery of core data logic testing and development also found some differences.
Twice missed the opportunity to remedy
- The first time rework occurs, do not realize the root of the problem, still arrange follow-up test of the whole staff. Missed the opportunity the first adjustment programs;
- Changes in the frequency of abnormal performance is not the same depth of mining problems, we are still blind a road go black. The second missed opportunity adjustment programs;
to sum up:
- All programs must rely on to determine the full understanding and analysis of the environment, each project is unique, blindly apply will die miserable;
- Not every problem is a case, there must be a hidden reason behind it, in-depth mining problem to avoid more problems.
Second failure - not flexible "flexible"
Team formed at the beginning, a parallel project is a big challenge we face. So on project B, I tried a flexible team of the Leads, hope to achieve pluggable personnel.
In project B, each stage of the development is completed, I will try to replace a tester, want flexibility in the face of the project team workout. Testers involved in the ins and outs of the project B has five, the last delivery of quality is also a five acceptance.
Is a familiar scene, there are different reasons:
1. blind item : personnel changes will inevitably result in the project for blind and needs, each person is responsible for his or her stage and modules, even do more, still not enough to cover the entire project to the blind, blind to Bug hotbed;
2. Everyone no responsible person in charge = : when all involved in the project knows I only work for a short time in the project, when asked all those involved in the project is responsible for the project, that no one would be responsible for the project;
3. testing is failure: after the issue of customer acceptance do the whole analysis, found that 75% of the problem because we do not align to customer acceptance criteria which, if compatibility requirements, requirements documentation requirements, user scenarios requirements, we have been ignored a.
to sum up:
- Flexible pluggable, does not mean that everyone needs frequent change, 1 + N model will be better. That is, a person in charge, together with the N adjustable testers;
- Each project has one and only one person in charge is responsible for the project, the everlasting truth;
- Standard alignment is always the top priority, to give watermelon sesame things do not dry.
The third failure - the cost is king
The company's projects are all functional test, in line with product quality and enhance the quality of the team's mind, began to advance interface testing. After training to the team made two basic concepts plus tools used to find a project manager selected a period of relatively liberal project began interface test trip. The whole process in line with expectations, two weeks to finish the entire contents of the use cases designed to test. Found some project problems, the team also gained practical experience. But still failed, the failure is not the project failed, but the interface testing is not to promote it.
For this reason it is even more grim: the
1. Cost pressure : interface test intervention and did not reduce the time function tests, an increase of more than a dozen people days are additional costs. Enhance the quality of the project because there is no comparative data, it is not reflected;
2. Pressure cycle: test requires a more comprehensive interface documentation to support the test. Theoretically interface documentation should be defined in the design phase of the project, but the project did not actually interface documentation, information swagger is also simple could not be simpler. Developers need additional time to prepare documentation, testers need additional time to test, customers do not give enough period;
to sum up:
- Expanded skill tree is a good thing, but the aim should be to save costs. Any cost considerations into bullying;
- Applications should be more flexible skills, such as adding interface test milestone in the acceptance do, do more with less. Blindly on the integration testing must not succeed.
Fourth failure - is greater than the internal customers and external customers
One day my boss to find that there is a pure test project needs to evaluate. After doing basic grooming to get information, government projects, the logic is simple but super multi-form, moving bricks live. After the exchange of information back to the boss and the boss again and my conclusion is that - can not do it, the team was working at full capacity. Later, several exchanges with the boss, I can not do all the feedback. Finally, the owner found a few interns at the school to help me, then came into contact with customers. That customers several exchanges, customer demands are hoping to save costs, but I still insist on quality first, the customer ultimately accepted our program. The final success of the project to do down more than 80 days, 900 bug, 40000 Tiao use cases, data look pretty good. Why it is counted as a failure?
1. do not meet internal customer demands : the project owner brought over, there may be many considerations, such as profits, such as to catch new customers and so on. After I received the information, my first reaction was digested team can not afford to not do it, did not take into account the boss was asked to take the hill.
2. does not meet the demands of external customers : customers frequently expressed wish to reduce costs when there is no user's position, quality standards possible government projects and other customers are not the same, and perhaps this is just a demo version, the latter also there will be more changes, the possibilities have not been taken into account. Although customer acceptance of our program, but the result is that customers no longer collaborate on projects and our test class.
Summary :
- Treat internal customers should be treated like a family, to solve their problems should be a thing in the first place to consider. Like children come to tell you I was hungry, your first reaction should be to find a way I give you something to eat, but not I have no money.
- Treat external customers should tap the core demands to meet customers can bring long-term victory.
to be continued······