Please enable JavaScript.
Coggle requires JavaScript to display documents.
Designing a test automation strategy (Test Automation (Goals (:red_flag…
Designing a test automation strategy
Test Automation
Goals
:red_flag:Reduce the time that it takes to execute regression testing
:pen:Reduce the manual effort it takes to run the regression tests, and allow testers to focus on testing the new features,to release features faster.
:red_flag:Reduce technical debt by closing your sprints with test automation in place for the new features
:pen:As developers are creating new features and testers are verifying them, there’s not much time for full-on regression testing.
And closing the sprint without automating the newly identified tests only adds to that problem.
:red_flag:enable continuous testing as part of your build process
:pen:developers may want the confidence that what they’ve added isn’t compromising the overall quality of the application.
Communicate the goal to the entire team
implications of automating the regression tests
write the test automation scripts
monitor the results every time the tests are run
update the tests when the behavior of the application changes
Triaging and maintaining automated tests
While all developers and testers can certainly assist in the triaging and updating of test automation scripts, because it’s not their primary responsibility, there’s still a need for someone to monitor this consistently. Unmonitored tests are untrustworthy tests.
How
Which tests should we automate? :not everything is automated
What's the scenario? : the actions and the expected results need to be clearly identified.
What about implementation? :need to choose tooling for your automation project such as a programming language or codeless offering
How will the tests be executed? : gradually move through below
1.
Running the automated tests locally and reporting the results to the team requires manual intervention and therefore will indeed be slower,
but the result reported to the team has already been triaged and can be trusted to be accurate.
2.
Running the tests multiple times a day in a CI job separate from development gives faster feedback, but the reported results have not been triaged.
So, the tests themselves have to be written with a greater level of proficiency and care to ensure they are not flaky and can be trusted.
4.Once you find that you can trust your tests yourself, move to a separate CI job that is visible to everyone but doesn’t affect developer check-ins. This strengthens your trust in what you’ve written and also allows others to begin to trust it as well.
3.
And running the tests as part of development’s CI process requires fast and reliable
tests that only fail with the application under test has provoked it to.
Creating a culture for test automation success
best approach for getting team buy-in for test automation : Communicate the goal, strategy, and opportunities for collaboration
product owner :the most probable way they can assist with test automation is by providing business insight on which scenarios should be automated
benefit of good test automation to product developers is that they are able to develop features with more confidence
test automation affect manual testers by assisting them