In Agile Scrum methodology, the sprints are of very short duration like two to three weeks and such a short period of time where the development, code review, functional testing and performance testing completion of iterative software development sometimes finds very challenging to accommodate the test automation. In Agile methodology, QA need to work in sync with the developers within the defined time frame of the sprint. Therefore, the QA need to grasp the requirements of all the user stories which are the part of the current sprint and need to make a call or create the JIRA tasks for the test automation of the user stories deliverable.
To take on call on the user stories automation may not be very straightforward and sometimes requires the story grooming and consensus among the agile team member to automate or not to automate the user stories.
Which criteria to consider for Test Automation During Sprint?
Also, the QA may not get enough time to automate the user stories in a sprint as they have to focus on multiple things such as writing test cases, feature files, test scripts, validation of test results, etc. Given below is the criteria that the QA and the agile team should keep in mind to conclude what all user stories should be taken into consideration for the test automation.
Repeatability:
The functional test case is held eligible for automation if it is repeatable and the test case output should be consistent to rely on the outcome of the tests by the agile scrum team. In other words, we can automate the functional test associated with the user story where a test is going to be executed only once. In this case, the only exception could be if we are executing a test against a large data volume like testing the web link redirection script, etc.
Time:
If the execution of the manual tests is taking longer to create the scenario then in that case the automated tests can save us time. For example, if a particular manual test takes 30 minutes to execute and complete the test outcome then the same result can be obtained in 5 minutes when automated. Therefore, it is best to automate such test cases.
Reliability:
The automated test case should be reliable for the result obtained after executing it against the input set of data. It should be checking the verification’s correctly to determine actual output against the valid expected results. It means that the results should be determined easily irrespective of the environmental issues that can cause false positives in the test results making the automated test not reliable.
Safety Net:
It is very important that the automated tests act as a safety net for the agile team especially the developers. If there is any deviation from a working code due to the changes made to the code base, then it can be easily highlighted and reported to the agile scrum team.
Frequent need for the Regression Testing:
If a particular user story implementation is about the application module which needs to be regression tested as a part of integration testing then the automation tests for such modules are very important to assert the regression in case any upstream partner application has made changes.
We have defined the criteria that could help to filter the user stories in the current sprint that are held eligible for the automated test creation. Based on the eligible user stories for the automated tests, the new tasks should be created for automating the user stories and the story points should be given to these tasks that can buy-in some time for the QA to develop the test scripts for the automation of the user stories.
Further, the QA is advised to separate the layers in their test automation framework where the base layer should be the application framework code that communicates to the automation tool, such as Selenium WebDriver, etc. The page objects should be the next layer to model the application where the functions can be written to take full control over writing user scenarios. The last layer should be the layer for the scenarios where the reusable functions can be called from the page objects to completely test the scenario.
With the help of the above layered approach, the QA can expedite the automation of the user stories and commit to the automation test completed within the sprint with full confidence. Also, this should be noted that the automated regression tests require discipline during the sprint. If the scope of regression is increasing sprint by sprint, so as the maintenance effort. Also, keep this in mind that no one in the QA world can achieve the 100% test automation or automated regression. We should be automating only those tests that provide value for the business.
Conclusion
We should understand the current sprint requirements for the user stories and validate them against the functional test requirements to automate or not to automate. There could be scenarios where we can reuse the existing automation tests after making a slight modification to the underlying test scripts. The bottom line is that the agile practices are time-sensitive and therefore, we should be spending the calculated effort toward the best functional testing. The QA is expected to maintain the maturity of the regression environment to save the time to automate the user stories and deliver the test results with accuracy in a short period.