Hello guys need a advice. manager is asking QA team to start working on automation but we have some projects that are ongoing that will change most of the flow of our system. is it worth to start automation now because those scripts will all fail once new projects came. what to suggest effectively in automation meetings. they have higher expectations about automation from QA team.
The glib answer is don’t wait to start.
My experience is, that not automating early could harm you, but automating the wrong things too early definitely will harm you. That said, automation is a journey, a long journey, very long really. So starting out unprepared is a good way to waste time, but not sending a scout out ahead so they gain some automating experience even if they “cover territory” on a product you are about to drop support for, might also be unwise. We could also talk about design paralysis forever.
I advise choosing your bravest warrior, and make sure they go out far, and come back safely.
I would only focus on API automation, it has less maintenance and it’s less likely to break. If you are talking about UI automation… that’s rough… it depends on the project/context and how much is going to change. You’re going to have to look at the ROI there.
Here’s some topics on how to start with automation:
- 30 Days of Automation in Testing | MoT
Getting expectations correct may be more imporant than the consideration of when to start.
I’m just looking at a refresher applitools intro video. “setting a foundation for successul Test Automation” currently.
As I watch it I am just thinking if I had access to this 20 years ago when a number of managers asked me to start the team on automation it could have been a lot of value.
If you have a good working environment set up a session that includes the manager and a couple of testers, automators and developers and perhaps just watch the first chapter together as a starting point.
It may help you question what your real goals are and consider a strategy to match.
It may even get you aligned as a group and in which case you can move slowly forward with potentially more reasonable expectations.
I am not sure how open my manager at the time would have been to sit down and watch a training video with me but I think its worth a try.
The first thing I’d like to know is if the manager actually knows what he wants to achieve from introducing automation. What are their expectations? Automation should be designed with these in mind. It is also important that you communicate what can reasonably be achieved to your manager. In my experience, it can usually take a few months before there is any return of investment.
You can start sooner, in fact I would encourage this. Starting sooner will take the pressure off later on. Since the workflow is likely to change, I would put a strong emphasis on making sure the tests are maintainable and can easily be updated. Split up the test steps into smaller functions that can be reused in other tests, so that updating individual steps is easier and test steps can be easily rearranged to match the new workflow. This is generally good practice even if you don’t expect things to change, as you never know how the application may change in the future.
As new projects are started, make sure that automation is included in the definition of done so everything is updated as the application is changed. For every change to the workflow, make sure an/y existing automated tests are also updated. If the automated tests don’t already exist, then create new ones. Break the work up into smaller chunks, complete it all as you go.
There are n number of situations when you will notice that automation testing is must be included, here I am going to list out such situations as;
→ To improve Speed & Efficiency
→ To Improve Quality of product
→ To overcome cost
→ When there are test cases repetition
→ When there are a number of test cases under one test-suite
→ To improve test Coverage
→ If you want to test single functionality
→ When you need to run Regression
I found one of the best source on this topic, you can check here: When Should You Adopt or Start With QA Automation Testing? - Testrig
Automation testing is always considered as most efficient option when it comes to technology. It obviously going to make the process quicker and that is why most organizations are turning into automation testing companies. Although, test automation scripts might save time on software validation, but they add maintenance time and often increase the complexity of tests. Test automation also requires maintenance, and it generates technical debt. Below given are some points which can help with maintenance of test scripts when flow of softwares changes a lot:
- Focus on sophisticated scripts to minimize test automation maintenance. A small, prioritized test suite can be better than an exhaustive one.
- Adaptive test scripts simplify the work : When you design a test, avoid repeating code, and write the minimal amount of code necessary to accomplish the task.
- Test management increases software quality : Poorly written automated tests are time-intensive to maintain, and they create long waits while tests are non-functional, yielding zero value. To track the value of your tests, measure how often they run, and how often they catch bugs.
- Fit the test process to the situation : The right approach is tailored to the situation. If you have a well-designed, comprehensive test suite, but speed is of the essence, run a subset of those tests to provide quick feedback to developers.