Art of Automation Testing
Akhil Jain
Follow me for SDET Learnings, Posts, Jobs, Bootcamps, Videos, Concepts | SDET Lead | PodTest | GeeksForGeeks |TestTribe |Teacher | Course Instructor| YouTuber| Taught 2000+ Students till date | 5k+LinkedIn |2k+YT | 1*AWS
Every Automation done requires Approach, strategy & Design which matches best to the infrastructure around the Software being automated.
With this Article, my focus is to give a new perspective to the Approach taken for automation.
Existing Approach:
There is already a very streamlined approach taken by almost everyone i.e.
You have access to the software via web browser, where the software is hosted on cloud/remote servers etc.., In this case, Do's & Don'ts are:
Do's :
- The Application needs to be available.
- Access it via browser & give the URL to our automation framework.
- Simple & Easy.
Don'ts :
- No technical know how required to run Application
- No need to build the Application, as it is already built & hosted by dev team.
- Automation team doesn't need to know the dev code & location of the repository.
New Approach :
Here we will create a local copy of application; similar to what Dev team does.
So Do's & Don'ts are:
Do's :
- Take the Backend & Frontend application code from repository & build the code locally on your own machine.
- Technical know-how may be required to build the code & run it.
- You access this application to automate stuff & not the one hosted on QA Environment.
- This also helps in managing test data, as it is locally hosted, data can be erased , added, updated as per the need, no interdependence with other colleague's work.
Don'ts :
- You don't need to be dependent on QA Environment availability.
Advantage's:
- No dependency with anyone.
- Fetch the latest code from repository & build the application & run it locally
- Test Data management becomes easier.
- It enhances your technical knowledge around the application & also gives you a chance to better understand the architecture of your Application.
- It can be integrated with CI/CD very easily, you can maintain separate repository or same repository to achieve it.
- It is more time saving once implemented
NOTE:
This approach may require good know-how around the tech-stack of the application, also it may work only for some specific applications depending on their architecture.
Also, it requires efforts & understanding from Dev team to help Automation team take this approach & scale this to cover CI/CD integration.
I am fortunate to work on such a approach & deliver Automation coverage.
Quality is everyone's Responsibility. :)
Just one question how are you keeping the code in sync with latest dev builds. And what is the frequency of new commits, because this becomes much more challenging if you are getting one or more builds in same day. Keeping that latency to minimum we can have common environment for dev and qa.