Is In Sprint Automation Testing Possible To Complete?
The short answer to this question is – yes, it is. The hard part is to find out how to complete in sprint automation testing.
The general problem with test automation is that people usually wait until the entire development is complete before starting automation. Or at least, when the feature is stable enough. There is nothing wrong with being careful, but this also means that you as an automation engineer will start testing when the sprint is already over. At this moment, it wouldn’t be uncommon to have the entire feature already shipped to the client. Why is this a problem? Well, imagine that in the next sprint your team introduces a regression issue for this same feature. You don’t have a test that would be able to catch it. This regression issue could be sent to the production and only then the client would inform the development team about it. Is it necessary to explain why this would be bad? The following strategy can be implemented as part of Shift Left approach.
Preparation for automation
The first thing we need to do is to familiarize with the feature we will be testing. We need to ask a ton of questions to all the parties involved in the process. When we get all the answers we can then decide what to automate. Working with developers on automation strategy is quite important. You don’t want to create duplicate tests. And most certainly you should opt out for the solution that provides the fastest feedback to you. Once we know what to automate, we should think about how to perform the automation. What tools should we use? All of these activities must be completed prior to the start of development. There is no time to waste and this planning is definitely something you should not leave for later.
Getting familiar with the design
Since we are talking about UI test automation, people would think that you need a complete UI before you start working on it. This actually is not quite right. What we need is a mockup of the design of this page just to understand what elements would be displayed there. When we know what would be the layout of the page, we know what to expect and what would be the elements we will work with in automation. This model is still possible even without the mockup. The developer needs to closely communicate with the automation engineer about which elements they will add to the page. The automation engineer must be informed immediately in case of changes in the design of the page. In this way we are able to rewrite our tests as soon as the change happens.
Writing the test
The test writing starts with checking the test cases. Before this step, at some point we should have written the test cases. If we use page object model, we can write the page class with almost all the logic for finding the elements. We know from mockup what element we need to find and we know what we could do with that element. The automation engineer just needs to write the logic for finding the element without inputting the locator. Then we can add the functions for manipulating the element, e.g. enter the value in a field or select an option from the list. Now we can start with writing the tests. We will write the tests based on our test cases. We have to wait for the completion of the entire development and add locator details in the page class before the automation engineer can execute the tests.
What if there is a change in the business logic?
Well, the answer to this question is quite easy. If there is a change in business logic which the project manager or product owner share with developers but they withhold it from QA engineer then there is something wrong in how this team works. QA engineer is an equal part of the development team. He needs to be informed about any business logic or design changes. Working with uncertainty is part of development and while the developers handle it on their side the job of QA engineer is to handle it on the test side simultaneously. Not doing so can severely affect the software quality and delay delivery of the project.
Final words
This process works in practice, although it may not be the template for all projects. You must adopt the changes to the process if you want to use it successfully in your organization. In any case, it can help you to complete in sprint automation testing or at least to give you an idea how to do it. In this way, these tests can cover regression issues for the features pushed to production environments in future sprints. We must do the development and tests simultaneously.
