Another question from our recent webinar with @QA_nna regarding Test Automation in Agile, “Isn’t it also true that automation engineers and Scripters, even ones who are well versed in testing, are often constrained in how much they can test by the amount of time it takes to actually build the automation and meet the aggressive timelines often seen in most Agile teams, and thus limiting how deep such testing actually is possible at a given moment?”. We’ve examined your comment in several aspects.

  • True that there are always time constraints as in any project. But the time is especially constrained at the end of a sprint, where developers are checking in their code and QA is expected to wait until finally, ah… We can test now. For test automation in agile, the most important thing is to expand your view of automation outside the UI. Automating testing can encompass data preparation, data verification, environment preparation, test case generation and many other things. White box automation is also possible. By doing all these ‘other’ types of test automation earlier in the sprint, you’ll ensure better quality from the beginning and leave more time for the UI testing, which in many cases, is more suitable for manual testing.
  • Time to build the automation depends on the type of automation you are building. For instance data verification automation can be done earlier and independent of the sprint cycle. In addition, you don’t have to be totally in sync with that particular sprint. You can run your automation as a separate agile project, with its own sprints and code. What goes into the agile test automation backlog? Those features done in previous sprints and tested manually once/twice. In order to do automation effectively, you have to know how to manually test it anyway.
  • “Deep testing” is a subjective term in breadth and meaning. By doing other types of automation as expressed by Anna during the webinar, you can actually spend more time in testing new features manually, and often have time to do it deeply.
  • At any given moment, meaning at the end of a sprint is what we assume this means. Don’t save the testing to the end. Move testing upstream and expand the traditional meaning of ‘testing’ to include other activities including verification-understanding of requirements, writing test cases from requirements and sharing with developers, doing automation on older features (1-2 sprints earlier).

In general, to do Test Automation in Agile, you just need to shift your thinking to the left, and consider staggering your cycles. Consider automation a project in itself that you can run using agile methodologies. Think of a feature that needs to be tested with automation as an item in the backlog and prioritize. You don’t have to run totally in sync with the rest of the project.