In my experience, most of the QA teams won’t attempt to create automation scripts for the features within the same sprint in which they build/develop, and these two activities (creating the feature and automating them) together can easily expand beyond the sprint life cycle.

First of all, we need to understand why we need in-sprint automation. This will introduce risk as well as technical debt. Any functional testing done within the life cycle of the sprint usually focuses on the feature story itself and not on complete regression of other parts of the product. The automation task for the current sprint features goes to the backlog or for future sprints.

And, thanks to in-sprint automation, we can easily end all of the preceding points. The benefits are:

⁃ Most of the time, the development processes get delayed due to the time the QA team needs for testing. A feature needs to be tested along with others to ensure seamless integration. With the help of In-Sprint automation, we can save time and ensure there are no leftovers or backlogs for the current sprint.

⁃ With Insprint automation, we can ensure the business can achieve their development goals in the first build and the ongoing adjustments will require less time since there are no repeat processes involved.

⁃ We can reduce the chances of errors if we identify the test scenarios in the early stage of the sprint.

There are some creative ways to achieve test automation within the same sprint, especially when it seems like a big task to achieve it within the same sprint or short window of time. Here we will discuss how the development team can close the sprint with the test automation in place.

1. COLLABORATE WITH OTHER PLAYERS:

In my opinion, the automation engineer should consult with all verticals (business, QA, and developers) to determine what can be automated and what an automation engineer requires for scripting the feature.

THE BUSINESS

The main reason for collaborating with the product owner is to limit what can be automated. If you are looking to automate everything within the sprint, then you can not automate everything. The product team can provide insight into the feature and its use criteria, as well as prior usage data that may reveal useful patterns, and the automation team can ensure that they are automating the right thing.

THE TESTER

By collaborating with the functional tester, you get to know about all aspects of the feature being delivered. And the tester will help you come up with business-critical integration scenarios that are important for automating the feature.

THE DEVELOPMENT TEAM

Early collaboration with the development team provides a wonderful opportunity to understand what the automation team needs to automate a feature, such as code seams, API’s, and the UI element identifiers.

To achieve in-sprint automation, we need to understand Mike Cohn’s test automation pyramid, which helps us formulate an effective in-sprint test automation strategy. At the base of the pyramid are the “Unit Tests.” Unit tests are the fastest to execute and the least expensive to create. Next are the “API tests,” which test services separately from their user interface. “UI tests” sit at the top of the test automation pyramid. As we move up the pyramid, the costs of creating and maintaining tests, as well as their execution time, fragility, and coverage, all rise.

image_pyramid

Automating Unit Tests

First, let’s consider the unit test. Unit tests are tiny pieces of code (generally a function or method) that developers write, execute, and maintain. The practice of unit testing mainly prevents regression defects and gives software developers a sense of confidence in changing the code without breaking things. A developer can write unit tests relatively quickly and give fast feedback on code quality. As we can see in the pyramid above, unit tests should constitute most of your automated tests. In the traditional development process, unit tests are not written until later, leading to low coverage and technical debt. The problem with this approach is that we won’t find errors until the functionality is fully completed, and that is already too late. In my experience, I have seen many teams estimate the time required to develop a feature and do not account for unit testing during the planning of a sprint.

Automating API Test

Higher on the test automation pyramid is API testing, which is more suitable for test automation than UI testing. Since APIs (the “transaction layer”) are considered the most stable interface to the system under test, API tests are less brittle and easier to maintain than UI tests. In API automation, we can validate the core logic of the feature without being dependent upon the UI. And the API tests are easy to automate within the same sprint. With the help of API automation, we can start testing your application in the early phase of the development cycle even without a user interface. This allows us to identify and fix issues early in the deployment cycle, which would otherwise be costly if they were discovered during UI testing. API tests are much faster to execute and are thus suitable for checking whether each new build impacts the existing user experience.

Automating UI Tests

UI tests are the highest in the pyramid, and they are the most difficult to automate. UI test automation usually spills-over or takes subsequent sprints because the automation engineer may wait till the UI design and development is finalised. Automating the UI test cases within the sprint may be challenging, but we can do it without worrying about the other aspects if it is prioritised first. Let’s understand it with an example: Assume that you need to test “Registration screen” in the sprint and development hasn’t been completed yet, but you have the designs (wireframes). If you have a relatively stable design, you can start automating the UI tests without waiting for the completion of development. How can we achieve this? To discuss with the developer all the locators/identifiers you want to automate and plan to use for the fields like the first name, last name, email, password, and the buttons submit, cancel, or any attributes of the screen during the sprint planning At the very beginning of the sprint, UI automation can be handled smartly by coming up with a contract with the developer for mapping the locators. This way, the automation engineer can start automating the feature without being blocked by the developer to complete the feature. And it helps to develop tests in parallel to development, enabling the automation engineer to ship the release faster.

2. AUTOMATE STRATEGICALLY

Let’s assume the feature being developed is related to the UI, then it is natural to want to automate this feature at the UI layer to ensure if the UI behaviour is as expected or not. However, an automation test scenario contains much more checks than actual verification. That includes setup, navigation, and clean-up, all of which need to be automated. To increase the speed of automation development time, we can take a hybrid approach to automation testing. Like determining if any of your test scenarios can be pushed down to the unit or service layer of the test automation pyramid. And we can use APIs and code seams to take shortcuts within the application to shorten the test steps. For example, you need to automate a scenario where you need to add a product to a shopping cart. For that, you need to have some prerequisite steps before you’re ready to test:

  1. Go to the home page using the URL.
  2. Find the product.
  3. Click on the item.
  4. Click the ‘Add to Cart’ button.
  5. Select the cart icon.
  6. Click the “Remove” button for the product.
  7. Check the cart.

Automating steps 1 to 6 by navigating the UI is unnecessary. We can achieve this by adding a product to the cart using an API and launching the cart page after adding the product, so your test doesn’t need the step 1 to 6.

Now the automation scenario can be shortened:

  1. Call the API to add the product to the shopping cart.
  2. Open the cart page.
  3. Click the ‘Remove’ button to remove the product from the cart.
  4. Check the cart.

Taking the second approach is a lot faster than the first approach. The less code you need to write, the more likely you will be able to complete the automation within the given sprint.

3. BUILD INCREMENTALLY

Whenever a new UI page gets delivered, we, as automation engineers, may be tempted to build out an automation framework for all the elements of that page. Avoid automating each and every element of that page. It will take more time to automate the whole page than you have. Only focus on the tests that you need to automate. A test-driven development (TDD) approach can help you to switch between the tester and developer mindsets, while coding these scenarios. I would recommend writing out all the test scenarios first, calling out the methods and functions that you need to create further in your automation framework. This is something which always helps you to identify all the methods and functions needed to execute the tests, and you can focus on building only that and nothing more. While building the tests that you need, just keep in mind that you cannot skip automation of tests for the features that are not ready for testing yet. If a sprint allows for only part of a feature to be built but that feature is not yet testable, do not skip creating the necessary pieces of the code for the features that have already been deployed. For example, let’s say in the first sprint, the task is to create the UI for the editable profile below, but the “Create Profile” button does not do anything yet.

image_profile

Technically, this page is not yet able to be tested. But in the next sprint, the “Create Profile” button to save the data will be delivered. Well, by then, there will be at least two pages involved: the “Edit Profile” and the “View Profile” screens. If you wait to automate until the feature is done in its entirety, that’s quite a bit of automation code you’ll need to write when the full feature is delivered. Instead, you can still consider which tests you’ll want to cover; use the TDD approach to write those tests and to develop the necessary framework in the sprint in which they’re delivered; and add the assertions when the full feature is complete.

A better definition of ‘Done’

What is the definition of ‘DONE”? It is a set of criteria where a software development team must agree and complete before a feature is considered as completed. By utilising the above technique, we can confidently say that the scenarios are automated, and you can add them to your definition of done. And be careful; do not try to quantify the percentage of scenarios that should be automated. And again, focus on automating only the scenarios that are needed to give everyone involved the confidence of truly completing the feature.