Before jumping into Automation it is best to decide what kind of Automation is best fit for the Product and the Team.
A process I have used to access and determine automation is:
- Pull together a team of core engineers, the quality lead/manager, and the development lead/Manager to outline the Automation Strategy.
- Ensure that Automation is NOT assumed to only be a 'quality' activity
- Use the test pyramid as the foundation of the automation strategy (https://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid).
Notes: I have modified the pyramid by
- Separating unit tests into 2 categories, backend and frontend
- Included Integration tests after Unit tests
- Gave coverage percentages to each level where the highest percentage is on Unit tests and lowest percentage on UI.
Initial conversations should be centered on ensuring what Unit and Integration Tests will be built. For example, frontend unit tests (via mocha, chai, etc) can be more efficient and less expensive for web application frontend testing vs Selenium.
From there, it can be determined what additional frameworks are needed.
It is best practice to do as much automation in the same development frameworks (nunit, etc) as possible so that way automation can be built into the SDLC and contributed to by the dev team, this is key! If automation is not built into the SDLC, including sprint & release work, it will always fall behind and not be valuable.
Also, use the same build framework (Jenkins, Bamboo, etc) to deploy and run the tests this will make the automation tests more streamlined and enables reporting to be built into the deploys/runs.
