Agile is one of the most adopted approaches for software development and, no matter if the selected implementation is SCRUM, Extreme Programming or other, they all follow the basic concepts originally articulated in the Agile Manifesto. In practice, one of the most important aspects to be aware of when executing an Agile software development methodology is the interaction between the various individuals on the team. Frequently, close, even intense, collaboration is identified as the key to success on Agile projects.
Much effort is undertaken by the development team on creating working environments that allow easier and more effective collaboration. Many U.S. software companies default to setting up their development teams locally in order to optimize the collaboration process by having all the team members located in a single building, or campus. However, due to the well-documented unavailability of local engineering talent, many companies look to other geographies to help them scale their team. Unwilling to go through the many months or quarters it takes to recruit local talent, they find talented, available engineers through partnerships with software engineering services companies.
The integration of QA teams in the development process can, at times be an issue under regular circumstances. This is particularly true for Agile-based engineering projects, particularly when people are not used to certain collaboration practices. When we add the reality of a geographically distributed QA team, in some cases located in different countries and time zones, the collaboration process takes on added complexity that must be addressed.
The reality is that geographically distributed QA teams collaborating on an Agile-based project can perform just as well as those within a single location – or even better, as long as the right combination of processes, tools and experience are firmly in place.
PROCESS – The key for true Agile collaboration
When there’s little time to perform activities, having a clearly defined process for all those day-to-day tasks is critical. In an Agile methodology, QA software engineers are not just in charge of the application testing, they also have to estimate and specify test cases, report and verify issues, create automation scripts and escalate big issues as part of the daily routine.
Following is a list of recommended actions that will improve the process and make the integration of geographically distributed QA engineers into team collaboration easier.
- Involve QA engineers not just on testing-related activities but also in planning, design and post-implementation tasks. Asking QA team members to participate in planning meetings, design reviews and early application demos will give them a clearer technical and business picture of the overall production. It will also allow them to provide feedback earlier in in the process, helping to avoid larger, more damaging problems within the advanced development stage.
- Make sure clear acceptance criteria is specified (at creation) for every user story the team should work on. The criteria should specify necessary inputs, expected outputs, validations in place and any other expected behavior, allowing development to create the right features while QA verifies the right expectations.
- Standardize the prioritization criteria for detected issues. Make sure that, no matter who finds and analyzes an issue in the development process, everyone will use the same criteria to prioritize. This will insure that attention is given to high-priority items first, instead of wasting time wading through, and then discarding false alarms.
- Define clear communication and escalation processes. As long as the QA engineering team is clear about who should be aware of situations based on the affected areas or the priority of an issue, the team will not waste time – time wasted from having to redirect communications to the right people. The result: issues will get to the right audience sooner, enabling quicker resolution.
- Create traceability mechanisms between QA and development work in order to avoid duplicate work, especially for certain tasks such as testing automation, which are a joint effort between QAs (functional testing) and developers (unit and some integration testing). Defining a small set of labels on management tools to represent phases of the work performed by the parties (i.e., “Unit Tested” or “QA Automated ”) and/or having a process to track each side’s effort through comments can really help everyone to keep posted on the work already done.
- Allow QA visibility by defining a set of metrics to be created and maintained periodically by the QA team, covering areas like bug rates and classification, test case execution, and overall status of the application being tested. This information will serve as a communication channel and will provide important insights about the process and the product itself based on the actual QA work.
TOOLS – The ideal support for your Agile collaboration process
A well-defined process will certainly be a huge step toward the goal of having real Agile collaboration. But if we really want to enhance the process and take it to the next level, we need to add some key tools and make the most of them.
Most software development efforts today have at least a bug management system and some tool to manage user stories /requirements in a more structured way than just spreadsheets or email messages sent back and forth. In the case of mature companies, it’s very likely they also have a test case management tool for their QA team and some infrastructure for test automation at the unit or integration level.
Whether a team uses all or just some of the tools mentioned, the main issue in most of the cases is the lack of integration or cross-referencing between the tools. The QA engineering team automates tests on their side and reports issues on the process. Unfortunately, the team may be unaware of the corresponding user story related to that automated test or the open issues resulting from testing a specific story. There is a disconnect that can lead to unwanted consequences and poor quality.
The lack of traceability between tools can negatively affect the collaboration process, making it unnecessarily complex. The good news, though, is we can solve the issue by adopting some very simple practices:
– For every user story created make sure your development team adds references to sections of the code were they added testing coverage at the unit level. In the same fashion, have your QA team add references (URLs) to test cases on the TC management tool and bug reports found for every specific story.
- Whenever a bug is reported as a result of testing a specific user story, QA can also add a reference to the user story on the requirements management system in order to complete the cross referencing.
- Every test case defined on the TC management tool can be easily identified as automated (either by the software developers or QA engineers) by checking a field for this purpose – when available – or just adding a descriptive label to the TC. Additionally, a comment with a reference to the actual file containing the automation code can be added.
- At the code level, references can be added using the native features of some testing frameworks (i.e., Java annotations) as a way to close the circle of cross-referencing.
Following those simple, practical practices will ensure the whole software engineering team, no matter the individual location, has the required information to determine how the process is going and what is the next step to take.
EXPERIENCE – The final ingredient to make Agile collaboration happen
Knowledge is probably the best tool we can have no matter the activity we perform. QA engineers with experience working on Agile development processes are used to the daily dynamism required, and that’s especially convenient if your QA team will be widely distributed geographically across states or even countries.
Since determining the real Agile experience of a resource can be tricky in an interview, we need to focus attention on a set of more generic skills to make sure our distributed QA engineers have the right profile to collaborate successfully using the process and tools we have defined. Personal flexibility is the key to success due to the variety of activities to be performed on an Agile quality assurance process.
Some of the most important things to look for in a QA engineer who will work on a widely distributed team are:
- Communication skills, both spoken and written, since most of the communication will be done via email, conference calls, electronic chat tools such as Skype or G-talk, or specific reports. There’s a reduced time window for communication, and we need to make sure the message will be sent as clear and quickly as possible.
- Strong technical background to allow deeper analysis and decision-making on situations where answers or clarifications needed from software developers or managers on different locations will take some time to arrive.
- Quick response to unexpected situations so that we make sure QA will keep up with the desired project pace, and will adapt to the changing needs of the project. Even if those changes arrive unexpectedly, and at times unwanted, with short notice, leaving little time for assimilation.
Agile software development remains one of the most popular methodologies. All indications are that popularity will continue to grow. Strong, real-time collaboration between the various individuals on the team remains a key path to success. Paying attention to creation of a streamlined working environment that allows easier and more effective collaboration will insure quality software delivery.
Manuel Cubillo Arias is QA manager at Avantica Technologies. He has over seven years of experience in the software development industry, particularly in the area of Quality Assurance. Currently managing QA related projects for customers of the nearshore software engineering services specialist, Avantica Technologies, Cubillo works closely with startups and the Software 500. Together with testing engineers located in the company’s software engineering centers in Latin America, he collaborates both in traditional and Agile methodologies with customers in the United States, Latin America and Europe.