I spend a lot of my time with clients figuring out the minutia of how to implement optimal test automation strategies that support their transition to Continuous Delivery. The goal is typically to be able to release software after each 2-week iteration (Sprint).
When faced with such a compressed development and testing schedule, most teams quickly realize that they can’t afford to have a separate QA automation group — there is just not enough time for after-the-fact automation and bug investigations that have to be done with that approach. Instead, the teams are adopting “whole team automation” strategies where system, integration and unit tests are owned and developed by the entire team.
The first and most persistent question I hear from folks who are going through this transition is: “who writes the system/integration tests?” This is usually followed by a discussion about the tester’s lack of knowledge of the chosen development language (Java, C#, etc.) and that some cockamamie, XML-based tool will save the day. My advice is to recognize that the fundamental issue is not the tester’s coding skills, but the lack of proper collaboration on the team. Learning to write most test code in Java or C# is not much more difficult than expressing the same script in XML or equivalent QA-only tool — it is difficult is to write ALL of it from scratch and without proper support.
Allow me elaborate: when tests are well-written, using proper layering patterns such as Page Objects for Selenium and using the ‘builder/fluent’ style, its is quite easy to add additional tests or to modify them when requirements change. Once the initial design is laid out — the rest of the code is quite simple to write and when a tester needs help the developer is right there. When testers pair with developers, they become proficient very quickly — pairing is a very efficient way to transfer skills. Now, when you check in code — you are checking in “units of business value” — that is code with the proper amount of tests to mitigate the risks to quality.
Lets take a look at a real-world example:
Imagine an application which has a Web UI and both internal and external RESTful APIs. We chose Cucumber/Selenium for automating the Web UI and rest-assured for automating the web services. How would this work in a fully integrated team?
The Product Owner comes to the planning meeting with a rough draft of Cucumber feature/scenario scripts that support the user stories that may be chosen for the upcoming Sprint. The requirements are reviewed and clarified with developers and testers; additional scenarios are discovered and added to the Cucumber ‘feature’ files. Agreement is reached on what scenarios needs to be automated with system/integration tests.