The basics of test automation

Test automation means saving time, not only for the first execution but mostly for the next ones.


Although technical expertise is an asset in this field, it’s certainly not the major asset, since beyond languages and technologies, notions of design, coverage, readability and maintainability will distinguish good scripts from useless ones.


In the course of my experience, I’ve noted the following points about automation that I feel need to be checked:

  • Reusability of scripts


Autotests should not be “one-shots”, but should remain as functional as possible on different environments and be reusable several times, particularly for non-regression.


  • The design


Yes, being technical isn’t enough! It may be necessary to use design techniques and identify both valid and invalid cases. Writing test cases is an art, and soliciting other people’s opinions is a must!


  • Coverage


You need to cover as many aspects as possible, but always with a minimum number of test cases. Think in terms of execution time, and try to build a relevant, redundancy-free legacy.


  • Readability


A clear and readable script is the basis, but don’t neglect the structure and relevant comments. Turnover happens in every company, and you need to think about the people who might come back and try to read you again.


  • Maintainability


The last point is crucial. Whether using low-code / no-code languages or tools, it’s essential to understand the notion of “object” so dear to certain programming languages. If an object/module is the same in several scripts, it must be modifiable at a single point, just like actions/functions/methods that are repeated. This avoids having to repeat the same modification on several scripts.


In web automation, we call this principle the Page Object Model, otherwise known as POM.


What do you recommend? What are your recommendations?




Get knowledge, news, inspiration, tips and invitations about Quality Assurance directly in your inbox.

share the article