As a software test engineer or developer, you will already be aware of the benefits of test automation and the technical debt it can save when you have the privilege of developing the automation framework (or automation test design).
In this post, we are going to look at three of the most important things that you should address as you begin your automation journey.
Before a line of code is written….STOP
Here are three principles for successful test automation design to set you and your teams up for success.
Gather your requirements first.
There is almost nothing more important than requirements in software development. We are not talking about big specification documents, but identifying a problem that needs to be solved before you create the solution.
It is key to understand what you need your automation to do, what are the goals and how can you measure the success of your implementation?
Once you know what you need, you should establish what you can achieve. Iterative development in agile is all about taking small steps forward in continuously improving your product, taking on board feedback often and acting on it. You will also need to gain an understanding of the dependencies and constraints for your automation project – financial, time, people?
Requirements should be gathered agnostic of tool, language, or skill. Doing so will enable biases to be removed so that you can see the clearest picture of what is required before making those crucial decisions on what your test automation design needs to look like.
An Example of the Test Automation Design Process Gone Wrong
Years ago, I had the opportunity to work in a global automation platform team. This team had a dream to bring together our automation experiences to create a platform on which each satellite office could build their automation. A truly dynamic, useful, modular and scalable platform. Our initial ideation meetings were promising, and we agreed to go and gather the requirements of those who would be using the platform, as well as those who would be directly impacted by or would benefit from our upcoming work. From that work, we generated a backlog of items, prioritized them and had a really clear understanding of what we wanted to do. So what went wrong?
While we were looking to understand what was needed from our new platform, a decision was made outside of our team, that decision determined which tool we should use, which language and platform. All without the context that we had worked so hard to establish.
This predetermined tool could not meet the needs of the end-users or stakeholders, thus leaving this project destined to fail.
Change the Automation Test Process Collaboratively
There is a big difference between change happening to you and you being a part of the change. The dynamic and equilibrium of a team can be greatly affected by changes. Involving those who are going to be directly affected, impacted and who will directly benefit from the automation at the beginning of an automation process, will not only help to not destabilize the team, but also to organically bring about buy-in, goodwill and allies to bring about future success.
Software development is, after all, a team sport and quality is everyone’s responsibility – automation should be the same. Designing and building in the open helps bring about a shared understanding of the assumption and risks in the project, the earlier those are socialized, the better.
This should not be your solution, but our solution.
Future-Proof Your Test Automation Design
Technology doesn’t stand still, it is ever-evolving and we should always keep that in mind when we are designing our automation solutions.
What we want to avoid is an outdated and flaky solution, where a failure from a test leads us to question the validity of the test, rather than a fault in the target solution.
We can mitigate this by building for testability, scalability and maintainability.
We should treat our test code with the same respect and rigor as production code, with coding standards and reviews. Building the benefit for those yet to come, or even future versions of ourselves, with good commenting and modular reusable code.
We can learn from mistakes and failures, testing is all about the discovery of information to learn more about our capabilities and confirm what we can do. We hope you have found our guide on test automation design principles useful and that you will take these points into account when preparing your next automation framework.
Be sure to check back for the next part in our series and read more thought leadership from our Salesforce continuous testing experts here.