One of my pet peeves these days is teams referring to their test automation as “test scripts”. To me the term “script” minimizes the role of test automation. It sounds throw away, like something you might whip up real quick to configure your bash shell.
I coach teams to really treat their test automation as software development. On my teams, test automation code must, at a minimum, be:
- Checked in to a source code repository, preferably the same repository as the code it is testing
- Scanned regularly, preferably with every commit, by a tool like SonarQube using the same quality gates and profiles as the application code
- Subject to design and code reviews
- Unit tested where appropriate; for example, any frameworks or helper classes that are built to support test fixtures
Why do I insist on this? Because test automation is not just something testers run at the end of a sprint to make manual testing a little easier. Test automation is a customized tool that the team uses to get early and rapid feedback on application quality. This is an important way to think about it because, as with any tool you might buy, you want one that is well-built and of high quality. It stands to reason that your test automation should be the same way. In other words think of it as a product you are delivering to yourself, as opposed to a customer.
When we get into the design of code, we talk a lot about self-documenting code and code that is easy to read and extend. All of these concepts extend to the code for test automation as well. In fact, it might even be more important. Well-written, easily readable and extensible test automation:
- can serve as a living requirements document and specification of the intended behavior of the system
- allows for rapid creation of test cases
- gives uniformity to the format of test cases that helps both specifications and test case creation
The bottom line is, don’t ignore software engineering principles when building test automation. Insist on teams using the same standards they use for application code. It may take some time to get your testers up to speed in development and/or it may decrease velocity slightly as developers help out getting the test automation off on a good foot but it will pay off handsomely in the end.
Interested in getting hard numbers on your test automation maturity and some expert advice on how to improve? Along with other, longer-term testing-related engagements, Coveros offers a fixed-price, two-week assessment that will provide you with actionable advice on improving your organization’s approach to test automation. Read more here: https://www.coveros.com/services/agile-testing/
