Usually when we discuss automation in QA’s releam, it is usually associated with functional aspects (UI automation, Backend automation, API Test automation, Compatability test automation, etc ) and non-functional (load, performance, stress, availability). But how do you see QA contributing to automation in rest of the SDLC? For e.g. automating build and deployment, automating the test reporting, automating monitoring, etc.
Do you feel these categories of automation are reserved for the roles like DevOps or SRE? Or do you feel slowly and steadily Automation Engineer will be the role which clubs the responsibilities of Automation QA and DevOps ?
Realistically, it’s up to the individuals and the organization to decide on the roles. Obviously, there are considerations for time, skillsets, and benefits.
I see the role of QA as being “whatever it needs to be in order to support or improve the quality of the software being tested”. Among the things I’ve done as part of that are building a CI/CD pipeline, building custom reporting for the test results, customizing our in-house Team Foundation Server installation, maintaining and monitoring the sync we use to connect TFS to Rally (the cloud software we use for work management), writing and updating application documentation, writing and updating user documentation, creating database dictionaries…
You get the idea. If it helps me and the dev team I support to maintain or improve the quality of our software or our management of it, I’ve learned how to do it and done it. My actions have nothing to do with the recent popularity of AI: I’ve just seen a need and taken action.
Hot take here, I think “testers” that do not test but do automation is in fact developers and not testers. So this question to me is should developers limit what they can develop. Automation like most other fields in development is a deep area where you can spend a lot of time before you will master it, so staying in the field to become better is absolutely viable.
In general you want the T-shaped people in your organisation that have an area of expertise but also can dabble in other areas as well, since that provide you with a good mix of productivity and flexibility.
So the question is if, working as an automation engineer you should only focus on the execution and reporting of automated scenarios?
That depends on what you were hired to do, how willing you are to learn more and help in other places, if your carer progression depends on it, if you enjoy doing other things, what effort it takes out of you and what risks you’re not helping uncover, how friendly you are with your mates, etc…
If your automation is vital for the testing support, or the current work that you do then you should focus on improving that one until you have high confidence and free time.
That can be in the form of refactoring, porting into cloud, switching technology, reducing execution speed, parallelizing, reducing flakiness, adding a smart mechanism to detect if failures, auto-create tickets in ticket system for any failures, teach/coach others into the framework usage, learn tricks/tips from devs on how to improve the framework, create a smart variation system(randomizing steps, or data used when interacting with the app).
When you have free time you can think of what testing problems can make use of a tool or script that you can build. Sometimes it’s testers needing some code/scripts, sometimes it’s developers, or support, or business.
The number of things that you can do to support in assessing the quality of the product, or improving the quality of other teammates can be endless.
You could also look at it from a career progression point of view. If you can demonstrate that your automation skills extend to the occasional pipeline (as an example), or extracting build reports into readable HTML, or any number of other tasks, you’ve shown that not only is your knowledge expanded, you’re also willing to work in a team.
Look at what katepaulk posted, there’s a great example of a very ‘sellable’ person. Put that next to someone who has ‘just’ done test automation and it’s clear who gets hired first.
I agree with @katepaulk I think a testers job is do whatever we need in order to support or improve the quality of the software. This is true regardless of your title (tester, QA, automation engineer, SDET, etc.) and the only difference is the amount of time you are expected to do one thing (explore) vs the other (program).
Listen, a lot of the way people talking about testing (which includes automation) is really generic (and/or at a high level). They talk about interfaces like API or UI, or specific test techniques like load, performance, functional. In reality there’s a lot we do: risk analysis, reporting, monitoring, data analysis, discovery, oracles, designing experiments, creating test data, looking for sequences, etc. Some of those things we can use automation to help us with.