4 THE UAT TEAM
In Chapter 1 the concept of stakeholders, each with a different role to play in an implementation, was introduced. The sponsor commissions the system and signs the cheques, the manager is responsible for delivering the benefits of the system, the end-user operates the system and the developer builds the system. Each role has a different contribution to make to the project and each role has different objectives. UAT represents the first time that all the roles will potentially reach a moment of resolution regarding their own goals and responsibilities. The sponsor will know whether the cheque should be signed, the manager will know whether the business benefits will be delivered, the end-users will know whether the system works in the way they had envisaged and the development team will know whether its development work has met the requirements.
In this chapter we look more closely at the testing team and its relationship with other stakeholders. The mechanics of team formation are well known, but the UAT team has a unique challenge – to acquire the skills it needs, to form an effective team quickly and then to take on a challenging task and complete it in a very short time.
Topics covered in this chapter
• Stakeholders and the UAT team
• Key roles in a UAT team
• Creating a successful team
• Training the team
• UAT training content
• The team life cycle
• Dealing with team conflict
• The working environment and working patterns
• Basic disciplines
STAKEHOLDERS AND THE UAT TEAM
Not all of the people interested in UAT are considered to be part of the UAT team, yet some will have an influence over how it is conducted. These are stakeholders in UAT, 75
even if they are not considered as stakeholders of the system being delivered. Depending on the scale of the project and the organisation they might include:
• programme manager – responsible for delivering a number of related projects;
• project manager – responsible for delivering the project;
• project management office (PMO) or administrative staff – responsible for organising UAT;
• test/quality manager – responsible for all testing including UAT;
• UAT team leader/manager – responsible for delivering UAT;
• UAT trainer – responsible for delivering UAT training;
• business analysts – responsible for documenting requirements.
The UAT team’s primary responsibility is to provide the key stakeholders with enough information to make a rational decision about whether or not to accept the system. Evidence will be based on a programme of structured testing to determine the achievement of acceptance criteria. It is the UAT team’s responsibility to plan, schedule, execute and report on the testing to provide stakeholders with detailed evidence and a recommendation (for acceptance or non-acceptance) based on that evidence. The stakeholders will also require recommendations about potential alternatives, for example to accept the system subject to receiving an update that corrects known defects within an agreed time frame.
The UAT team
The ISTQB Glossary does not include an entry for ‘UAT team’, but normally when people refer to a UAT team they mean those actively taking part in the UAT process; the UAT team leader or manager, possibly business analysts and the UA testers. UAT teams vary widely in their size and composition and the team may only comprise a single individual, but coordination, analysis and testing still need to be carried out and having specialists in these roles can help to make UAT more effective and efficient. Where the team is relatively large, that is more than three people, additional specialist roles can be identified.
We always need to bear in mind that the members of the UAT team may have other responsibilities in their day-to-day working lives or on the project. Not everyone will be available continuously or full-time, especially in the preparation stages, and work schedules will need to take account of availability as well as recognising that UAT team members may have to deal with other priorities in their other roles during the period of UAT. It is true that a dedicated team with no distractions can do the best job, but that is a situation that only rarely happens and we would be unwise to assume it in our planning.
According to Wikipedia:
A team comprises a group of people ... linked in a common purpose. Teams are especially appropriate for conducting tasks that are high in complexity and have many interdependent subtasks.
This is certainly true of UAT, in which a complex web of interrelated activities has to be managed effectively and efficiently to reduce the resource costs and elapsed time of the UAT exercise.
KEY ROLES IN A UAT TEAM
Business analysts (in-house or outsourced)
In any implementation project there is a potential for miscommunication between the project and the business because of differing goals and responsibilities and because each speaks its own language. Business analysts are the specialists who can speak the two ‘languages’ of the implementation project (‘IT’ and ‘business’) and are able to translate between them. Business analysts represent the ideas of one group to the other, ensuring that development meets the user expectations as closely as possible.
The business analyst’s task of translation begins with the definition of the business requirements and the subsequent translation of the business requirements into a technical specification. Business analysts also assist in writing test cases and test scripts, matching them as closely as possible to the end-user experience, because they usually have experience of defining tests for the system test level. We must always be aware, however, that business analysts will already have a perspective on the system and may have been involved in earlier testing, so it is the end-users who must ‘own’ the tests in UAT.
One problem that is likely to arise is that novice UA testers take a relatively long time to create workable tests. One commonly used compromise is to involve the UA testers in the creation of UA test conditions and test cases but leave the creation of the test scripts to the business analysts.
Where business analysts are available they are usually involved in test execution and reporting, and they are particularly well placed to help rate the severity of incidents, to discount any duplicate incidents and to explain or resolve issues raised during testing.
UAT coordinator/manager/team leader (in-house or outsourced)
The UAT coordinator is responsible for creating a plan for UAT, possibly in conjunction with a test manager or project manager, and for organising and planning resources for testing. The UAT plan sets out the objectives for UAT and the activities, timescales and resources required in order to deliver UAT.
In preparation for testing, the UAT coordinator will ensure that the necessary data and environments are available for testing; accounts and logons are set up and some customer accounts and documents – or other data that are part of the end-user process – are added in order to replicate how the system will be used in real life.
During testing, the UAT coordinator will manage and track test incidents.
Incident management
An incident is defined as ‘any event occurring that requires investigation’, so any test that does not deliver the expected results would generate an incident, as would any defects found in documents.
Incident management (IM) is normally in place before UAT and is usually based on software tools designed specifically to support software testing. IM includes assigning a unique identification (ID) to each incident, describing the incident and adding a severity rating. The recorded incidents will be investigated by the development team and will form the basis for changes that need to be made to the software and the regression testing that is carried out as a result of the changes. Regression testing checks whether the change has been made correctly and whether other, previously working, parts of the software have been negatively affected by the change. Incidents, once raised, must be tracked to ensure that the correct process is followed (see RIAD below) and that incidents are properly closed after the retesting of any changes made.
RIAD is an acronym for the standard IM process of:
• reporting;
• investigation;
• action;
• disposal.
Each stage of the process must be ‘signed off’ by the appropriate authority. Only the UAT coordinator will normally be authorised to sign off disposal, which means to effectively close an incident, for UAT incidents.
The severity of an incident is assigned when it is first reported. The UAT coordinator does not necessarily assign the severity rating but may decide on the severity of incidents where there is disagreement between testers or between testers and the business analyst or developers.
Finally the UAT coordinator and the business analyst will be expected to recommend to what extent the software requires changes or whether business processes can be adapted instead. The UAT coordinator also tracks the coverage percentage (the percentage of all the possible scenarios that have been tested) and decides when enough testing has been done.
UA testers (in-house)
We said earlier that end-users carry out UAT. Those who will use the system ought to test it because of their unique relationship with the system that is both present and future. We have previously likened a custom-built system to a tailor-made garment; the only way to find out whether a made-to-measure garment fits is to try it on, and the only suitable people to try it on are the recipients.
At the UAT team level the testers may comprise both end-users and other subject-matter experts who have a thorough knowledge of the current system or the current processes. UA testers are likely to be in-house even when parts or most of the rest of the project, including UAT, have been outsourced.
Ideally the UA testers should get involved when the needs of the business are defined and the business requirements are formulated at the start of the project, so that they can represent the voice of the end-user throughout the rest of the project.
UA testers determine the appropriateness of test cases, paying particular attention to those processes that currently, or that will potentially, cause problems, thus ensuring that UAT is relevant and reflects the real user experience as much as possible. UA testers should also provide ideas on how to improve current processes or on how to change current processes if needed.
Finally UA testers will execute test scripts, note incidents that arise from those test scripts and provide feedback on the user experience.
Skills, knowledge and experience
The UAT team needs to be able to operate independently (albeit with some support from other specialists) so that it is free to manage its own operations, set its own testing standards, and plan its own schedule of tests. Independence is vital in ensuring that UAT is not driven by particular individual stakeholder interests, either in content or schedule.
The list below identifies in brackets the role most likely to bring particular skills, knowledge or experience to the team:
• in-depth knowledge of the business requirements (business analyst);
• system architecture knowledge, including current fixes and workarounds (business analyst);
• thorough knowledge of UAT (team leader);
• an understanding of formal testing methodology (team leader);
• writing a UAT plan, assigning resources and deciding which issues to escalate (team leader);
• IT literate (testers);
• considered by the user community as an expert and able to represent the wider user group (testers);
• detail-oriented and diligent in collecting proper documentation to support the test results (testers);
• creative enough to think of alternative ways of carrying out processes that may represent an improvement or may suit the new IS better (testers);
• able to feed back to their peer group in a positive way (testers).
There are other skills that may sometimes be required, depending on the size and complexity of the UAT project and the organisation’s overall approach. These may include:
• knowledge and experience of test automation;
• familiarity with particular tools for requirements management, version control, IM and test planning;
• familiarity with general software tools, for example spreadsheets;
• experience of working in an agile environment.
In addition to these skills, knowledge and experience a team needs a mix of personalities that will enable the team to function effectively.
CREATING A SUCCESSFUL TEAM
Acquiring the necessary skills, knowledge and experience is a key part of creating a UAT team; the other key part is forming an effective team.
Particular tasks we have identified are normally assigned to key roles, but who delivers what on a team may differ depending on the project and the resources available. In addition to identifying the tasks and required skills for each role we need to also consider what makes any collection of individuals a balanced and successful team.
PERSONALITY VERSUS SKILL
Creating the right team is about getting the right people on the team and keeping them focused on the right things. But who are the right people?
What makes a great team is combining some qualities that are skills-based with others that are non-skills-based to make up the balance of the qualities required to get the job done. This is often overlooked when putting together a team and managers may focus too much on finding all-rounders when what they need to be most successful are flawed specialists.
The effect that personality can have on a team is also often ignored. Posing the question, ‘I don’t care how good he is, I don’t want him on my team because…?’ should help to clarify a number of non-skills-related traits that will not be helpful to creating a successful team. Attitude can enhance or diminish the usefulness of a team member regardless of their skill level.
No team is likely to be effective if it does not have the experience, knowledge or skill to carry out the required tasks.
A UAT team is not necessarily or normally a homogeneous group, each with the same set of skills, and there are other restrictions that may complicate the selection of the right set of people with the right skills. For example:
1. There is a small pool of potential candidates to choose from or the ability to reassign potential candidates’ daily duties is limited.
2. Multiple roles need to be taken on by a single individual.
3. An end-user earmarked to be part of the team may leave or move jobs.
4. A specialist contractor may have the right skills but not the right attitude.
5. A potential candidate may resist taking part in UAT if they view it as an increase to their workload for no or little benefit.
Putting together a list of likely candidates is seldom as simple as ticking off the list of skills and experience relevant to each role. Furthermore skill alone does not guarantee success and it is important to consider what makes teams successful and why.
There are many approaches to making sure a team works well together to achieve a purpose. It may not be appropriate to find out what personality types the potential team members are and whether they complement each other, simply because there is unlikely to be a large enough pool of people to choose from and because there are other factors that are more important when deciding who to select (particularly skills, experience or relevant business knowledge). Nevertheless it may be helpful to consider some of the key differences in personality suggested by the kind of analysis championed by experts such as Belbin (www.belbin.com) and Myers Briggs (www.myersbriggs.org).
Whether or not you select team members based on personal characteristics, there are some general points to keep in mind when putting together a team.
Belonging to a team results in feeling part of something bigger than yourself. Each member contributes to the overall success of UAT through collaboration with fellow members of the team to produce specific results, and the bigger picture drives everyone’s actions. This sense of teamwork is a team characteristic that is quite distinct from the team’s ability to carry out the necessary tasks to achieve its goal. Building a successful team requires as many as possible of the following six actions in order to ensure the team has the best chance of success:
• Communicate the purpose clearly. Team members should understand why the team was created (its goals), its importance, where it fits into the objectives of the business and the project as well as how the work will benefit the business.
• Ensure participants want to take part. Members should be committed to accomplishing the objectives of the team and perceive their contribution as valuable.
• Encourage open communication. Successful teams are able to discuss issues in an open and friendly atmosphere and team members are encouraged to give feedback whether positive or negative.
• Make sure the right people are present. The knowledge and skills required to make decisions and enter into discussion must be present in order to achieve the team’s goals. In an effective team all members can bring diverse opinions to the table and any conflicts are raised and addressed effectively.
• Encourage creativity. Delivering a new IS is partly a change management exercise and it is useful to have people in the team who are creative thinkers. It is also important for the team to understand that it can facilitate change. Involving those affected by change in decisions is a change management strategy that, all things being equal, has been shown to be effective.
• Make most decisions when there is agreement. Involving all parties in the decisions that are made may require some active intervention by the UAT coordinator if not everyone who disagrees voices their opinion. It helps to not accept the majority’s opinion as a reason to make a decision but to commit to understanding all objections and dealing with those objections as much as possible.
Even where people may object to being subjected to detailed personality analysis, there are still some easily identified characteristics that can be combined within a team to great benefit and that will make the six actions outlined above more likely to happen.
SOME USEFUL ‘TYPES’ (FROM BELBIN)
Belbin identifies nine ‘team roles’ that make up an ideal team. Here are three of those ‘roles’ that might be usefully deployed in a UAT team:
• Monitor evaluator – characterised as sober, strategic and discerning; sees all options and judges accurately.
• Teamworker – cooperative, perceptive and diplomatic. Listens and averts friction.
• Completer finisher – painstaking, conscientious, anxious. Searches out errors. Polishes and perfects.
Others, such as team leader and specialist, have an obvious role within UAT but the emphasis here is on achieving a harmonious and effective balance between individuals with quite different characteristics.
TRAINING THE TEAM
There are three related but separate aspects to training within the project life cycle: UAT training, end-user training and planning. End-user training and planning will be explained in more detail in chapter 10:
• End-user training allows all the intended users of the system to be sufficiently able to carry out their jobs using the new IS.
• The training, planning, coordination and preparation ensure that all the required ingredients appear at the right time for successful training to take place.
UAT training provides the skills that allow the team to carry out the UAT and help to build a successful UAT team. It is hard to overestimate the importance of UAT training. UAT training is in some cases the first time the UAT team will experience the new system and often the first time it meets the project team and stakeholders. A suitable test basis has been created and the test scripts have been written. The groundwork has been laid for UAT to begin and all that remains is to execute the tests. All this preparation has cost time and money and the next step will deliver the benefits in the form of a rational decision about acceptance and a clear path to implementation.
Given this scenario, and that to be really effective UAT must be carried out by end-users, it is vital to ensure that the testing is not carried out by unprepared, untrained end-users. If participants are either not trained or insufficiently trained, there is a risk that UAT will be chaotic and unfocused and that, as a result, UAT will be unsuccessful in enabling a rational decision or collecting feedback about the status of the system and its readiness for deployment. In other words the UAT may fail to do what it was intended to do and the investment in UAT will be wasted.
LONDON AMBULANCE SERVICE (LAS) – INADEQUATE TRAINING AND LACK OF TEAM FORMATION
Before 1992, office staff were charged with deciding what ambulances should be dispatched where and it seemed that there were efficiencies that could be achieved by using a computerised system. A new computerised dispatch system was duly built and tested. Just a few hours after it was deployed problems began to arise with the new system. In the chaos that ensued during the nine days following the initial deployment 46 people died who may have been saved had an ambulance been able to get to them in time. The South West Thames Regional Health Authority report into the failures of the project identified a number of issues. In its opening paragraph it states that:
What is clear from the Inquiry Team’s investigations is that neither the Computer Aided Dispatch (CAD) system itself, nor its users, were ready for full implementation on 26 October 1992. The CAD software was not complete, not properly tuned, and not fully tested. The resilience of the hardware under a full load had not been tested. The fall back option to the second file server had certainly not been tested. There were outstanding problems with data transmission to and from the mobile data terminals. There was some scepticism over the accuracy record of the Automatic Vehicle Location System (AVLS). Staff, both within Central Ambulance Control (CAC) and ambulance crews, had no confidence in the system and were not all fully trained. (South West Thames Regional Health Authority Communications Directorate, 1993)
Taking into consideration that training was clearly not the only contributor to the far-reaching difficulties experienced by LAS, a number of lessons can be learned from the LAS case. In relation to the trial of the CAD system one of the issues reported was, ‘frequent incomplete status reporting by ambulance crews caused by inadequate training, communication failures and alleged wilful misuse’.
Despite these problems having been known, the report shows that the final user training was:
• too far in advance of the implementation date leading to significant ‘skills decay’;
• not comprehensive and often inconsistent, problems exacerbated by constant changes being made to the system.
CAC staff and ambulance staff, roles heavily dependent on one another and often ignorant of the other’s work processes and pressures, were training separately. Training the roles together would have enabled them to understand that the successful operation of the system could only come about through CAC and the crews operating in full partnership.
Training, whether related to UAT or to the ability of the user to employ the system successfully pre- or post-implementation, should keep in mind:
• Timing of the training: is it close enough to the time when the skills wll be needed? Ideally the participant of the training should move from training to use without delay.
• Does the training teach the skills that are required in order for a single user to be successful and does it teach all the skills in order for the system implementation to be successful?
• Who is trained together, does an opportunity exist to learn from other users or roles and is training an opportunity to create a team spirit?
• Is the system stable enough to conduct training?
A UAT training session should be scheduled as close to the UAT as possible and the training session should achieve three goals:
1. Introduce the project, UAT and the system.
2. Teach the skills needed for testing.
3. Discuss what being a part of the UAT team means, the benefits and the rules.
UAT TRAINING CONTENT
The content most often forgotten in UAT training is an introduction to UAT and to software testing. Unless the whole audience consists of experienced UA testers, this part of the UAT training should not be omitted or neglected. Just as incomplete requirements are created because of the author’s assumed knowledge (the stuff everyone knows), so incomplete training can be created because of the trainer’s assumed knowledge. A UAT training audience may have no knowledge of UAT, and may not even know what the acronym UAT stands for.
When training is delivered to groups with different levels of knowledge, as long as the introduction does not take too long, no one will complain if the training material starts at the beginning and explains the basic concepts first. In fact many people may be grateful for explanations they have always wanted to ask for but were afraid or embarrassed to. Basics to cover would include:
• General project information and timeline. (Project manager)
• The basic functionality of the system. (Project manager)
• Any known issues and workarounds. (Project manager)
• What is the system designed to deliver? (Sponsor)
• What are the expected business benefits? (Manager)
• What is UAT? (Trainer)
• What is the specific purpose of UAT? (Trainer)
• What testing has already taken place? (Project team)
• What tasks are carried out during UAT and in what order? (Trainer)
The UAT training provides a good opportunity for the trainer to discover each participant’s strengths and weaknesses and for participants to recognise what their key training needs are. The interaction required to create the session, especially if members of the project team and other stakeholders deliver some of the material about the project, is invaluable in helping to form the ‘UAT community’.
An introduction to the system, with demonstrations as necessary, is important so that the team can feel comfortable with the way the system works and, if possible, have an opportunity to do some simple practical exercises to gain confidence.
Task-based training
All UA testers will need to understand the key steps in executing a test script, evaluating and logging the results, and reporting test incidents. All of these will need some practical hands-on training based on the specific approach to be used in the project.
To complete the trainees’ understanding of their tasks some background will be needed on the overall processes so that they can understand where their specific contribution fits. They will also need to understand the basics of how test scripts arise so that they can contribute their experience and question any aspect that does not make sense to the end-users.
The task-based training will need some background such as:
• what will happen to issues raised;
• how to feed back issues not part of the script such as usability;
• the importance of working independently and not forming a consensus.
By covering the points mentioned, the UA testers will have a good understanding of why and how they are taking part in UAT and what the outcomes will achieve.
Team formation
The single most important prerequisite to team formation is to ensure that the whole team is present. The UAT team leader will have an opportunity to assess the strengths and weaknesses of participants and begin to form a positive relationship with team members. Exercises should provide opportunities for team members to cooperate and provide mutual help and support. Group practical exercises are one way to engage team members, though it is important to watch out for the least experienced or confident being marginalised by more confident team members.
Careful debriefing of exercises provides opportunities to draw out key issues about participation and mutual support by inviting participants to make their own assessments of how successful the exercise was and how each participant contributed.
THE TEAM LIFE CYCLE
The training event is an early opportunity for the team to meet and begin to get to know each other. Even if they already know each other it may be the first time they have worked together in a team.
Every team member has three compartments to their life within a team: the tasks they must perform; their responsibilities to each other and the team; their responsibilities to themselves. In a harmonious team these three aspects are kept roughly in balance. When any one of them takes up significantly more of an individual’s time and energy, the team will become unbalanced and performance will suffer. The effect of increasing work pressures as tough deadlines approach is a good example and attention to the team’s health and the well-being of individuals is needed to maintain a balance.
FORMING, STORMING, NORMING, PERFORMING
When putting together a team it may be useful to remember that you cannot expect a new team to perform exceptionally from the very outset. Team formation takes time and usually follows four stages, moving from strangers or colleagues to becoming a united team with a common goal. Understanding these stages will help the manager or coordinator help the team become productive in the shortest time.
Psychologist Bruce Tuckman (1965) first came up with the memorable phrase ‘forming, storming, norming, and performing’ in an article for the Psychological Bulletin. He used it to describe the path to high performance that most effective teams follow.
Forming – stage 1
Forming is the initial stage in which members are positive and polite. Some members may be anxious because they have not worked out exactly what being a member of the team will involve. Others are simply excited about the task ahead. This stage is usually fairly short, and may only last for the initial meeting at which people are introduced to one another. At this stage the team has a high dependence on the leader for guidance and direction. The leader must be prepared to answer lots of questions about the team’s purpose, objectives and external relationships and be aware that some team members may feel frustrated and anxious to get on with the tasks ahead.
Storming – stage 2
Storming soon follows and decisions do not come easily within the group. While the ways of working start to be defined you must be aware that some team members may feel overwhelmed by how much there is to do, or uncomfortable with the approach being used. Some may react by questioning how worthwhile the goal of the team is and by resisting taking on tasks. Team members may also vie for position as they attempt to establish themselves in relation to other team members and the leader, who might receive challenges from team members. Clarity of purpose increases but plenty of uncertainties persist. The team needs to be focused on its goals to avoid becoming distracted by relationships and emotional issues. Compromises may be required to enable progress.
Norming – stage 3
Gradually the team moves into a ‘norming’ stage as the way of working and the hierarchy is established. Agreement and consensus form among the team, which responds well to facilitation by the leader. Roles and responsibilities are clear and accepted. Big decisions are made by group agreement. Smaller decisions may be delegated to individuals or small teams within the group. Commitment and unity is strong. The team may socialise together and team members are able to ask one another for help or constructive criticism. There is general respect for the leader and some of the leadership is shared more by the team.
There is often a prolonged overlap between storming and norming behaviour: as new tasks come up the team may lapse back into typical storming stage behaviour, but this eventually dies out.
Performing – stage 4
When the team reaches the ‘performing’ stage, work leads to progress towards the shared vision of the team goal supported by the structures and processes that have been set up. Individual team members may join or leave the team without affecting its performance. The team has a shared vision and is able to stand on its own feet with no interference or participation from the leader. There is a focus on overachieving goals and the team makes most of the decisions against criteria agreed with the leader. The team has a high degree of autonomy. Disagreements occur but now they are resolved within the team positively and necessary changes to processes and structure are made by the team. The team is able to work towards achieving the goal and also to attend to relationship, style and process issues along the way. Team members look after each other. The team requires delegated tasks and projects from the leader. The team does not need to be instructed or assisted. Team members might ask for assistance from the leader with personal and interpersonal development.
If you are a team leader, your aim must be to help your team reach and sustain high performance as soon as possible. To do this you need to change your approach at each stage. The steps below will help to ensure you are doing the right thing at the right time:
1. Identify which stage of team development your team is at from the descriptions above.
2. Consider what needs to be done to move towards the performing stage, and what you can do to help the team do that effectively.
3. Schedule regular reviews of where your team is and adjust your behaviour and leadership approach to suit the stage your team has reached.
If you are a team member, bear in mind the four stages and try to identify where the team is and where you are in relation to the rest of the team so that you can help to accelerate the progress towards a performing team.
DEALING WITH TEAM CONFLICT
When a number of people, each with different experiences, points of views and objectives, come together to work towards a goal, there is a chance that conflict will occur. Conflict can create an unpleasant working environment and represents a risk because the team is less likely to achieve its goals while the conflict persists.
Signs that conflict is an issue include:
• delays and absences;
• blaming and complaining;
• hostility and passive–aggressive behaviours;
• non-compliance with requests.
These behaviours alone do not necessarily mean that conflict is an issue. Deadlines may be missed and blaming may occur without conflict necessarily being the cause. If the goal of the project is understood clearly and the tone has been set for open communication within the team, you will have the best chance of avoiding conflict, but conflict can still arise because of, among other things, personality conflict, lack of skill or boredom.
The fact that conflict has occurred is also not necessarily a negative thing. Conflict that has been resolved successfully can have a positive impact on the team beyond restoring the peace. A stronger, more cohesive and productive team is likely to emerge and it can lead to personal and professional growth of the individual members of the team.
The best person to help resolve conflict is the team leader or someone who has the authority to lead in the eyes of both the business and the members of the team. This person should also be able to remain calm, factual and focused on finding a solution. The best way to resolve conflict is to establish what the issue is that is causing the problem and the most powerful way to do so is to get the team to define the issue together. Once the issue has been defined, understand the issue based on data gathered, not emotion, before deciding on the possible solutions. Managers should also examine whether they themselves were remiss when examining the causes and possible solutions of the conflict.
Some tips to help the manager or other role appointed to resolve the issues are:
• Listen more, talk less. Understanding where the parties are coming from is the key to finding the right solution. Encourage the rest of the team to also listen more instead of defending an existing position and to use questioning as a tool.
• Separate people from problems. In most cases people are not just being difficult. Finding the real and valid points of view that lie behind conflicting positions and discussing those differences means a greater understanding of issues will be achieved without damaging working relationships.
• Focus on relationships. As far as possible, make sure that everyone treats each other calmly and that you are building mutual respect. Lead the way by being courteous to everyone and remaining constructive even under pressure.
• Explain the facts. Agree and establish the objective observable facts, not emotions, that will have an impact on the decision.
• Explore solutions. Be open to the idea that a different solution may exist and that you can get to this idea together.
Implementing the solutions will benefit from team involvement where appropriate. If a single individual or issue has been the cause of the problems, the manager may need to take action without involvement from the team, but the actions taken to support the individual to perform better should still be noted and appreciated by the whole team.
THE WORKING ENVIRONMENT AND WORKING PATTERNS
The working environment for a UAT team can be problematic. The ideal image of a team in its own testing laboratory is seldom reality for UAT teams. A more common reality is a distributed team with members working from their own normal place of work and communicating electronically.
Environment matters to our sense of ‘team’ and to our sense of the importance of the task we are performing. Working in your familiar environment brings many distractions because all your day-to-day colleagues will expect you to respond to them as you would normally. The inevitable outcome of this situation is that you will struggle to get your UAT tasks completed as other priorities intrude. This is a recipe for wasted time and effort and probably a very patchy and incomplete UAT.
What can be done to achieve an ideal environment? We can split this into two components: how we achieve a sense of ‘team’ and how we achieve focus and commitment to UAT tasks.
For a team to perform, it must be allowed to progress through its natural growth and development and that requires dedicated time together to act as a team. It matters little what a team does in this phase as long as what it does is not seen as a waste of time and effort by team members. Training is one team activity that promotes ‘teaminess’. If the team is trained as a team and the training is directed at achieving high levels of interaction and preferably some opportunities to express ideas, and discuss and agree or disagree about relevant topics, the impact on the team can be dramatic. Carefully planned preparation for UAT that includes some tricky issues to be debated (such as what do we do if pressure of work from our ‘home’ department affects individual performance) can have the effect of airing issues that would have to be confronted eventually anyway. Here they can be debated in a ‘safe’ atmosphere and team members can begin to build trust and confidence in their teammates. Keep in mind the importance of spending some of the training time on team building and spend some time before the training to ensure the trainer understands what is needed and has planned appropriate sessions (preferably spread among more conventional ‘technical’ sessions).
Focusing on the UAT tasks in hand is an integral part of achieving effective team behaviour. Once the team has been formed and trained, it needs to spend time together so that everyone gets a sense of the importance and priority of tasks and understands what their teammates will be doing and how they depend on our own progress to enable them to achieve their objectives. Wherever the team is expected to work from, it must find a place that is its own (even if that is a pub or café outside the workplace) so that members can spend some time together on a daily basis. This may entail ‘overtime’ if the only time available to meet is after work, but it might be possible to arrange a short meeting just before or after the lunch period or, better still, at the start of each day. The advantage of this is that the team meeting is an opportunity to become energised and focused on the team’s needs so that team members return to their workplace in a positive frame of mind. Communication during the day, even if it is not essential to getting the tasks done, will then provide regular refreshment of the team’s sense of belonging.
One good solution that takes account of the business’s need to keep UAT team members engaged in other work might be to share time; half the day on routine work and half on UAT work. It is vital to align every team member’s ‘UAT time’ and for them to have a place to work on UAT away from the normal work environment. If these can be achieved the team will have a solid base to work from.
Finally, never forget the social aspect of work and teams. If the working patterns do involve working, say, afternoons on UAT, there may be an option to extend the working day to get more time on UAT and occasionally to extend the day into an evening social event where team members can relax together and enjoy each other’s company away from the pressures of work.
If you are fortunate enough to be able to work exclusively on UAT during the project, the earlier points still apply. The best time to work will probably be when the rest of the business is not around (especially if you do not have a dedicated work area) so a shift from day to evening working can be a good option.
BASIC DISCIPLINES
All that has been said about building teams and operating effectively depends on individuals behaving in an appropriate way. The team-building activities will help to resolve any dissension about behaviours but it is also good to have some rules that help the team to function. Here are some that have worked well in the past:
1. Start each working ‘day’ (whatever your working period is as a team) with a short (10 minutes) ‘stand up’ meeting in which you briefly share any problems from the previous day and any concerns about the day ahead. A ‘stand up’ meeting is just what it says – everyone stands because it is a short meeting and we do not need or want to get comfortable.
2. Give your teammates respect by never being late for a meeting, review or any joint activity. That will also save the massive cost in wasted time of people waiting for others to arrive.
3. Always get done what you have committed to. If you are absolutely prevented (by illness or by another priority forced on you) make a point of contacting your teammates to explain and apologise. It will enable them to find a way around the problem that is created for them.
4. Keep everyone informed about anything that forces a change of plan or a delay by email or telephone.
5. Make a point of speaking to all of your teammates at least once a day even if your work tasks do not necessitate it.
6. Remember you will all be under pressure at some time or other. Be prepared to listen to a stressed colleague to help them to relieve the pressure they feel and be prepared to share your own stress with teammates. It helps everyone and enhances the sense of ‘team’.
All this amounts to the idea of putting the team first. If every team member behaves in a way that puts the team first, they are also putting their teammates first and the impact of those simple courtesies can be significant in terms of productivity as well as making life more pleasant for everyone.
CHAPTER SUMMARY
This chapter has addressed two key concerns about teams:
• How do we select and prepare them for the technical tasks they must do as a UAT team?
• How do we build and maintain a ‘performing’ team?
In addressing these concerns we have also identified many of the challenges, frustrations and problems that UAT teams will have to face in doing their work effectively.
One key message that this chapter embodies is that it is never too early to begin the work of a UAT team. There is work to be done right at the beginning of the project in helping to ensure that business requirements are well defined, and there is definitely plenty of planning and preparation for the UAT exercise to be done later in the project.
Whenever and however the team is formed, there is an opportunity for UAT team leaders to begin preparing and planning how to achieve the objectives of UAT before the team is formed so that this ‘shaping’ work can be used to encourage team building before the team has to deliver testing under pressure.
The way the team is set up and trained will have a huge influence on its effectiveness in the face of the many distractions, frustrations and problems it will face in performing its work.
What have you learned?
Test your knowledge of Chapter 4 by answering the following questions. The correct answers can be found in Appendix B.
1. Which of the following is a key role in a UAT team?
A. Business analyst
B. Project manager
C. Test manager
D. Trainer
2. Which of the following is the second stage in Tuckman’s model of team behaviour?
A. Storming
B. Norming
C. Performing
D. Forming
3. Which two of the following are positive actions to promote ‘teaminess’?
A. Provide everyone with a written job description
B. Communicate the purpose clearly
C. Encourage those with technical skills to take the lead
D. Encourage open communication
E. Make firm decisions and ensure everyone knows what you have decided
Some questions to consider (our responses are in Appendix B)
1. Your most knowledgeable UA tester has been identified as a complainer. What would you do?
2. One team member is being regularly distracted by their line manager to do routine tasks. How would you deal with this situation?
3. Your company does not have space to house the UAT team away from the rest of the business but is willing to give the team half of each day to work on UAT. How would you organise the team to work?
4. Your company provides a room for the UAT team to work in but takes the view that all your normal work must be completed as usual during UAT. How would you ensure that the UAT meets its deadlines?