Enterprise Software QA Automation: Four Crucial Steps

Recently we’ve covered a topic of combining manual and automated testing in enterprise software development. While this approach is useful, there are also other important things to do to get the most of the QA process. The number one of them is how to implement the automated testing part. Today we will cover four crucial steps which will skyrocket your automated QA efficiency.

Define expectations

It is crucial to ensure that all team members have a common understanding of testing automation results. Such an approach will help you to avoid a situation when you’ve automated something just to find out that a part of the team had different expectations. For example, the QA experts might think that tests should be written to cover the whole software functionality and run at night while the project manager wants to limit the scope of testing to run them fast.

The only solution here is to build an open environment where team members do not become afraid to ask a lot of questions. After you’ve made sure that everyone has an equal understanding of goals and tasks, it’s the time to move to the second stage: defining what to automate.

Define what to automate

It is evident that thoughtless automation is wrong. But how to understand which tests are worthy of automation and which are not?

Here are some tips on what you should not automate from the beginning:

• Tests for buggy functionality/features under development. You will waste time for the initial automation, and further tests rework.
• Automation with negative ROI. You need to calculate everything. For example, you need to spend three hours on test automation. If this test is run once a day, has an execution time of one minute, and you need one minute to analyze the result. In this case, the automation time costs will be 180+2*30=240 minutes. If you need just 4*30=120 minutes for manual testing than it is clear that such tests should not be automated as it won’t save time.

Pick a framework to use

Sometimes there is no choice due to some project restrictions. However, if you can, It is better to spend some time to evaluate the pros and cons of different tools. We at 1Ci had multiple projects where our team faced such a dilemma, and there are main principles we followed to make the right decision:

• Writing tests is convenient. Software development and QA framework is a tool you use every day. Thus, its convenience is crucial. For example, if in your work you need to reference some UX buttons there should not be any unnecessary steps to connect these buttons. You should be able to use parameters in your tests or re-use procedures, etc.
• Tests are readable. Another critical factor for a framework is an easy-to-understand syntax. Every team member should be able to understand what the particular scenario is used for easily.
• Tests are easy to implement. This will be handy when your testing team expands. You don’t want to spend lots of time on new employees onboarding and education.

For sure, you have your product or development process-related peculiarities, which means our principles may not fit you well. Feel free to review your workflow and come up with your own set of things that make sense for your team, project or product. Then map this set with a list of tools you’re reviewing, and assign points for matching with target criteria using a 1–10 scale. You’ll see what framework is the best option for the particular project very fast.

Set up a plan

One does not simply write tests… You need to go to analysts or project manager if there is any, or come up with a list of tests by yourself, assign priorities to each test, etc.

If you do not have a specific set of tests, then you need to start from dividing the whole product by functional areas. For example, when our team needs to test 1C:Drive system test cases, there are such functional areas as Sales, Purchases, Payroll, Production, etc. At the next step, each such area should be further divided to sub-categories with assigned priorities. Like, for Sales functional area “Sales order” document tests may have priority “1,” while tests for email newsletter may have priority “4.” Such splitting is helpful during the evaluation of the scope of work to be done.

Final thoughts

QA automation is often tricky. To not end up burning resources on unnecessary automation, you will have to spend time on analytics, ROI calculation, and assessment of available tools. Only such preparation will allow you to determine which things are worthy of automation, what result you really need to achieve, and how it can be done.