Test automation is a hot topic right now. And so is the idea of Agile. How do automated tests affect the Agile software development process? And how to make them visible? In this article I will try to indicate points in the Agile process where tests (including automated tests) should be taken into consideration, so that the entire Development Team can benefit from them, and the level of awareness about their importance is raised.

Estimates

Let’s imagine the following situation. A day like any other – the Development Team carries out an estimate of the task. And all of the sudden the developers say: “It’s a simple task. We will finish it quickly”. The room falls silent for a moment, and the people responsible for testing are starting to wonder if anyone has considered the impact of the abovementioned task on the design of automated tests. Maybe there will be a need to add a completely new functionality (e.g. authorization tokens or login process)? Maybe it will be necessary to make several adjustments? The role of the tester (or rather the developer, because Agile methodologies do not distinguish the names of team members) is to ensure that the tests, including automatic tests, are taken into consideration in the estimate. Effective communication is one of the principles of Agile methodologies. “It will take up a little of your time, but testers will spend much more time on it”. Therefore, the testers’ work should also be reflected in the estimate.

Such an approach during the estimate phase will have a positive effect on the work of the entire Development Team, because automated tests are also about the code. And just like the production code, it should also undergo the code review process. It may seem a waste of time “because these are just tests. But poor quality code is hard to maintain. Not without reason do 63% of experienced developers participating in HackerRank research consider “spaghetti code” as one of the most irritating pet peeves in a project. In addition, such code does not give definite results, and can also omit important business cases.

Read more: Test automation common myths

Automated tests, Definition of Ready and Definition of Done

Definition of Ready

Definition of Ready (DoR) defines the status of the task that the team recognizes as understandable and which it is able to carry out. The DoR should also specify whether the task is testable, and if so, in what way. This also applies to automated tests. The team should outline and comprehend all activities that must be performed to include the given task in the test design. Even at this stage we are able to determine which of the tests will be automated. It is worth bearing in mind that they will certainly affect the velocity of the Development Team. What does this mean? Let me explain. Velocity  measures how quickly the Development Team is able to meet the Product Owner’s requirements. It is worth taking this factor into consideration when determining the scope of work in a given Sprint.

For example, in the case of a task concerning updates of tools used in the system, automated tests will be limited to running them after making changes in order to perform regression, so as to confirm that the system is working properly.

The situation is different when it comes to a task concerning the implementation of a new functionality. In this case, development and code review tests must be included in the estimate.

Definition of Done

Definition of Done (DoD) defines the moment when we believe that the task carried out from the Sprint Backlog has been completed. Should it then contain information about automated tests related to a given task? There are different opinions on this subject.

Some people believe that it will slow down development, thereby reducing the team’s velocity. The concerns are related to a potential situation in which the developers would finish their tasks and then simply wait for the testers to complete testing, without doing anything active themselves. Others, in turn, claim that this will help to create better quality software, which will positively affect the awareness of the Development Team in the context of testing. Proponents of this approach emphasize that it will allow teams to indicate the impact of test adaptation to the complexity of the task, which should be taken into account during the estimate.

In my view, you need a well-coordinated and committed team with a high level of awareness of work in the Agile methodology to include automated tests in DoD. The lack of awareness in the team should not, however, be an argument against such a measure. On the contrary – it will be a challenge and it will have an additional positive impact on knowledge when it comes to the role of automated tests in the software delivery process.  

In one of the projects I worked on, the team decided to include automated tests in DoD as they wanted to confirm the system’s level of performance prior to presenting it to the client. Next, the developers asked for training so that, in the event of a heavy testing workload or their absence, the tests would not be neglected. This approach quickly proved to be fruitful. The tests prepared by the developers showed that changes to the code caused the system to malfunction in a completely different place than expected. And all of this before the code review of the solution itself!

Sprint Planning

Should tasks related to creating and maintaining automated tests affect the scope of the Sprint? In my opinion, we need to distinguish two areas here. The first of them is related to DoD, about which I wrote above. If tests have been included there, the Sprint range must reflect the team’s velocity, including automating testers.

The second area, in turn, concerns test-related tasks, i.e. those which are not directly related to tests, but have a significant impact on them. It is a good idea to ask yourself a few questions here. Do testers have a separate environment for running their tests? If so, does it have adequate infrastructure? Do testers have adequate knowledge and / or access? Perhaps, while searching for answers to these questions, we will realize that it is necessary to engage other team members (developers, DevOps), which will affect the Scope of the Sprint.

Sprint Review

How to present automated tests during the meeting summarizing the work done in a particular Sprint?

Good practices:

  • Certainly, what has been done and what area of functionality has been covered by tests should be briefly discussed. The extent to which it will unburden testers during manual regression testing is also important. This is the best way to present the impact of automated testing on collective work to the entire Development Team.
  • If you work on a given application with several teams, it is also worth mentioning the problems encountered and ways of solving them. Why? It may turn out that the problem has already been solved by someone else, or – on the other hand – maybe we have solved a problem that someone else is working on.
  • If necessary, it may be worth considering adequate reporting in the automated test design, for example by configuring a dedicated tool so that it is possible to present a ready-made report with statistics.

What to avoid:

  • Individual testing scenarios should not be presented and discussed. The Sprint Review is not the appropriate time for this, since their assessment should be done at the planning stage and subsequent code review.
  • Definitely do not offer the team something that can be called a “test seance.” Do you consider running automated tests and watching how the machine clicks on the application” together a great idea? You may be right – if you want the Sprint Review testing part to be tedious and treated by others as a necessary evil.

Summary

In the article I discussed the presence of automated tests in the Agile software development process and their influence on the work of the Development Team. It is worth remembering that automated tests are part of the testing service, but without an appropriate process and understanding how they function, they will not be effective. In Agile teams, automated testing facilitates the software delivery process for the entire Development Team. Therefore, testers (developers) take care of it and make them visible to others. The visibility of automated software tests at every stage of planning will certainly allow the entire team to have a better understanding and make more effective use of their potential in the future.

Author
Mariusz Skomra

No adventure in my professional life began with: "Hold my salad!", but a lot of began with: "Mariusz, I have a problem. Can you help?" Biotechnologist by education, automating tester by profession. Currently, he is developing his knowledge of Java in the context of automated testing of web applications and APIs. In a private life he is a photographer.

Dodaj komentarz

Comments:

CONTACT US!

Would you like to learn more about the possibilities of cooperation? Do you have a question? Write to us!

I hereby agree that JCommerce Sp. z o.o. shall process my personal data (hereinafter ‘personal data’), such as my name, surname, e-mail address, telephone number and company name, for commercial purposes.
I hereby agree that JCommerce Sp. z o.o. shall process my personal data (hereinafter ‘personal data’), such as my name, surname, e-mail address, telephone number and company name, for marketing purposes.
I hereby agree that JCommerce Sp. z o.o. shall process my personal data (hereinafter ‘personal data’), such as my name, surname, e-mail address, telephone number and company name, for recruitment purposes.
I hereby agree that JCommerce Sp. z o.o. shall process my personal data (hereinafter ‘personal data’), such as my name, surname, e-mail address, telephone number and company name, for future recruitment purposes.
I have been informed by JCommerce Sp. z o.o., 3 Ks. Piotra Sciegiennego St. 40-114 Katowice – the personal data controller – that: - The provision of the aforementioned personal data is voluntary but essential for commercial purposes if I have chosen a request for proposal, or recruitment purposes, if I have chosen the remaining options;
- I have the right to access the content of my data, including to receive copies of it and correct it, delete it and limit the processing of it, as well as the right to transfer it, the right to object to the processing of it, and the right to withdraw my consent at any time. However, the withdrawal of my consent shall not affect the lawfulness of processing carried out on the basis of the consent in question prior to its withdrawal;
- A statement of withdrawal of my consent to the processing of personal data should be submitted to the headquarters of JCommerce Sp. z o.o. or sent to the following e-mail address: zgody@jcommerce.pl. The withdrawal of consent to the processing of personal data shall result in the inability to fulfil the aforementioned processing purposes;
- The personal data provided shall be shared by JCommerce Sp. z o.o. with the company’s authorised employees and individuals collaborating with JC under civil-law contracts, who are involved in the implementation of the purpose of the processing;
- The data provided shall be processed on the basis of the relevant provisions of Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation), ‘GDPR’;
- Should you have any questions regarding the protection of your personal data, please contact us by e-mail: odo@jcommerce.pl;
- The personal data provided shall be processed for the purpose for which it was supplied, or until I express my objection in this regard. In the event of filing an objection, JCommerce Sp. z o.o. shall no longer process my personal data for the aforementioned purposes, unless it can demonstrate that there are valid and legally justified grounds overriding my interests, rights and freedoms or my data is necessary to establish, pursue or defend a claim, if any;
- I have the right to file a complaint to the supervisory authority if I consider that the processing of the aforementioned personal data violates the provisions of the General Data Protection Regulation of 27 April 2016.