How can I prove/showcase the value I add as an automation tester to (high) business?

Question

Say that I am a sole QA in a new project, and a first-timer in automation testing in the department (no prior experience or support network). Initial participation in the project (handful of weeks) ran smoothly and even received positive comments from the team. The problem is that in the last sprint, creation of any further testing is blocked due to:

1. lack of new features (I've automated what I have available),
2. devs do not want me to "test CSS" but only work on visual regressions (without elaborating why, are the design or the requirements expected to change?)
3. I only have a local environment and cannot access/authenticate with the "dev" environment, and everyone is too busy to unblock me.

Now, I've been told that as part of this sprint I need to "prove/sell" the idea of automation testing to a high-level manager.

I have already written wiki documentation regarding my setup and what is tested (which I also have in spreadsheet form), I do visual regression with cypress, and I generate mochawesome reports.

Based on your experience, how should I approach this situation? How can I produce a testing plan and potentially track metrics/KPIs that showcase the time earned from not having to do manual effort, or how the tests protect from visual/functional regressions?

p.s. I've read more than 50 potentially relevant questions but I do not think they covered the concerns of my question, so I will attempt to provide some context for my case. Note that I considered posting in "workplace.SE" but I am not concerned about the team dynamics or potential "cost cutting" at this point.

Answer 1

Short Answer: Value of automation is in long term regression testing over a period of weeks, months or even years.

Long Answer:

The more comprehensive (from business perspective) coverage and frequent the automation execution is over long term, the more it will add value in saving manual test cycles, which gives the required ROI to convince/sell it to the management.

Having said that, it is not a silver bullet which can solve all test problems or even completely replace manual testing.

In the best case scenario it compliments thoughtful, skilled & creative manual exploratory testing.

Practical Advice: Develop an POC

In the given scenario, I would identify the smallest possible & highly condensed area in application (based on manual testing experience) where most/or major bugs were found frequently previously.

I will automate 2-3 scenarios to showcase practical value to the stakeholders in the form of an POC (Proof of Concept) result analysis as part of Demo.

Answer 2

Ultimately what I aim to provide with automation is a faster feedback loop between the point of time in which the code is written and the point in which the defect is discovered. By reducing the time in this feedback loop you are able to have the defect addressed over a shorter period of time, while the code is still fresher in their mind and the fix is much easier and quicker for the developer to write.

The second goal with automation for me is to handle regression. In Agile, there is rarely time to do full regression if it is being done manually. This requires some sort of automation to validate that the day to day operations are still functional.

Answer 3

First read Experiences of Test Automation (the link is to a sample), you might get some ideas.

Then ask yourself, any be honest with the answer: "What real value did my automation brought to the team" ?

If you don't count issues you've found during the development of automation or immediately following it (because then it falls under exploratory testing using tools), there's a good chance you'd be surprised with the answer. My experience shows that the answer is going to be something around "not much".

So what are you going to do ? try presenting yourself as a modern tester whose job is to Accelerate the Achievement of Shippable Quality, the principles are here but there's a lot of material if you search for it.

Answer 4

Everyone have discussed about the merits like fast build feedback , more coverage etc.

But i think you could also reiterate on few things like:

1. How many projects/ product do you handle
2. How many features are there to be tested in each
3. How many test cases have been identified for each feature , so lets say 10 test cases and 20 features. So total identified tests are around 200.
4. Whats the sprint size and how much time you get for testing . Say 3 days.
5. Whats the release cycle ? every 3 days or every week?
6. How is it difficult to test 200 tests every 3 days or week without human errors
7. How addition of new features could increase the test effort as testcases increases
8. How this will affect effective regression testing as its humanly impossible for single QA to cover all tests.
9. How easy to start early when there are less features than waiting till we have more features and less time.

Answer 5

If I would need to present a case for test automation I would walk my managers through the results of the State of DevOps 2019 (Forsgren et al) survey.

It has some shocking results on page 18, comparing teams on the following key DevOps metrics: Lead time for changes, Deployment frequency, Change failure rate and Time to restore service. These are the metrics that have the highest impact on business results, eg more money!

My current team has a deploment frequency of more than a month, lead time of four weeks and our time to restore is indeed more than a day and sometimes more than a week. Change failure rate is also relatively high.

Good and fast test automation is needed to improve all these metrics. If you are a modern software development manager and you ignore these findings in the State of DevOps survey...certainly the result to business growth...that means it time for me to suggest some career planning suggestions to his/her boss and or sponsors.