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 test automation framework design (or automation test design).
In this post, we will look at three of the most important things 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 significant specification documents but identifying a problem that needs to be solved before you create the solution.
It is vital to understand what you need your automation to do, what the goals are, and how you can measure the success of your implementation.
Once you know what you need, you should establish what you can achieve. Iterative development in agile is about taking small steps forward to continuously improve your product, taking onboard feedback, and acting on it. You will also need to understand the dependencies and constraints for your automation project – financial, time, and 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 most precise 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 its automation. A truly dynamic, functional, 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 and 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 clearly understood what we wanted to do. So what went wrong?
While we were looking to understand what needs from our new platform, a decision was made outside our team; that decision determined which tool we should use and 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 significantly affected by changes. Involving those who will be directly affected, impacted, and who will now benefit from the automation at the beginning of an automation process will not only help not to 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 available help bring about a shared understanding of the assumption and risks in the project. The earlier those are socialized, the better.
It 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 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. We are 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 about discovering 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 applicable and that you will consider these points when preparing your following automation framework.
Check back for the next part in our series and read more thought leadership from our Salesforce continuous testing experts here.