When the Agile Manifesto was published, and Scrum was formulated, many viewed the Agile principle of “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation” to mean that everyone had to be face to face working together in the same room. Yet, for most organizations, that just isn’t reality. Even pre-Covid, virtual teams have been proliferating across the workplace landscape as globalization becomes entrenched in the provision of services, not just manufacturing products. Regardless of what development methodology you’re using finding skilled talent is difficult. One of the facets or roles on a development team that was often separated not only in mindset but also geographically was QA. However, with Agile, teams have been expected to have “face to face conversation” which implies being together in some sense. Hence the challenge, not just for QA in Agile, but all roles within the Agile process. What if your Product Owner, Scrum Master, Developer, and key stakeholder are all separated geographically? And particularly for QA, if you were tasked with implementing a virtual QA team to support an Agile development team what challenges could you expect and how would you overcome them? Over the years at XBO, we’ve learned a thing or two in actually implementing virtual QA teams and would like to share some insights. Overcoming Virtual Challenges For starters, please take time for this webinar, Overcoming Virtual Challenges, by Heidi Araya. In it, Heidi discusses common types of virtual teams, the challenges they face, and how to overcome them. As a bonus, she addresses some best practices for virtual communication and provides recommendations to encourage better collaboration, teamwork, and effective online meetings. Implementing Virtual QA in Agile – Some Good Practices to Keep in Mind Successfully setting up and managing virtual QA teams within an Agile process depends on a variety of factors. Below, are our best ‘Good Practices’ for building a virtual QA framework for success. \tThere should be an information-sharing system to document the latest information with regard to the user stories, tasks, defects, and decisions made. \tThere should be an issue tracking system (i.e. JIRA) to document processes and implement workflows. This also serves as the organizations knowledge common repository to track and measure progress for the entire development process. \tQA should understand the business background and objectives as much as possible in order to start testing from the user story creation. Combined with 1 & 2, this enables development of acceptance criteria which can force a clarification of features and drive development. \tQA should understand the development process and be able to report key metrics in order to make decisions such as whether the release should go live and what areas need further testing. \tDevelopment processes should be lightly documented and include how a build is made, how a user story is developed, how the code is managed, checked in, etc. \tMany think that ‘Agile’ has to be all co-located but not necessarily true. Sometimes there is benefit from the overlap of time zones in using geographically separate teams. As long as there is enough overlap for good communication, and tasks are assigned well, this way the team can effectively work around the clock. \tAdditionally, many believe that in Agile, everyone does everything. Just like a football team, some people are better at certain positions. Have people doing what they are best at. That means developers doing unit testing and some integration testing, but it may be best to save their time for developing rather than other higher-level types of testing. \tTest automation should start as early as possible. But the goal should not only focus on automating test cases for regression, but also put significant effort into reducing the cumbersome work/steps during tests, such as test environment setup, test data preparation, test configuration check before testing, and test results update. \tIf resources permit, provide QA with the API instead of the GUI to test as the GUI may change dynamically over time. \tTo be Agile, tasks must be small and estimable in size and organized. Without user stories and tasks broken down into small pieces (i.e. 2-3 days to complete by one person), understanding the complexity of the task (and hence the user story) becomes cloudy, and hence inaccurate. This leads to inaccurate estimates of the amount of work for a release or iteration, and can therefore lead to delays in the entire process. A team assistant can help make task breakdowns and keep things organized during the initial setup phase. A new Agile team needs a master/guide to help the team members to form the right habits of collaboration at all levels and across functions. This can be much different from what they are used to.