Choosing and Managing the Ideal Test Team

Lloyd Roden, Grove Consultants, www.grove.co.uk

Introduction

"People are the most important asset of any company"

Do we agree with this statement? The majority of us would answer "yes", the main exception would be if we owned a fully automated robotics company! It is the people that make the company what it is. People are important; we therefore need to invest time in people as well as tasks related issues.

Creating the right balance between task issues and people issues is vital for successful test management. Focussing on just task issues can make us little more than a military camp where people are accustomed to follow orders. Whereas if we focussed only on the people's needs and ignore tasks that must be accomplished then we move closer towards the 'holiday camp' scenario! This balance is not only important it is also very difficult to do well. In this paper we take a look at some of the people related issues in software testing.

While it is often said that 'anyone can test', the skills and makeup of the test team are important and must be managed and cultivated properly. We shall have a look at some of the key ingredients in building (and retaining) successful test teams within our organisation. Building a test team is one thing but keeping and maintaining a healthy, effective and efficient test team is quite a different matter.

During my 16 years career as a test manager / test consultant, I have found that managing people is often one of the most difficult things to do well. If this is the case then why do we spend more time dwelling on the task issues? We shall take a look at some of the key ingredients of a successful test team and some of the problems we can encounter preventing us becoming a successful team and how we might overcome them.

We will also use the "tester's style analysis questionnaire" to discover the 4 types of tester that exist within our organisation; the pragmatist, the facilitator, the analyst and the pioneer. It is important to recognise differences that exist so that we can maximise their strengths rather than dwell on their weaknesses. The analysis questionnaire can also be used to identify how conflicts arise and how to defuse "explosive" situations. Once a team has been formed it is important to motivate the team. I shall explain my top four tips for motivating our testers to help them become passionate and committed to a career in testing.

Know Your Team

Tom DeMarco and Tim Lister in their book "Peopleware" describe how we can create an atmosphere for Jelled Teams - teams that produce "success" and "productive harmony". So what are some of the common distracters when it comes to forming successful teams?

Physical separation. It is difficult sometimes to always have the test team in close proximity to the rest of the project team. But I have found that the more separation there is, the more problems transpire between the teams. It is important - where possible to have the test team, development team and designers located as close as possible.

Being unfair. Human nature is to crave fairness. From a very early age children seek fairness from their parents. I have two children and even now when both of them are in their 'teens', I still need to be fair. This human nature is in adulthood as well. The general rule for unfairness is when favouritism is shown to one group above the other. This can manifest itself in a number of different ways; salary, remuneration, office space, paid overtime and other financial and non-financial rewards.

Communication breakdown. Good communication is one of the key ingredients in any relationship. This is vital within the test team. To communicate with key project personnel with regards the test assessment enabling them to make informed decisions.

No common goals. The test team must have a vision - clear direction from the management in order to be productive. Otherwise the team will end up heading in different directions. State the objectives of the test team and seek approval of these with senior management. Some examples of good test objectives are:

• assess software quality
• help achieve software quality
• assess and report on risk
• help preserve software quality

Duplication of effort. One of the most frustrating activities in testing is the feeling of "deja vu" - that someone has already performed the tests that we are running. Duplicating testing can be annoying to all parties - the feeling that we are wasting our time, which is a luxury we often do not have in testing! Simple techniques like reviews, allocation of tests and paired testing can alleviate this problem. Time spent planning who does what at the start of the project is time well spent.

Lack of management support. If the test team feel as though management do not support the test activity then this can have a severely damaging affect on the team. Some of the key indicators where support is not being shown:

• not being listened to
• test results not being acknowledged
• test estimates being ignored
• very little of no tool support

Adopting a blame culture. From a very early age we like to blame. If you don't believe me then take some time watching the activities of small children. When one child does something wrong then the tendency is to blame the others - usually to avoid punishment! Why do we blame? Because we usually want others to feel bad! Why is a blame culture unhealthy for productive test teams? Because we become fearful of taking any risk in case we make a mistake.

We went into one client and asked "do you operate a blame culture?" and they replied; "well if we do...it's their fault". Another client relied; "no we operate a revenge culture!" If we are to learn, progress and become more productive as a team then we must fight the "blame culture" mentality.

Failure to appreciate. Everyone wants to be acknowledged and appreciated for the work they do within the organisation. If we do not begin to appreciate one another then people feel as though they are 'worthless'.

Take time to watch your team and start to praise them for good work. It is important that this activity is not forced, but is born out of a natural relationship in the team. Rewards are sometimes good, however a simple "thank you" or "well done" goes a long way!

The key components of a 'jelled' test team:

• Trust and support
• Good communication
• Strong leadership
• Identity - having a sense of direction
• Building a sense of belonging to an elite
• Providing a lot of satisfying closures
• A move from independence to inter-dependence
• Recognition of strengths within the team

The tester's style analysis

Based upon the communication styles questionnaire I have noticed that there are 4 types of tester that exist within our organisation. The questionnaire has been adapted to help assess these types and the type of testing work that these styles enjoy. This enables us to manage our teams more effectively. Assigning correct work to the correct type is essential for greater productivity.

How to complete the questionnaire:

1. Complete the questionnaire by marking one column in each of the x and y axis set of questions. For example I think I am more "friendly" than "formal". As illustrated above.
2. Add up the left most column for each axis. In the example above we have scored X= 7 and Y = 8. This gives a grid coordinate (7,8) which can be plotted on the grid.
3. Each grid coordinate represents a "style"

Top Left: PRAGMATIST

Top Right: PIONEER

Bottom Left: ANALYST

Bottom Right: FACILITATOR

The Pragmatist

Likes	Dislikes
strategic / goals positive results / brief practical efficiency tasks	indecision vagueness time-wasting unproductive
The 'Pragmatic' style tester will... be good for setting and monitoring short/long term goals for the team be good at documenting factual 'test reports' remain positive through pressure be keen to adopt 'Most Important Tests' first principle be a strong driving force - ensure a task is done want to implement efficiency into the team be self-motivated and task oriented will make quick decisions enjoy challenging testing tasks

The Pioneer

Likes	Dislikes
new / ideas change openness results/efficiency involving others risks	standards detail 'norm' paper-work
The 'Pioneer' style tester will... be good at 'ad-hoc' testing / bug hunting / error-guessing/ exploratory testing be good at challenging and improving things to make more efficient and effective enjoy "GUI" type testing/lateral tester have good ideas be good at brainstorming Test Conditions share ideas about different ways to approach testing identify and take necessary risks when required have creative test ideas - how to find more faults

The Analyst

Likes	Dislikes
accuracy attention to detail proof standards reliable all alternatives	new / change untested / risks brief / speed letting go
The 'Analysing' style tester will... be good at defining and documenting test cases be good at producing test standards and procedures analyse problems and finding root cause produce work which is accurate and complete enjoy logical tests scenarios provide proof when faults are found document thorough test reports complete work regardless of what it takes challenge requirements

The facilitator

Likes	Dislikes
networking positive team oriented consensus / sharing building bridges status quo	pressure / deadlines confrontation isolation dictated
The 'Facilitating' style tester will... be good in a RAD environment or a 'buddy' test team often ask opinion before raising issues be good at documentation co-operate well with other departments often see the 'other side' be good at defusing 'us' v 'them' syndrome be popular make things happen - eventually! will provide support in testing to other team members

Tester style patterns

We usually operate within a boundary and can fluctuate within that boundary. The more prominent we are within a style the more difficult it is to adapt to one of the other styles.

If we find ourselves on the line or in the centre, then we are very flexible within the styles, but can be difficult to manage.

Opposites repel!

The key in using this analysis questionnaire is to understand where we are and also where the rest of the team are so that we can assign work which will compliment their style. However opposites repel and this maybe a reason that tension exists between team members.

For example: John is a 'Pioneering' style tester and wants new ways of doing things, to help with efficiency. John is constantly challenging standards and procedures. Chris however is an 'Analysing' style tester and requires structure in order to work efficiently. Chris is often seen as challenging John for his cavalier approach to testing! Tension often exists between John and Chris - is this wrong? No, it is just that they are different.

As managers we must recognise the team's strengths as individuals as well as the team as a whole. Yes, we must address the weaknesses but we will be far more motivational if we concentrate on the strengths.

As a general principle

• analysts & pragmatists tend towards 'task issues '
• facilitators & pioneers tend towards 'people issues'

Recruiting the right people

Recruiting the right person to join the test team can be quite daunting as well as difficult. What should we look for on a CV? How do we recognise good testers during interviews? What should we do when we have no choice in the recruitment process? Whilst anyone can run tests, not everyone is a good tester and we should challenge statements that suggest "anyone can test"!

Adding one person can disrupt the group dynamics of our team. Will the candidate gel with the rest of the team?

Have you ever thought about producing a tester's aptitude test or a small application to test to see how good the potential candidate is? If you don't want to produce your own then send an email to myself and I shall send you "Grove Consultants" versions of the above.

Motivating your team

Understanding motivation

Motivated testers will be more productive. What are the key signs of our testers being motivated and more importantly - how do we recognise when they are de-motivated?

Before we look at the key motivational areas for testers we should ask ourselves four basic questions:

1. What is motivation?

The Dictionary's definition of motivation is "to cause someone to act in a certain way" Motivation is the will to act. It was once assumed that motivation had to be injected from the outside but it is now understood that everyone is motivated by several different forces.

2. Why is motivation important?

For the employee, the chief advantage is job satisfaction. For the employer, it can mean good quality work. Motivation encourages higher productivity in the organisation.

Signs of motivation	Signs of de-motivation
high performance drive & enthusiasm co-operation in overcoming problems keen to achieve results accept responsibility working long hours! happiness & enjoyment welcomes change	apathy & indifference dissatisfaction poor time-keeping/high absenteeism resists change exaggeration of disputes generally uncooperative blame withdrawal

3. Whose responsibility is it to motivate?

Motivation should not be left to the manger. It is everyone's responsibility to motivate! Self-motivation is however longer-lasting, we should therefore encourage self-motivated staff further by trusting them to work on their own initiatives and encourage them to take responsibility for entire tasks.

4. Should motivation be long or short term?

Motivation should be both short term and long term.

There have been numerous studies on motivation and various theories produced. To help with the understanding of motivation further we shall take a brief look at two such theories: Hertzberg's theory and Maslow's theory.

Herzberg's Theory

Frederick Herzberg, contributed to human relations and motivation in terms of his theory of motivation. Herzberg suggested that job satisfaction is mainly caused by 'motivators' and job dissatisfaction is mainly caused by 'hygiene factors'. The first part of the motivation theory involves the hygiene theory and includes the job environment. The hygiene factors are mainly external and include

• the company,
• its policies and its administration,
• the kind of supervision which people receive while on the job,
• working conditions
• interpersonal relations,
• salary, status and security.

These factors do not lead to motivation but without them there is dissatisfaction. The second part of the motivation theory involves what people actually do on the job. The motivators are

• achievement,
• challenge
• recognition,
• responsibility
• growth / advancement and
• interest in the job.

These factors result from internal generators in employees, yielding motivation rather than movement.

Both these approaches (hygiene and motivation) must be done simultaneously. Treat people as best you can so they have a minimum of dissatisfaction. Use people so they get achievement, recognition for achievement, interest, and responsibility and they can grow and advance in their work.

Maslow's theory

In the late 1960's Abraham Maslow developed a hierarchical theory of human needs. Maslow focused on human potential, believing that humans strive to reach the highest levels of their capabilities.

1. Biological / Physiological Needs. These needs are biological and consist of the need for oxygen, food, water, and a relatively constant body temperature. These needs are the strongest because if deprived, the person would die.
2. Security / Safety Needs. Except in times of emergency or periods of disorganisation in the social structure (such as widespread rioting) adults do not experience their security needs. Children, however often display signs of insecurity and their need to be safe.
3. Social (Love, Affection and Belongingness) Needs. People have needs to escape feelings of loneliness and alienation and give (and receive) love, affection and the sense of belonging.
4. Ego / Esteem Needs. People need a stable, firmly based, high level of self-respect, and respect from others in order to feel satisfied, self confident and valuable. If these needs are not met, the person feels inferior, weak, helpless and worthless.
5. Self-actualisation/Fulfilment. Maslow describes self-actualisation as an ongoing process. Self-actualising people are involved in a cause outside their own skin.  They are devoted, work at something, something very precious to them.

Maslow set up a hierarchical theory of needs in which all the basic needs are at the bottom, and the needs concerned with man's highest potential are at the top. The hierarchic theory is often represented as a pyramid (or a set of steps), with the larger, lower levels (steps) representing the lower needs, and the upper point representing the need for self-actualisation. Each level of the pyramid (step) is dependent on the previous level. For example, a person does not feel the second need until the demands of the first have been satisfied.

Key motivators for testers

There are a number of aspects in addition to the standard motivators that are specific for testers:

Clear goals and vision for testing. It is important to know where we are heading in testing and that this is agreed with senior management. Discuss the 'terms or reference for testing' with your team, produce a one page document and publicise it. This shows commitment towards testing.

Support for your testers. It is important, as a test manager, that we listen to the team and if the need arises - we fight the 'tester's corner'. Discuss various courses and staff development with your team. Think about sending them on testing courses, conferences or testing seminars to improve their skill.

It is also important that we are seen to strike the right balance between 'hands-off' and 'hands-on' test management. Small things like sitting with the testers rather than in a large office and actually helping with testing will motivate the team. It shows them that you are involved rather than removed.

Promoting the value of testing. Another way we can motivate the team is to promote the value of testing at every opportunity. This is such an important aspect because so often testers are not valued for the work they do. The primary reason, I believe, is that we do not produce anything that is 'tangible'. We must constantly reflect and report on how individuals, as well as the whole team, have added value to the project and company.

Career path & Salary acknowledged. Salaries for testers should reflect their skill and the value that they add to the company. There should be no differentiation between tester, developer and designer's salary structures.

One of Maslow's motivational needs is 'self realisation' - an opportunity to improve in the job we find ourselves in. Therefore a career path for testers is essential if we are going to meet this need. Unfortunately many organisations do not have a clearly defined career path for the testers. There are a number of alternative career models we can look at:

• Hierarchical, where the structure starts with a trainee tester and progresses to team leader and test manager. The problem with this model is that 'management' should not be the only option in reaching the top.
• Functional, where the career path revolves around functions. A technical path, an automation path, a test design and analysis path and a team leader/test manager path.
• The career cube by Gitek/Sogeti...

The test career cube by Gitek/Sogeti (used with permission)

To professionalise testing within an organisation testers need to have the possibility for balanced growth in their career. This paragraph will show a method to appoint career paths for testing. Training and education, development of working experience and a coaching programme are essential components. These are addressed per function and per level in the 'career cube' (see figure 1). The career cube is a tool that is developed to provide better guidance by a personnel manager in career growth. It helps to adjust the demand from the organisation, the available knowledge and skills and the ambition of the test professionals to each other.

The three dimensions of the 'career cube' are defined as follows:

• height: functional growth
• width: functional differentiation
• depth: knowledge and skills

Figure 1: Dimensions of career cube

Functional growth

Functional growth implies the career an employee can make from tester to test manager. A distinction is made between vertical growth and horizontal growth. The moment vertical growth (higher function level) is no longer an option, it is possible to grow horizontally ('deeper' within the same function level).

Vertical growth leads to a higher function level, horizontal growth leads to a higher performance level within the same function level. An improvement in the conditions of employment can be realised in this structure by achieving a higher function level or a higher performance level.

Figure 2: Functional growth

Functional differentiation

Three main streams are recognised for the dimension of functional differentiation:

• Team and project leading
  People who have an interest and the talent for managing a test project can choose for this stream.Methodical support
  This stream is for those who want to provide test advice and support, e.g. for the setting up of a test strategy, the selection of test specification techniques.
• Technical support
  People who have the affinity with the technical side of testing can provide technical test advice and support. Examples here are selecting and implementing test tools and setting up the technical infrastructure for testing.

Employees can choose for either stream, depending on their interest and talents.

Figure 3: Functional differentiation

The diagram below shows examples of function levels with the corresponding function names for each differentiation stream.

D	general test management
C	test project leading	methodical test advice	technical test advice
B	test team leading	methodical test specialist	technical test specialist
A	test execution

At level A, there is no real differentiation. At these function levels broad experience is gained in the area of test execution. For levels B and C there is a differentiation. At level D there is no differentiation anymore. Employees at this level are expected to be able to successfully perform or manage in all three differentiations.

Knowledge and skills

The third dimension of knowledge and skills comprises the following components:

• (test)training;
• social skills;
• experience;
• coaching and support.

Training in testing, coaching and support are essential conditions for a sound career growth, especially for the lower function levels. Each employee is supported in a number of ways, provided by the personnel manager, the test manager and/or more experienced colleagues. A coach provides extra support to starting personnel in the field of testing, who takes care of all aspects of education and the progress therein. At higher function levels the experience and social skills are becoming increasingly important.

Figure 4: Knowledge and skills

Based on the three dimensions mentioned above, the 'career cube' can be filled in: for each function level the required knowledge and skills can be defined per functional differentiation.

Figure 5: Complete career cube

For further details on the career cube contact Sogeti/Gitek in The Netherlands. Website www.sogeti.nl

Conclusion

In order to retain good quality testers within our test teams we must spend time developing the people side of test management. Promote the value of testing within your organisation; support your testers by seeking to introduce a healthy career structure for testers. Recognise their current strengths and try to address the skill gaps.

The test team should provide an environment for testers to grow in their skill. We should seek to motivate our staff at every opportunity and encourage 'self motivation'. Our test team should not be likened to a military camp nor should it be a holiday camp. We should try to strike a good balance between the two.

---

Software testing team articles in Methods & Tools

Software Testing Team Dynamics

More Software Testing Knowledge

Software Testing Magazine

Software Testing Videos and Tutorials

---

Click here to view the complete list of archived articles

This article was originally published in the Winter 2005 issue of Methods & Tools