How to Begin in Sprint Automation: A Tactical Guide
Test automation has undergone a steady evolution since its inception. While the process of writing test cases to test the software remains the same, the “how” part keeps changing. Sometimes, we like to perform simple and plain test script development as we did in the 90s using a spreadsheet. Sometimes, we record our test cases and run them through programming languages as we did in the 2010s using Selenium. Lately, we skip the test script part and choose codeless test automation tools to speed things up.
But even though test automation may be a straightforward process in theory, its alignment with the development process has not been so smooth. Since the inception of the Agile methodology in the SDLC, we have kept the maximum focus on the development (completing the tasks of sprint) rather than focusing on the whole system as we did earlier. As a result, the time we give to automation testing is very less and most of the time impractical.
The result: test automation lags behind dev sprint, and barely manages test things that have already been delivered.
This creates a number of problems and in this post, we try to list them down and highlight a new transforming method in the same domain. With in-sprint test automation, we focus on each phase of SDLC equally and try to wrap the automation of tests in the same sprint. This, however, is a systematic process and if you are someone just beginning your journey, this guide would suit your needs in every way. Let’s see what in-sprint is and how it benefits us in the current software development process.
Table Of Contents
Understanding In-Sprint Test Automation
From the early days of software development till today, it seems like a lot has changed in the software development life cycle methods. The waterfall method is now outdated and economically devastating in a lot of cases. The newer and most accepted method, Agile, particularly, continuous integration and delivery, transformed the way software is developed and availed to the end-users. Dividing our tasks into chunks and focussing on each of them in shorter periods of time (like 15 days) proved extremely efficient and eliminated analysis-paralysis and competitive disadvantage. These shorter periods are called sprints and generally, organizations set their next set of goals according to the sprint. Hence, sprint becomes a perfect parameter to develop, deliver and judge your own performance over a period of time.
But there is one small problem in the sprint-style development. It is completely development-oriented. It might seem logical and a correct choice to keep development as something that shapes our sprint culture, but over time each of the processes involved in the SDLC has changed, including the testing. It has become more complex and therefore requires its own focus, resources, and most importantly, time. This is where the problem arises. Agile does not give much time to the testing team to allow exhaustive, relevant, deterministic automation of the tests required to test the code that is created and delivered in each sprint.
QA processes are often called for at the final stages to test the newer code and version. This is also called a linear line of development in SDLC resembling a scenario like this:
When development and planning take much of the time in the sprint, we are not left with much choice but to consider QA to work one sprint behind. It works, definitely, but is neither ideal nor without its own risks. If you are releasing a product version based only on the previous test cases (also including regression tests), you might be allowing bugs to seep into the production. By the time you find out about the bug, the costs of rollbacks and debugging/hotfixing is 100 folds what it would have been had the bug been caught earlier in the SDLC.
In-sprint test automation fills the gap between development sprint and test automation by incorporating QA into the development process. With in-sprint test automation, the QA team is actually working on the same thing that is being worked upon by the development team (i.e. same sprint). When everyone is on the same page, the process becomes smoother and communication extremely efficient. Along with this main highlight, in-sprint test automation adds a series of benefits.
Benefits of In-Sprint Test Automation
Adopting in-sprint test automation is, we believe, the only true path to Agile software delivery. Here are some of its benefits:
Software with fewer bugs
There is no better thing for the team and the organization than to deliver software that has fewer bugs. In-sprint test automation keeps testers involved in the current development cycle. Therefore, when a bug is found, it can easily be communicated and rectified before pushing the code to production.
Smoother communication between teams
In-sprint test automation keeps the communication between the tester and developers contextual, relevant, and therefore smooth. Let’s say you are working with conventional designs and the testing is one sprint behind the development. The testing uncovers a bug. Now you have a query and request a developer to resolve it. However, since the version is already released and developers are working on current sprint tasks, they might not prioritize your query. They might think that the feature is already released so this can wait a bit. Here the communication gap between the teams can be felt.
In the in-sprint test automation, you all are working on a feature that will be released a few days later and is still in development. Therefore, everyone can prioritize the queries related to it, allowing for efficient delivery of quality software at every sprint.
Cost saver
In-sprint test automation saves the organization from the immense cost of releasing a product with bugs. As mentioned earlier, hotfixing a bug on production may cost as high as 100 times than it would have cost if it were caught before deployment. There is also brand reputation and end-user trust to think of. These costs, along with a developer’s hours can be saved when we work in an in-sprint mode.
So, with this brief introduction to in-sprint automation, let’s assess our next steps in transforming our current SDLC into something more suitable for QA and business.
How to Introduce In-sprint Test Automation in Your Current Processes?
You can incorporate in-sprint test automation in your current sprint cycles by following these steps:
Include QA in sprint meeting
A common mistake in many organizations that have not adopted the in-sprint test automation is excluding QAs from the sprint planning meeting. Their idea is to involve QA is at a stage when full functionalities have already been developed. When transitioning towards adopting the in-sprint test automation process, the first thing to change is inviting QAs to the sprint meeting where we plan the objectives. With these changes, we may expect the following things:
- Careful planning: QAs can help you plan things more carefully when in the sprint. Since QAs know how much time will a specific feature take to test completely, you can assess your tasks aligned for the current sprint more clearly.
- Ticket prioritization and classification: Since QAs can tell you the time it would take to test every ticket you put up in a sprint, they can provide insights on prioritizing these tickets to the most optimum stage. This way, we can be done with high-priority features first and test them by the end of the sprint.
- Quick test case creation: When QAs are included in the sprint, they already know what features are the team planning and how will they work. So, you do not need to give them time, later on, to provide this knowledge explicitly. Hence, test cases can be created very quickly in in-sprint test automation.
Ditch sequential test automation
Once you have started to involve the QA team in the sprint meetings, the next step is to adopt a testing method that can facilitate the in-sprint test automation. In the same aspect, these three methods are among the most popular choice for testing:
- TDD
Test-driven development, popularised as TDD, is an approach in the development-testing world where tests are created before the functionality. Initially, these test cases fail because the functionality is not yet completely developed. On the other hand, developers start writing code and testing again and again with the aim to pass all the tests. Once all the test cases pass, developers move on to the next functionality.
TDD ensures that the code developers are pushing ahead is bug-free.
- BDD
Another popular approach to TDD is BDD. Abbreviated for behavior-driven development, BDD aims at writing test cases that are understandable by all the business partners. Using Gherkin language popularly, BDD test cases look like follows:
GIVEN Abish is on the User Login page
WHEN he inputs all the fields
THEN a new user is created
The major advantage that BDD offers is its easy understanding to all the stakeholders. Online cloud-based test automation tool, Testsigma, offers a similar test case writing structure using the English language. You can check that out here.
- Shift-left testing
The final testing method we can incorporate is shift-left testing. This is newer than the two discussed above. Shift-left testing derives its name as we shift the testing process to the left side of the graph. In practice, we do not wait for the development to complete and start testing right away.
With this definition, it may seem that shift-left testing resembles in-sprint test automation. However, shift-left testing is a testing practice whereas in-sprint is a process of test automation. We can perform in-sprint test automation without shift-left testing and vice versa.
Sequential test automation is not a good choice in any organization, especially in the competitive, rapid-paced release frequencies of today. Maybe for small projects, it can still be alright, but bigger brands and projects work on deadlines, timelines, and efficiency. This can be achieved through one of the above said three practices while making a shift to in-sprint test automation.
Incorporate testing in DoD
The Definition of Done (DoD) is a term used to define what exactly we mean when we state that something has been completed. For example, if you are developing a feature about a wallet-based system for an application, does pushing the code to test mean it is completed? Or testing it would mean it is completed? Or running a CI/CD pipeline on it would mean it is completed?
The definition of “done” could be interpreted differently by different people and teams. This can create confusion when one team says they have completed a task while stakeholders do not agree. Therefore, it is advised to always settle on a common consensus here.
However, testing is often not constituted as part of DoD because of the same reasons we discussed above (as traditionally, testing is taken to be a process that happens AFTER the dev sprint is done). In-sprint test automation requires a slight modification in this part of DoD. If we start including test automation in the Definition of Done, we cannot push out a ticket as “completed” until testing is done on it. This way we ensure that the QA teams do not lag behind in the sprints.
Choose the perfect tool for you
Once we have incorporated the above-mentioned changes in the dev and testing teams and their processes, the next thing to decide upon is the tooling that enables the new changes in their workflows. There are a lot of things that are shaped by the tool you use. For example, if a tool uses a particular language, you might want to check whether your team knows that language. The frameworks too work differently by themselves and their knowledge of them could also play an important role. Choosing a tool based on popularity alone has long-lasting repercussions such as high maintenance costs and flaky tests.
In this matter, the tool choice remains a bit of a personal matter for the team. If 10 out of 10 people know Selenium, for example, then Selenium would be the de-facto choice for all (considering it satisfies the project requirements). To demonstrate a neutral and easy-going test automation tool that has a smooth learning curve, we will take up Testsigma, which offers all the test automation practices in a single place.
To start your testing on Testsigma, you need to sign up (free account) on the platform or use the Github repo to set up an instance on your workstation. Then choose the type of testing that you need to do, for example, data-driven testing or API testing, etc. The common thing among all of these is the use of the English language to create tests. In-sprint test automation means working fast as a testing team. Testsigma facilitates this process by introducing NLP (natural language processing) into the system that can not only understand the English language but also convert your actions into English-based test cases.
Along with this, Testsigma also comes with a self-healing technology that can heal the test cases according to the changes made to the UI components over time, which takes away 70% of your test maintenance efforts and prevents test flakiness. With this platform, it does not matter much about what you know in testing. For beginners to professionals, this tool serves as a perfect choice. It is easier, faster, cloud-based, provides real devices, and is feasible as compared to other such tools.
Start slow and simple
Once all our setup is done, we can start our way to testing the software. The first thing to remember is that you won’t be able to achieve everything in in-sprint test automation in a single sprint. A good practice is to start slow and take gradual steps ahead. You do not need to convert your existing testing practices to in-sprint all at once. The best practice here is to start with tests that are not complex and allocate some resources to your test automation backlog at the same time. With the simpler tests, people in the testing and development team can spend their time verifying the functionality rather than understanding what a test case means. As an effect, the teams can adjust more efficiently.
Then, in the next sprint, acquire some more percentage of your testing phase and again practice the same concepts until you are comfortable enough to push everything to in-sprint.
Do not let developers wait for feature completion
In the development part, the conventional method is to finish the feature completely first and then push it for testing. This is a normal notion because generally, the thinking is what will the testers test if the feature is not completed yet. However, in-sprint test automation may need some changes in this.
Consider one sprint where QA is involved and everything is done according to the in-sprint workings. In this sprint, the teams settle on only one feature because it is a complex and big task. If a sprint is around 15 days, this feature development might take 12 days alone. Then, would we be able to test the feature as we intend to do with high quality in just 3 days including pushing it to CI/CD for building it again for processes lines ahead?
In-sprint test automation asks the teams to work together where sometimes you might have a need to break the conventional cycles. Here, a perfect system can only be created if testers are not just sitting idle for twelve days but rather work on whatever has been developed. A partial functionality with proper documentation (only as initial drafts) is worth more than full functionality but no time which affects the quality of testing. So, complete functionality to a point it can be tested without refining it for production. Then, pass it to the testers who will then start testing it by writing test cases for full functionality. Obviously, a bunch of test cases will fail here but that’s a good thing.
Handover the same tests to the developers so that they can build and rebuild again and again until all test cases pass. This way, all your test cases are worked upon in a minimum time frame and you, as a tester, can again analyze the complete functionality.
Finally, be prepared
Following the above steps would mean you have successfully started your journey in the in-sprint test automation. But all the members of all the teams need to be aware that this is not a small transition. In-sprint test automation affects everyone because of the change in processes and sudden break in the conventional methods. Teams take their time to adjust, calibrate and adapt everything that is new.
When they start, you might notice that the transition to in-sprint test automation is not going to be a smooth ride at first. Give your members time and expect slow progress to achieve fruitful results later.
In-sprint test automation is a fairly new practice and a lot of organizations are moving towards adopting this practice. The inclusion of the testing team into the sprint right from the start has advantages that are hard to ignore. The results are satisfying and in-sprint holds a promising future in the complex and chaotic SDLC world.
In this post, we tried to chalk out the steps for people who are unaware of in-sprint test automation or those who know about it and thinking to transition their conventional testing practices to in-sprint. If this guide helps you or if you have already started to move towards in-sprint and would love to share your experiences with the community, do let us know in the comment section. We hope this guide helps you in transforming your testing practices. Thank you for your time.
