write in front
Recently, a friend asked me what are the routines for building a test team from scratch and airborne to a test team. I happen to have both experiences, and I just like to summarize and share, so I can tell this friend about my experiences and feelings. My self-definition is a first glimpse of the management approach, so there are inevitably immature points in my views. You can ask more experienced people for advice.
This paper expounds from five aspects: team formation, staff training, work arrangement, work evaluation, and self-requirements.
After reading this article, you may gain the following benefits:
-
Build a test team from scratch, where is the focus of work?
-
What can I do to reflect the value of the testing department as soon as possible?
-
What does this job require of the test manager himself?
-
What are the differences in team formation and team building?
-
What problems should be avoided in management?
Form a team
When it comes to the management of test teams, it is inevitable to talk about recruiting. Perhaps this is also the most concerned issue for most people. If this issue is not covered, the discussion of test team management will not be complete.
At the age of 13, I was given an opportunity to build a testing team from scratch, because the company was just starting out and the budget given to me was not much, so I had to treat each interviewee carefully. Most of the time, they are selected from fresh graduates or candidates with less than 2 years of work experience, and the recruitment requirements have also dropped. Because there really aren't many options for me.
Looking at it now, as long as there are no problems with the recruits, there is no need to be demanding, and the lack of ability can be made up through norms and management strategies.
About how to form the initial team, I wrote some opinions last year (see " How to form a test team?" ). It is about how to plan the recruitment and hiring of talents according to the tasks undertaken. This article is limited in space and will not be repeated here.
Staff training
As mentioned above, my background in setting up a testing team was not optimistic, and it was hard to find people who were particularly satisfied. This means that there needs to be some quick fixes in terms of employee development.
I have used some small means, including creating a directory on SVN to put documents for new employees on the job; formulating training plans according to the characteristics of each person; training on test case design according to the "Black Box Testing Framework"; The process of the company's products in order to reduce the cost of work handover and quickly grasp the new team members...
In addition to skills training, there are also some skills in the way of doing things. Take instructing team members to submit bugs as an example. I will often read the defects submitted by the team members, and observe whether the defects are clearly written, whether the tone of the report is neutral, and what is the value? Is the test deep? Does the development understand flaws? What do the developers have to say about the bug submitted by this team member? …it’s easy to do this with a small start-up team. This work helps test managers understand the product, the strengths and morals of their employees, and the communication and interpersonal issues that affect their own employees.
It is also important to train employees in their time management skills and to exert their influence on the team. Because we often give our employees more work than they can accomplish, and many project teams are reluctant to fix bugs.
There are some more detailed arrangements for specific work, you can refer to my other article "How to bring new people? 》
Working arrangements
1. Try to prevent employees from doing multiple jobs in parallel
2. Arrange the old with the new
3. Ask new testers to rewrite old bug reports before writing new ones
4. Let new testers retest old bugs before testing new bugs
5. Don’t schedule test novices for nearly finished projects
6. You also have to work with your employees. The difference between this and the mature team lies in the amount of work you put in.
job evaluation
When evaluating the work of subordinates, the following aspects can be considered:
-
What is the quality and efficiency of the work done?
-
Read the output of its work
-
Gather input from developers or other interested people who work with it
-
What disputes has he been involved in, why and how?
-
How does he keep his promises
-
what type of question he missed
-
What type of help does he give other testers and programmers to improve their work effectiveness and productivity
-
Is he learning new skills and willing to share his skills to help colleagues improve
-
What is his perspective on dealing with the problem, has he dealt with the problem from the perspective of the company, and what has he dealt with?
By understanding these, the test manager can have a more comprehensive understanding of the subordinate's work and the status of the tested project, and can use this information to find out the strengths and weaknesses of the employees, and then provide targeted training and guidance.
own requirements
Finally, talk about the test manager's requirements for himself.
Requirement 1: Determine your own leadership style
When I first started out in management, I knew nothing about management. There is a popular saying in management science, "Management is a science, leadership is an art", but I didn't have any feeling for this sentence at the time, I don't know why I said it, and I don't know how to put it into practice.
好在，我运气一向不错。很快就得到了公费培训的机会。跟随郭致星教授学习项目管理的过程中，也学到了很多管理的思想和技巧，那时候才知道管理者也分类型，而且要根据不同的人不同的阶段变换自己的角色——算是完成了管理学的启蒙。
要求二：不要轻易做出承诺
现实情况是，我们的测试时间总是被试图压缩，也常有领导给测试部安排没人做的工作。小心不要让自己被滥用。不要承诺不可能做到的事情，在这样的事情上不必说谎，不必掩盖问题。有些领导不太讲理并滥用员工，测试经理改变不了这样的人，如果工作难以忍受，可以在找到更好的机会后离开。
要求三：汇报真相。
测试经理的力量来自向需要了解真相的人说明真相。如果在诚实上让步，就会使自己力量的一个核心支柱弱化。不必担心得罪人或被炒鱿鱼，只要有真本事，是为了工作，就不会有大问题。事实上，测试员的本职工作就是暴露问题，而不是将问题掩盖起来。不必，也永远不要在诚实上让步——这是我的血泪教训。
致命的领导错误
-
忽略人性，扼杀下属的创造性，试图标准化下属的全部工作，让每个人都确切的知道他们自己能做什么，然后以相同的方式去做
-
把下属培养成“不可替代的齿轮”，工作无备份
-
评价或考核员工时不关注其创造性、可说服性、判断力或人际敏感性
-
给下属灌输错误的理念，比如告诉他们的工作只是报告程序错误，不需要帮助程序员定位和分析缺陷，不需要考虑如何修改会让程序体验更好
总结：
-
慎重对待招聘，尽可能招聘合适的人
-
加强自身技术积累，多培训自需要
-
经理也承担很多测试任务
-
初期选择教练型领导风格
-
多跟领导沟通
-
注意员工士气