Ashley Hunsberger, Greg Sypolt and Chris Riley contributed to this post.
Bringing test automation into your organization is not as easy as writing and running a Selenium script. It involves getting buy-in, building a team, establishing a strategy and picking the right tools. During the Q&A portion of a recent webinar hosted by Chris Riley, Ashley Hunsberger, and Greg Sypolt, the presentation team realized that while each aspect is well known, it is not well understood. And that is why in this four-part blog post series, we are going to address each one. This post, the first of the series, discusses getting buy-in.
The need and high-level direction for test automation is usually driven by those who do. In an ideal scenario, both the doers and the decision-makers come to the conclusion together that faster, more repeatable testing is more than just a cost-saver. It supports the initiatives of moving modern development practices forward.
But this is not the reality. Those who know what is possible need to sell the idea from the bottom up. For QA, there are many challenges to doing this: (1) QA teams often do not have their own budget; (2) you are not just convincing development leadership, you are convincing your peers in development and IT as well; (3) all aspects are not in your control (such as continuous integration and test infrastructure). So let's answer questions asked during the webinar to give some insight on how to approach buy-in.
What strategy can you suggest to demonstrate the added value of QA to business teams?
Ashley: Are you trying to introduce a QA team to the business? This is just one aspect of it, but consider the cost of a bug. This cost increases the later it is found. Studies from IBM have shown us that a bug found during development costs roughly $25; in a waterfall-centric QA cycle, about $500; when caught by a client, about $1,500. You can read more on that here and here.
Greg: Everyone has solidified release dates. To push back and include technical debt into a sprint or release, it is important to educate the business on what technical debt is and what isn't. Start by creating visibility into existing technical debt and how it can affect future development if left unattended. Lastly, develop a strategy for ways to reduce and avoid technical debt in future release schedules.
How can I encourage developers to start implementing QA standards as soon as they start coding?
Ashley: It's so important that the team understands the definition of done and the acceptance criteria, and it’s even more important that the team takes ownership of quality. Quality should be a mindset that QA is there to help facilitate (and implement). As QA, you have a voice in what should be considered the definition of done! To start, you may want to begin with a very concrete list of things to complete. Ultimately, it boils down to a developer thinking:
1. “I am proud of the development work and I tested it thoroughly.”2. “Everyone on the team reviewed and tested what I put in, and agreed it was great.”3. “It is ready for all customers to use.”
If the developer isn't testing their own work (more unit/integration tests, their own manual testing) before telling the team it is ready, how can they be confident they have met the definition of done? Once teams start developing the mindset that they also must contribute to testing, you begin to dissolve the concept of code, then test. Build tests, build code that passes the tests, release.
Greg: I agree with Ashley’s statement. But let me elaborate! To get buy-in, testing (at all levels) needs to show the return on investment (ROI). When focusing on continuous testing for every change, it automatically fires off tests throughout the delivery chain. Does your team practice continuous integration (CI)? If not, this is an excellent opportunity to demonstrate the value of lower-level tests running on every pre-commit pull request (PR), and provide quick feedback within minutes. Based on my experience, I need to execute proof of concept (POC) to prove the importance of CI and continuous testing. So yes, practice CI, then focus on the importance of reliable lower-level tests will be stable, fast, and then provide quick feedback on the change. GUI tests are slow and can be brittle.
Developers hate GUI tests and think they are unnecessary. At the same time, no one shepherds the GUI framework; it was designed by chaos. How do you repair the damage?
Ashley: Once you have the right technology alignment, demonstrate how and why they are used. For example, we want fewer GUI tests, but we have roughly 40 tests that we consider critical to workflows that should always be passing. We are able to quickly identify when something breaks in the UI … Show that you have deterministic results. In the end, we were able to identify which commit broke our tests, quickly, and discuss it with the developer. Without these tests this bug would not have been caught for two more weeks. Since this was still during the development period, overhead was low, and we got a fix within a few hours.
Greg: I agree with Ashley. The best buy-in from developers, for me, has been technology alignment. Now the developers can help write and review test code. The key to automated GUI testing is reliable processes for developing automated GUI tests, working as a team to determine the right GUI tests needed, best practices for test code, and continuing to focus on ways to eliminate flaky tests, along with confidence in the test results.
Is all of this easier said than done? Yes. Every team is unique. But persistence is the key. Last but not least, here are some other things to consider when making the pitch to your peers:
Dear developer: Fix your bugs sooner so you do not get the pressure of bugs in production. And by the way, if you want to go faster, this is the fastest way to get your code into production.
Dear IT: Infrastructure is your domain, but the pressure of getting temporary infrastructure is just annoying, and could threaten your production environments. So let us build out our own temporary testing infrastructure in the cloud, following your rules, and then you don’t have to worry about it.
Even though it is a grind, the results are priceless. And once you have the buy-in, your ability to build the strategies and testing environment you always wanted is much easier. Read the second post in this series.
