How to build a QA Mindset from scratch - Chapter 4 - Automation Testing
Do you know that automation testing started at the moment that is planned and not only when you have tests automated?
Over the past few months, I've come across several intriguing articles discussing automation, with one particularly emphasized statement: "Automation is an absolute necessity; everything must be automated." However, this assertion is fundamentally flawed. Not all processes should be automated, prompting us to question the rationale behind automation in the first place.
The initial step involves elaborating on a checklist, and only if the majority of criteria are affirmative, should you proceed to the next stage:
Are you familiar with the products/services you work with?
Do you plan to implement or anticipate the use of unit or component tests to validate configurations at an early stage?
Have you documented manual regression tests?
How frequently do you release to production? If not, have you established robust regression tests to validate core features that must remain functional despite code changes?
Do you require additional time for exploratory testing?
If you answer yes to three of these questions, it indicates readiness to begin considering and implementing an automation roadmap plan for your team.
When incorporating automation tests into the test strategy, the main consideration should be the stability of the product. This entails assessing the frequency of changes to core features in production. Additionally, it's crucial to evaluate the robustness and stability of the existing regression suite. Once these factors are established, a plan can be devised to automate using the regression suite as a foundation.
If it's the inaugural venture within the organization, initiating a Proof of Concept (POC) is imperative.
How?
This required allocating dedicated time, which should be mutually agreed upon with your team, for instance, reserving a set number of hours per week for the POC, such as 5 hours.
Document any discoveries or insights using a test management tool like Confluence.
Familiarize yourself with the product; if APIs are used, research suitable automation test frameworks tailored for API testing. Similarly, for web and mobile applications, identify tools capable of accommodating both platforms.
Prepare for initial challenges and setbacks.
Seek assistance from developers and tap into the test community resources, such as the Ministry of Testing, for additional support and guidance.
Upon achieving milestones, disseminate the POC outcomes to your team and potentially to all engineering teams.
If you already have a test framework chosen then you can define a plan for the automation.
An example of an Automation Plan that I used in every company that I’ve worked for starts with:
Scope
Product/service
Test framework
Why automation for testing?
highlight the need for automation
Automated testing is the process of conducting a set of tests that run on their own. Unlike manual tests, reliant on the workforce, automated ones depend on tools for management and reporting.
How to create an automated Testing Strategy
Test environment.
Testing tools.
Testing approach.
Test Automation Strategy
The scope of automation testing is to increase test coverage and allow the creation of scripts for repetitive test scenarios and there are no significant changes from the development side.
products and regression tests - jira tickets to be created to track your work
Test Automation Approach
Process
Technology
Roles
Automation Lead: Responsible for coordinating and managing all activities regarding automation in the project.
Test Case Designer: these are the testers that created the test scripts for automation.
Test Case Reviewer: Similar to code reviews among developers, it’s important to establish a review process for automated test cases.
Risk analysis
Test Automation Environment
Execution
Release Test Cases
Failure analysis
Review and feedback
It will be a potential gain to the team and all organization, is quicker to show the results, and is possible once we have the regression test suite fully automated, to use some of the scenarios as smoke Tests or all of them, depending on the time to be executed, to show immediately results from each code change.
Once you have stable automated regression tests, such as end-to-end testing, use it for the daily pipeline executions and check the results first thing in the morning. You can also start or continue to evolve to automate component tests, using a regression suite, that executes locally and validates any code changes before it’s merged to the main environment, such as the TEST environment, depending on it is the environment that you use for testing.