Geographically distributed QA teams and the challenges that they face are a common and ongoing topic in the software development world. In this article, Kevin Wilson focuses attention on eight simple solutions that can help maximize the effectiveness of your distributed QA team.
The dynamics of geographically distributed QA teams and the challenges that they face are a common and ongoing topic in the software development world. While many of us likely know of several good practices for working in a distributed team environment, it has been my observation and personal experience that even basic routines and good habits can become marginalized and overlooked through the course of time.
If you are a quality assurance professional about to lead or participate in a distributed QA team for the first time, the basic practices below can likely provide a solid foundation for promoting accurate, timely testing and, ultimately, the delivery of high-quality software. If you already have experience working as part of a distributed QA team, these tips may still help streamline your existing processes—or serve as a friendly reminder of practical applications.
Let's assume that you and your QA team are responsible for at least two major product lines and numerous associated applications, each of which requires dedicated sprint cycles and release cycles and may have inherent dependencies. Your QA team has members who are divided across the two product teams and work ten to thirteen hours ahead of your time zone. To make matters even more interesting, other members of the larger Scrum team are located in one or two additional time zones.
As you begin to assess your situation, several questions may come to mind. How do you maintain good communication with your distributed QA team and ensure effective testing in a Scrum development environment? Are there any simple practices that QA team leaders and members can incorporate outside of normal agile activities to achieve their goals?
Consider incorporating some of the simple solutions below to improve team effectiveness.
Solution #1: Send a team email at the end of each day.
Before you leave your office or go offline at the end of a day, take a few minutes to compose and send a very brief email to the QA team. A number of things can change throughout the course of a day—statuses, software build availability, shifting company priorities, etc. By taking the time to communicate your thoughts regarding the QA focus for the next day, you can prevent wasted testing efforts and unnecessary loss of time. As an added bonus, you can use your daily email as a forum for guiding testing strategies throughout the project lifecycle and encouraging overall best testing practices.
Solution #2: Participate in a perpetual IM group chat.
Using an instant messaging software tool available to everyone on the team, create one or more group chats in which conversations can take place twenty-four hours a day. Quite a bit of nuance can occur during the course of a long, real-time conversation thread, and a perpetual group chat can very much aid in keeping track of what was agreed upon and why for a given issue. The group chat is also an excellent forum for making real-time adjustments to QA strategy, resource allocation, and more. Encourage your larger Scrum team to also create a perpetual chat as a means of fostering better Scrum team communication.
(Note: while engaging in a group chat can be helpful, it is important that the team closely guards the scope and integrity of the agreed-upon sprint scope and goals. Stay on track!)
Solution #3: Use a central repository for test cases and viewing test results.
Perhaps nothing can be more confusing or frustrating during the testing process than the possibility of having more than one version of test case suites distributed among team members. Spreadsheets containing test cases can be useful in isolation, but as the test suite is distributed throughout a team, the potential for version control issues significantly increases. It is also difficult to accurately measure the amount of test coverage achieved by team members.
When faced with such challenges in the past, my preferred and most successful option has been to leverage a centrally located test case management tool (either hosted locally or in the cloud). Any edits made to test cases and test suites are visible to all, and anyone can choose to be notified of any changes that are made. Do you ever find it difficult to quantify or visualize the amount of testing progress that has been made during a smoke-testing or regression-testing phase? A centrally located test case management tool will allow you to easily view percentages of testing completion and identify areas of concern (e.g., failed test cases) for both manual and automated tests.
If a test case management tool is not within the budget for your organization, consider leveraging a free, cloud-based spreadsheet application that will allow for access by all team members.
Solution #4: Provide a dedicated QA knowledge repository or wiki.
Make sure your QA team has a common and dedicated space for accessing useful QA-related information. Let this space serve the unique needs of your team and provide useful information about your products, testing environments, testing strategies, browser, OS testing specifications, and more. Have a specific skill or knowledge about a particular feature or product? Write a “How to” article and share it with the entire QA team.
In a previous e-commerce website work environment, I was largely able to become proficient with particular performance testing tools and automated testing frameworks due to a senior team member’s willingness to write thorough “How to” articles on a commonly shared wiki. Share your knowledge and encourage others to do the same!
Solution #5: Have at least one (brief) weekly QA team meeting.
Instant messages and emails certainly have their value, but for many, video or telephone conference calls are still the best way to strengthen the perception that each individual exists as part of a true team.
When attempting to find good schedules for QA meetings, I’ve struggled through phases of trial and error before finding that one QA meeting per week was sufficient. A higher frequency of meetings seemed to interfere with the normal rhythm and obligations of the Scrum sprint cycle. For maximum effect, keep the meetings as short as possible and use them much in the same way the group IM chat is used. Take advantage of the allotted time as an opportunity to discuss current issues and needs across multiple Scrum teams. I’ve found that the meeting can be an excellent forum through which those working on different projects and Scrum teams can share lessons learned.
Solution #6: Have each QA team send a daily status email.
Although testing status updates are provided to the Scrum team for individual sprint stories and defects, having a testing summary email is an excellent means of keeping track of progress at a high level and also being alerted to any specific concerns. As you might imagine, this is yet another action that needs to be brief and not demanding of a team member’s time.
If the act of composing and sending the status email becomes too cumbersome for your team, then it’s a clear sign that it contains too much detail. If your team thinks that even high-level daily emails are a bit too much, try a schedule of three times a week instead.
Solution #7: Regularly ask team members if you can be of any assistance.
When team members located in different time zones are signing off at the end of their day, ask them if there are any outstanding QA matters you can help investigate or resolve. Unresolved issues or unanswered questions can result in a day or more of lost testing time. By dedicating part of your day to following up on QA matters, you also help ensure that the QA team does not become a bottleneck in the sprint release or product release cycles. So as not to conflict or overlap with the duties of the ScrumMaster role, make sure you limit the scope of your activities to QA-related matters.
Solution #8: Share favorable feedback and constructive criticism with the team.
Geographically distributed testing teams can often miss receiving valuable feedback by nature of their remote locations and off-cycle work hours. Whether it's general or specific feedback from the Scrum team or from the larger organization, it is very important to keep QA team members in the loop. Make a concerted effort to let them know they are valued and that their testing expertise is appreciated. And, of course, always share constructive criticism and dedicate time for discussing potential areas for improvement.
Are there any particular practices you’ve found to be either essential or not very useful during your experiences with distributed QA teams? Please share your comments and recommendations!