How to manage your own testing team

1. As a team manager, at the very least, you must understand the business of your own product or project. This is very important. First, it will help you assign work to members of the team. Otherwise, it is very unacceptable to assign work to team members without knowing the difficulty and workload of the business. Second, it helps to cooperate and communicate with other teams or departments, so that if you don’t know the questions raised by other teams, you can agree or deny it.

  2. As a manager, you must understand more technologies, at least more testing technologies, and understand their working principles, which will help you help team members research or apply technologies to actual testing work. . You can also improve your prestige in the test team, and knowing more about yourself can make more students recognize and convince.

  3. Balance the assignment of tasks to team members according to their specialties. For senior testers, we assign more tasks to design test cases, and junior testers may assign more tasks to execute tests. The assignment of work also depends on which tester's specialty is. Some testers are more sensitive to GUI, some are more concerned about Logic, and some are more clear about the process of the whole system. These are all tasks assigned by test managers. Baseline, which can better lead a team and improve the level and quality of software testing .

  4. Do a good job in the management of testing risks. Generally speaking, we need to reduce the risk of testing as much as possible, which is also a very important topic in test management. I can only talk about some one-sided views of my own. Testing risks exist from the beginning of software requirements analysis. We should better discover these risks lurking in requirements or development design in the early stage: 1) If the requirements propose unattainable functions, or there are requirements that violate existing functions, we are in the requirements. 2) Some untestable functions or key points in the software requirements design should also be raised in the test requirements analysis; 3) The static test of the development design document is very important to me. Many small The company basically ignores this point. Static testing (mainly refers to the testing of documents), review or testing of development design documents or prototype design documents can help reduce the risk of testing, and can also find some designs that conflict with requirements. Try to catch mistakes early. At the same time, our test cases can also better cooperate with them in terms of testing, and design better test cases to test, whether it is from GUI or development and testing technology testing is beneficial; 4. Review or static test cases for test cases Test, which is conducive to optimizing test cases, adding more useful test cases and removing some useless or repeated use cases, which can improve the efficiency of test execution. 5. Monitor test execution and bug management. Bugs are one of the achievements of testers. As managers, we must manage them well, and at the same time, we can clearly see the existence of test risks. We can judge the system through the existing bug trends. How many bugs still exist in the future, we can analyze how long it will take to fix the bugs and how many bugs may be generated by the types of bugs, so that we can clearly know when the current testers and developers are going to work overtime or who are going to work overtime. We have dispatched people... We also need to pay attention to the progress of test execution, the bug trend graph in the early stage of test execution, and which types of bugs are more numerous. Will this affect the mid-test period? If there are too many Logic bugs, it will definitely affect the mid-test period. In order to improve the quality and test efficiency, the development team should be reminded to pay attention to the fix of logic-type bugs. Such bugs cannot be delayed to a later fix, which will affect the quality.

Of course, there are other factors affecting   software quality risk , such as project or product time evaluation, I think this part is mostly rigid, we can negotiate the project time of the test; there are also personnel requesting leave or resignation, and changes in test team personnel, and There is a tester's emotional fluctuations that will affect the risk of test quality.

  5. Reasonably evaluate or measure the performance and level of testers. I believe this is also difficult to do. If you don’t do it well, you will not only be unable to make the entire team work well, but there will be many internal conflicts, which will cause employees to leave. It is the most difficult thing for a team. work? First of all, I think that publicizing the hard performance standards, so that everyone can understand a standard, is also the purpose of the team's common development. Doing so is fair and will not be selfish. I think we can measure it from several aspects: a) work attitude and enthusiasm b) a linear comparison of workload and work quality, the one with a large workload must be the hardest, but the quality of the work should be used as a reference, of course we The number of bugs found by an employee can't be used as a benchmark for their performance, I remember a test manager doing this in the past, this is a terrible and company-wide practice, because the test objects are different or the level of developers The difference, the size and difficulty of the project are all factors that affect the number of bugs. I think a better standard is from many aspects, the test execution process and test cases, and the bugs in the test execution process. Trend chart, bug type distribution chart, and bug feedback rate after software delivery. Testers should discover bugs that should be discovered in each stage during the test execution process. It is not possible to say that obvious bugs are discovered at the end. These can be seen in the test. In addition, the design of test cases is also a very important standard. A good test case will find bugs as early as possible. Of course, the design operability and detail of test cases are all measures.

  6. Unite the team and stimulate the potential of team members. Although this is a bit of a big talk, it is really important. I think it is very important to let everyone in the team grow. It is very important to arrange reasonable job roles so that they can better see For example, let a junior tester design a relatively simple test project or required test case, so that he also feels that he can design test cases; let a very senior tester take charge of the project, let him feel that it is a project The protagonist in the test instead of the test manager, so that the members of the team will be more responsible; arrange idle tests to research newer technologies or test skills and share them with all members through lectures; , arrange testers to exchange tests during the execution process, so that members participating in the project can understand the entire system, so that every part of the project is equivalent to having backup personnel, and you don’t have to worry about which one of the project asks for leave and is embarrassed. The tester's business knowledge is developed. Let members communicate more and participate in activities outside of work together.

  7. Communicate with members and understand their mentality. As a manager, you should pay more attention to the mentality and growth of members. Why is your work less active? Why is the quality of the project not high? .... all can be understood through private chat and heart-to-heart, and help them solve it!

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324602658&siteId=291194637