August 31, 2017 // By Bill Roske
As test automation gains acceptance, distributing test development across multiple teams presents numerous challenges. What if multiple teams are contributing to the same project or product? One team may be focused on the UI, another on middle-tier/web services, yet another on a database layer. Left alone, each team may choose the automation stack that best fits their problem space. But now you are left with integrating results from multiple solutions.
How do you encourage self-direction AND have a single, cohesive view of product quality? As with many complex problems, the solution has many facets to it.
Manage Your Test Cases
This may go without saying, but having a single (real) test case management system is imperative to any QA solution, but especially with an automation solution. If you are going to get your money's worth out of your automated tests, you will be running them often. Running them isn't the most important thing, however. You need to analyze the results; looking for new failures in the latest results and looking for repeated or intermittent failures, indicating troublesome tests or application code. You will also want to have manual and automated test case definitions and results in the same system, so you can track how well you are covering your requirements with your testing efforts (manual AND automated). You won't get that information easily from spreadsheets or HTML summary files. Tools like TFS/VSTS, TeamCity and HP-ALM provide this kind of insight and APIs to allow you to publish your results from any automation solution. Just remember, don’t let the Test Case Management solution you choose dictate what test automation stack you use! You need to be more flexible than that.
Treat Your Automation like Development
Test automation is the process of developing software to assist in the testing of products. We need to treat it like a software development project, not "just some scripting." Design your tests and supporting libraries using good design patterns (DRY, KISS and SOLID, to name a few). The intent of your automated test cases should be clear and concise. The coding should not include UI element identifiers, HTTP message formats or SQL statements. Abstract those details out of the actual test cases and into supporting libraries and "models" of the application under test. Done right, this will enable you to make use of various levels of technical ability within your quality team. Like any software, your test automation require enhancements and maintenance. As different teams add to, or change, the framework, keep a backlog of enhancements. Make priority decisions and make sure you are designing and reviewing the changes. The framework is an asset to be protected and improved.
Plan to share your code. Make use of local NuGet repositories, or other library sharing tools (even a local network share) so that the solution of a problem for one team may be consumed by others.
Don’t stop at sharing code. Just as agile teams hold "scrum of scrum" meetings, Quality should be holding a quality scrum. This keeps the lines of communication open between teams. Sharing status, issues and solutions helps keep the quality team working as a group, even when individuals are embedded in separate agile teams. There is another benefit here. Whether we want to admit it or not, our resources are not permanent. Test engineers look for change, just like the rest of us. Having a team that is aware of what others are doing, and how, opens up opportunities for engineers to move from one team to the other. This provides them the variety in their work or coverage when someone is out.
Choose Your Stack Wisely
You need to choose an automation stack. That is, the technology that will be used for the development and execution of tests. If you can, choose one (yes ONE) that does not tie you to a specific level of interface with your application (UI, Service protocol or database). Better still, choose one that supports good test case design and allows you to use the right level of interface for the logic you are testing.
Test automation is not easy. Keeping it cost effective across multiple teams adds to the challenge. Magenic can help your organization. Magenic’s Automation Quick Start or MAQS (pronounced Max) was designed to get your software QA tests up and running in minutes and report results consistently across multiple technologies, helping you deliver a single product quality message across multiple contributing quality teams.