Setting the foundation for test automation success
Introducing automation to existing test process allows you to take advantage of what systems do best. The consistent, repetitive action that leads to lower test execution times and faster insights.
But with a high percentage of test automation projects failing due to a myriad of reasons from a lack of understanding of what automation is. And what to automate in a set of tests (hint: it’s not everything). Many people are not starting in the best place to allow future success for their efforts.
Test automation has the potential to generate a huge ROI for your organisation. But to reap the rewards. You need to take the time to develop a robust strategy which helps set the expectations of everyone involved. This should identify key information such as your goals, the roles of everyone involved in the development process and your long term vision.
Start with culture change
Software testing is often a time-constrained activity. Given a slot of time to test a particular feature. Traditional manual methods will easily be able to fill the allocated time slot. But often there can be much more that we would like to test.
While automated tests are pretty cool. Their ability to create more testing time isn’t something they can do.
But what they can provide is a basis for you and your testing team to be efficient and much more productive in your testing sessions. For example. You can set off a set of automated tests to ensure the login feature of your application is still functioning. While at the same time, freeing you up to perform exploratory testing.
This highlights two key concepts that are important to grasp at the onset to encourage the right culture.
Automation only enhances human testing
(I’m using human testing as a synonym for manual testing).
There seems to be a misconception with test automation that it can completely mitigate the need for human testing. If we take a list of user scenarios for example and turn those into scripted tests for our automation tool. There will be no need for human testing ever again!
Unfortunately, that is not true.
Human testing should never be overlooked and the goal of test automation is not to mitigate it either. After all, test automation is not a silver bullet solution.
The goal of any automation strategy should be to support human testing. It should take the strain off your other testing processes, provide valuable feedback to your developers. And free you to conduct additional testing methods (like exploratory testing sessions).
Increased collaboration is needed
Automated solutions can not be developed in isolation. Separate from your developers, test teams and project managers. Instead, they need to be formed in an environment that allows for comprehensive collaboration between each department.
Software development can be a fast-paced business. With new developments being constantly churned out and ready for testing. The close-knit collaboration of teams will enable comprehensive test automation solutions to be developed. Modifications to be made to current scripts and the dropping of out-of-date testing processes.
All together. This will create a valuable feedback loop that will be vital to powering your test automation going forward.
Decide who is responsible
Developing the tools required for test automation shouldn’t be considered as a side project for your testers. Something that they should only work on when they have ‘downtime’. Or for a limited number of hours in the week.
Instead, it should be seen as its own development project that is just as valuable and important as any other.
However, with that said, it should not be a project for your developers to work on either. With a work-load that is already full of bug-fixing and developing new features. They do not have the required quality time to dedicate towards developing test automation solutions.
Therefore, a separate team of testers should be formed with the required skills to take this challenge on. This can take time if you do not have the personnel and preparing for test automation should ideally be thought of early on.
You shouldn’t take short-cuts with this step. Any test scripts that are developed will need to be robust, maintainable and scale to the future demands of your business.
This is where my services can help with your business adopting test automation solutions. Highly experienced in creating targetted and efficient test automation frameworks. Taking advantage of my services will allow your business to focus on fixing bugs, and writing great software products.
Start small
A journey of a thousand miles begins with a single step.
Lao-Tzu
No matter what you long term goal is. Trying to automate a large end-to-end scenario will not only be incredibly complicated. But it will also increase the time for you to reap the rewards that your investment into test automation can provide.
Instead, a good starting point that I recommend would be to take the key functionality of your application. Automate the process of a sanity check and enable it to confirm if everything is working as it should.
Not only will this be incredibly useful for ensuring that functionality remains after a change in the system. But it will also set the stage and allow stakeholders to see what the payoffs are for investing in a test automation strategy.
Scale and grow
Now that you have the basis of a valuable testing asset. You should continue the cross-departmental collaboration. Begin the process of automating valuable tests cases, not forgetting to mentor internal staff so that they can contribute to the maintenance and growth of your automation strategy.
If you need some ideas on what kind of tests lend themselves to automation. Read this post for some ideas.
The key to a successful test automation implementation is to take the time to understand why you want to introduce it. What do you want to achieve? And who will own the newly developed solution.
Do not set out with big ambitions such as automating all your test cases or replace human testing entirely. Not only is this not possible. But human testing is just, if not more important when automation is introduced.
