How to Design an Agile Friendly Automation Testing Framework
Agile is test first model, this defines how to kick start testing in parallel with the development. The main agenda of this blog is to relate the automation testing to this model. The discussion is mainly on how to develop the test pack model so that it best suites the agile velocity and with the sprint level expectations. We, as an automation testing company, create a concrete plan while bringing automation into Agile, conduct proper analysis then understands the feasible fashion of test script development.
Designing Automation Testing Framework Given the expectation that the testing has to go hand in hand with automation we must have a proper plan of developing scripts. Whether n-sprint approach or n-1 sprint approach to be followed? Let’s quickly look at how those sprints work.
n-sprint
In this model, we will have to consider all user stories that are listed must be automated.
n-1 sprint
In this model we likely trail by a sprint, whatever the stories those were developed in previous sprint are automated in current sprint. Despite the model, we should always make sure that the regression pack is kept up to the date in the same fashion we have to maintain the sanity pack too.
Types of Automation testing When in agile, we build the system in many iterations and we call them as sprints. It is obvious that we will have only smaller chunks built in linear fashion. The question here is – how do we accommodate the space for test automation when UI and the whole system is not available? Because when automation testing is said, 90% of the spectators talk about automating at UI layer as that has ROI which is better.
If we think automation testing is best deployed to test UI, not others we are missing greatly the ideology. What we are meaning to say here is that we should think of automating at different layers such as API & DB validations to ensure that the system is doing the right thing. If we can ensure that at the initial stage our job would be lot easier, also it helps the business greatly as we are uncovering the bugs early in lifecycle and which are not that expensive to fix.
For an illustration let’s consider that the development approach is a TDD one, we will not have the complete system to test, rather we will have smaller modules/micro services would be developed in an incremental fashion. To support the quick testing at that level we should consider designing a automation testing framework that can have tests based on module wise. We also need to understand what are the services offered by the component and accordingly write type of tests.
Write powerful integrated API tests in order to verify the micro service – micro service communication. Perform some data base table’s validation to see the business logic has been processed successfully and information stored at right table. We will apparently not have UI developed initially so as soon as that gets ready we should be ready in testing the flows that starts from UI.
Conclusion
Test Automation industry has taken a big leap from documenting the manually tested functionality as scripts for future execution to the purpose of serving the need for in sprint automation due to the agile parallel test execution expectation. With following the discussed practices and understanding the strategy of development and testing need, we can design a matching automation testing framework that serves the need of the hour. There is no standard or hard coded practice as such, rather it fully depends on the context of a specific project.
