In today’s world, where things keep on changing on daily basis and we sometimes find it hard to adjust with the changing needs and scenarios, automation does play an important role for continuous delivery. QA being the gatekeepers, are not only limited to perform manual testing but also play an important role in designing frameworks and implementing test scenarios programmatically.
Like our needs, automation has also evolved tremendously over the years, giving us a variety of tools and methods to enhance quality. We started from record and play tools, evolving to various Custom Frameworks, thereby making our tests more qualitative and robust.
However the question remains, should we consider automation as a tool to enhance testing practices or should we treat it as a strong testing process as a whole. I have shared some of my viewpoints in this blog.
In a complex project with a lot of UI and backend scenarios, and tests within stipulated time frame, automation does come handy. However there could be projects which are small and time framed, where automation seems distant.
In a typical project, Test Driver Development or TDD is used by developers to build a test infrastructure to unit test their code. Also, testing frameworks are designed and implemented by QAs to verify various scenarios. This goes well for a small design, however it becomes difficult as the application becomes complex, which results in duplication of test scenarios covered by developers and QAs, and also may result in loss in coverage of necessary scenarios. To overcome these situations, a robust testing framework should be created, where-in every intermittent and release build can be tested within a limited amount of time, for stability and regression.
Considering an Agile Project which has many components involved and multiple builds are shared on daily basis as per planned items in iterations. To utilize time and being efficient, a robust automation suite can definitely provide a sense of stability and confidence to both - the developer and the QA, thereby ensuring that minimal manual effort is required for regression testing.
The truth lies in the questions - when to automate, what to automate, and how to automate
What is critical to be done!
- As per your business needs, definitely automate the regression tests. This would reduce the manual effort spent on every build.
- To limit defects, the test code should be of production quality. This can be achieved by a robust testing automation framework.
- Avoid doing automation in one go. We definitely need to automate, however it would be wiser to automate one use case at a time. This would strengthen the framework and confidence. We do not want to automate the first four steps of a test case and then move on to next one!
- Do not repeat the tests. Developers and QA need to sit together and decide what is to be covered in TDD and which, in test frameworks.
- Try to automate all of scenarios slowly as it is definitely fun to reduce the pain of running the same tests again and again.
- A team must own the test code and should be responsible for it.
- Maintain the test scripts and treat it as important as a test case sheet.
- We can enhance our regression suites by adding common customer reported issue patterns and ensure they are not leaked again.
- Maintain the automation and product versioning in order to run automation scripts across versions and platforms.