The challenge of working with distributed testing teams and performing a high-quality work.
Summary
Working with distributed testing teams means a significant change in management, perspective and level of effort.
In this article, I`ll try to describe some of the experiences I have gone through during the past 3 years, and the strategies we are implementing to succeed.
Introduction
Those of us who have been somehow pioneers in Testing, know from experience that the specialty has had a difficult childhood. Comparing it with people life cycle, we might agree that Testing has also had a difficult journey through teenage years. We can say that it was not until a few years ago that testing won its own identity, and the practice started being handled in a more mature way with processes, methodology and a broad spectrum of training possibilities. However, can we say with certainty that we are now going through a stage of maturity?
Constant evolution of technology and new global delivery methodologies have enabled us to work in offsite, nearshore and offshore modes with teams distributed in different regions of the globe, taking advantage of varied expertise in multiple disciplines.
But are we really ready to work with distributed teams and still provide high quality services?
How is the map for the onshore, nearshore and offshore service?
The challenge is how to achieve highest performance when working with distributed teams in different locations, how to train them for a homogeneous work, and how to reach the right level of communication so that it doesn´t became a barrier in their performance.
Management of distributed teams definitely plays a fundamental role.
Let's go over some tips that could help us to succeed.
Selection of an offshore team
Once you decide which tasks will be outsourced in an offshore team you will have to focus on its selection.
The selection of an offshore testing team requires an exhaustive evaluation that goes beyond required technical skills. Considering cultural differences and manners, language, time zones and the way of communicating will become a must.
Getting to know the strengths, weaknesses and technical capabilities of your offshore team will save you a lot of headaches in management.
If disregarded, cultural differences can lead to huge misunderstandings between teams; even when speaking the same language, a single word could have a completely different meaning from one country to another.
About training
Training offshore teams is not as easy as on-site or near-shore trainings. To start with, it generally implies a not so short of a trip. It is possible that the offshore team has specific skills different from the ones your onsite team has, therefore, it will be necessary to train them on topics such as methodology to be used for the specific project, testing process used by the contracting company, the way in which the documentation is received, the kind of documentation to be delivered and the business of the final Client, among others. Let's take into account that the main purpose of the training is to provide the teams with the general context of each project and align them into a common understanding and way of working.
Do not forget that your onsite team has multiple opportunities to acquire information from other testers, either from their own project team or from other testing projects, and a broad access to informal communication means. This kind of opportunities practically disappear when working with offshore testing teams.
So, it will be necessary to define a training plan that considers the following aspects:
- Identify and list the topics to be included in the training.
- Set dates and times in which sessions will take place.
- Define best training mode: remote, face-to-face, mixed, or other.
- Define how sessions will be carried out, who will lead them and where will the training material be made available.
- Decide the training material that needs to be read before the sessions.
- Consider full availability of documentation, videos, reading material and any other means to complete knowledge transfer. Do not forget that teams rotate, and people move forward.
- Estimate trainings duration with as much precision as possible.
Despite the chosen training mode, at some point nothing replaces “face to face” training efficiency. So, to obtain better results it becomes crucial to consider a “face to face” mode for at least part of the training. It is very difficult to get people to identify with values, vision and mission of a company through a corporate video or a Skype session.
Each team must be clear about what is expected from them, what are the objectives of each project, how management will be carried out, which communication channels will be used, who will inform tasks or results to whom, when and how. All this must be part of the collaboration environments.
Define how communication will be
It is necessary to define communication channels, officialize them and formally inform them. It is also very important to proactively verify that all members of the project know these channels and have full access to them.
The healthy practice of agile methodologies that maintain daily huddles is a way of improving connection between work teams. It will be important to consider geographical location of the teams since, depending on timezones, the end of the day for some members of the team could be the beginning of the working day for others.
Setting frequent short calls could perfectly avoid long email chains in which it is easy to lose the sequence and generate confusing information without solving the issues.
Teams should take part in planning and effort estimation meetings. This will allow to have a realistic feedback on their possibilities and acquire their commitment with set goals.
On the other hand, it is fundamental to define a focal point of the offshore team, that is, the contact person with whom you can review the progress of tasks, issues and delays that might appear. Soft Skills, among other competences, is a must for the position.
How to maximize productivity of the offshore team?
About requirements:
When an offshore team assumes Functional Testing tasks, beyond the initial training that I have already mentioned in the previous sections, it will be necessary for the team to have clear requirements either in the form of use cases, user stories or any other format depending on the project.
An incomplete, unclear or obsolete requirement is a source of problems. It will surely generate delays and rework in the tasks to be carried out later. "Requirements Review" is in my opinion an extremely efficient practice. If the information received is not enough to define some test cases, development will be facing the same problem as the testing team, since for sure something is missing or wrong and this lack of clarity will also impact the development. The key is to avoid disconnected creativity and work on a common base agreed to by all parties involved.
When this matter remains unsolved, Development and Testing might have their own different understanding of what is missing. Thus, when later executing the tests, we will find us reporting defects that are not real and missing defects that must be reported.
Regardless of the development methodology used, requirements must be always clear, complete and concise.
How to design Test Cases?
We know that there isn`t a single unique correct way of designing test cases.
This issue should be part of a training if necessary. When we have different teams working on one same project, we need to unify criteria for test cases design, defining the level of detail to be used when designing the cases and the information they will contain.
About Tests execution
As for test cases, it is important to define how defects will be reported, and what information the defect report will contain.
All the information generated must be registered and available for all project stakeholders, either for viewing only or for viewing and updating.
About tools
Necessary and appropriate tools for project management should be available for the teams. Make sure to communicate and formalize tools to be used. If necessary, include trainings and periodically check if the tools are being used correctly. Tools will allow to measure at least a large part of the offshore team`s work.
Retrospective
Post-mortem meetings are a common practice of agile teams; however, they might not be familiar in other Development models.
Implement them regardless of the development methodology used! They are an information source that allows you to learn from your mistakes and those of your teams. Don´t think of them as “witch hunting”, they are about identifying points of improvement. Get your lessons learned!
Don´t think of them as “catharsis”, they are about detecting items to be improved and practices to maintain.
Choose a moderator for the sessions, invite to the meeting all technical players of the current project and collect experiences that may be useful for future projects. Identify and record what was done properly during the project and spread it among all teams so that this kind of practices are maintained, as long as they seem useful for future projects. However, keep in mind that what is valid and useful today for a specific project may not be useful for others.
¡Do not miss the lesson!
Some conclusions
For this kind of services, an exhaustive selection of the offshore supplier is highly recommended. The supplier should match your needs and those of the business you are working for.
Do not minimize the importance of teams training, it is essential to reach homogeneity. In addition, full or partial usage of face-to-face training modes, gives you the opportunity to meet those people who will provide you with a service.
Take care of communication, confusing or insufficient communication will lead to many problems and delays in projects.
Use the right tools and register, register, register; do not forget to take record of what has been done!
Last, but not least, do not miss lessons you can obtain from post-mortem meetings. Learn from failures to improve your processes, management and communication.
References
- From Chaos to successful Distributed Agile teams – By Johanna Rothman and Mark Kilby.
- Agile Retrospectives: Making Good Teams great.
- Distributed Agile: DH2A – The Proven Agile Software Development Approach and Toolkit for Geographically Dispersed Teams. By Upradista Venkatesh.
- Managing Global Software Projects: How to Lead Geographically Distributed Teams, Manage Processes and Use Quality Models. By Gopalaswamy Ramesh.
- Distributed Teams: The Art and Practice of Working Together While Physically Apart By John O´Duinn
- Work Together Anywhere: A Handbook on Working Remotely—Successfully—for Individuals, Teams, and Managers. By Lisette Sutherland, Kirsten Janene and Jurgen Appelo
