How to manage your own test team _ test

Recently, I also read some posts on the internet about the Test team management issues, feel that in the test management is really a problem, this may also test the team is really not good management reasons, but I think as long as they think, to explore, will always find a suitable test team management concepts and models bar.

I summed up my own, but also with some of their own management experience to share with you, you are welcome to put forward their own opinions and share their experience, it is a chance to learn from each other.

1, as a team manager, the minimum is to understand their own products or projects business. This is important, the first is to help you assign work to the members of the team, otherwise it is not clear that the difficulty of the business and the amount of work to assign a job to member is a very difficult thing to accept. Second, to help themselves and other team or department of the cooperation and communication, not the others to ask questions, they do not know the promise or negative to do.

2, as a manager, to understand more technology, at least to learn more testing technology, to understand its working principle, so help themselves to help team members research or the application of technology to the actual test work. can also improve their Test team in the Granville sex, they know more can let more students recognized and convincing.

3, balance according to the expertise assigned work tasks to team member. For senior testers, we assign more tasks to design test case, and junior testers may be more likely to assign execution tests. Distribution work is also to see which Tester's expertise, some testers are sensitive to the GUI, some testers are more concerned about the logic, some testers to the whole system process clearer, these are as a Test manager assigned a baseline of tasks, so that you can better zone a team, Improve the level and quality of software testing.

4, do a good job of testing risk management. In general, we have to minimize the risk of testing, but also a very important test management issues, I can only talk about their own one-sided point of view. Testing risks exist from the beginning of software requirements analysis, and we need to better identify these risks lurking in the requirements or development design in the early stages: 1 If the requirements of the function can not be achieved, or there is a need to violate the existing functions of the requirements of our needs analysis must be put forward; 2 software requirements Design Some of the functions or points that cannot be tested, should also be put forward in the test requirement analysis; 3 The development of static testing of design documents, which I think is very important, many small companies will basically ignore this, static testing (mainly refers to the documentation aspects of the test), the development of design documents or prototype design documents review or testing to help test risk reduction, can also find some conflict with the requirements of the design, strive for errors in the early detection. At the same time, we can better match the test cases in the test, design better test cases to test, whether it is from the GUI, or the development of testing technology is useful 4. Review or static testing of test cases, which can improve test execution efficiency by optimizing test cases, supplementing more useful test cases, and removing unwanted or repetitive use cases. 5. Monitoring test execution and bug management, the bug is one of the results of the tester, we as managers must be managed well, but also let us clearly see the existence of test risk, through the existing bug trends to determine how many future bugs exist in the system, you can analyze the type of bug fix How long will the bug be, and how many bugs can it cause? So that we know exactly when the current testers and developers are going to start working overtime or have to deploy more people ... we also need to focus on test execution progress, test execution, bug trend charts, which types of bugs are more, At this time will not affect the middle of the test, logic bugs will certainly affect the quality of the mid-term test and test efficiency, at this time to remind the development team to pay attention to the logic type of bug fix, can not drag this kind of bug to later fix, this will affect the quality.

Of course, there are other factors that affect software quality risk, such as project or product time evaluation, I think this part is hard, we can negotiate the project time of the test, there are people leave or leave, as well as the Test team personnel changes, as well as the tester mood fluctuations will affect the test quality risk.

5. Evaluate and measure the performance and level of the tester reasonably. Believe this is also very difficult to do a little, do not good, not only can not let the whole team good work, internal contradictions, resulting in staff turnover will have, is to let a team the most headaches, then how can we reasonably assess the work of testers. First of all, I feel that public hard performance standards, so that everyone can understand a standard, but also the goal of common development team, so do justice, no selfish. I think we can measure this in several ways: (a) work attitude and motivation B) a linear comparison of workload and quality of work, the workload must be the most arduous, but with its quality of work for reference, of course, we can not find a staff found the number of bugs as their performance standards, I remember the way a test manager used to do that. This is killing and killing the whole company, because the testing of different objects or the level of developers and the size of the project and the degree of difficulty, are affecting the number of bugs is not the same factor, I think a better standard is from a variety of ways, Test execution process and test case two aspects, during the execution of the test, the bug trend chart and the bug type map and the bug feedback rate after the software delivery, the tester should find the bugs that should be found in each phase during the execution of the test, not to mention the obvious bugs in the end, which can see the tester's level In addition, the design of test cases is also a very important standard, very good test cases, will find bugs as early as possible, of course, test case design operability, detail, etc. are measured standards.

6, cohesion team and inspire the potential of team members. It's a bit of a lie, but it's really important, I think it's important that everyone in the team is growing up and that it's important to have a reasonable job role so that they can better see their growth space, such as a test case that allows a relatively junior tester to design a simpler test project or requirement , so that he also thinks he can design test cases, so that a very senior tester responsible for the project, so that he is the protagonist of the project rather than the Test manager figure, so that members of the team will be more responsible Arranging a relatively idle test to study the updated technical or test skills and sharing it with all members through the lectures, and arranging the tester to exchange tests during the execution of the program so that the members involved in the project can understand the whole system, So each part of the project is equivalent to having backup staff, not worried about the project to ask for leave and embarrassed, but also to cultivate the tester's business knowledge. Let members communicate with each other and participate in activities outside the work.

7, the communication member, understands the member's mentality. As a manager to care more about the members of the mentality and growth issues, why the work is not very positive. Why project quality is not high. .... Can be understood through private chats, and help them to solve.

Well, I have only summed up a few of these, I hope that the future work can be summed up better experience to share with you, but also hope that everyone to make comments, share their views on it. Thank you, we grow up together ....

Copyright NOTICE: This article is from the Peter.zheng 51Testing Software Test Blog: http://www.51testing.com/?116797

Original works, reprint, please be sure to hyperlink form to indicate the original source, author information and this statement, otherwise it will be held accountable.