Lisiane is a System Tester for almost two years who has been using agile methodologies to carry out her work. Today, she shares with us her professional perspective on this theme, which is increasingly discussed in the IT area.

“In fact, what are agile methodologies? Why are they used so significantly and how do they impact the software testing area? I will speak a little a bit about my experience as a software tester and try to answer these questions.

Agile methodologies – What are they?

Many of us, from the Information Technology area, already work with the so-called “Agile Methodologies” and especially those involved in software development life cycles. Agile methodologies, also known merely as “agile”, are directly linked to the way we develop software. Although the term is now broadly used, a simple motivation lies underneath its existence: to do what we do in the best possible way. Hence, the well-known Manifesto for Agile Software Development comprises the following four basic principles:

Individuals and interactions over processes and tools;

Working software over comprehensive documentation;

Customer collaboration over contract negotiation

Responding to change over following a plan

This does not mean that the remaining features are no longer important, however, the focus must be on emphasizing the efficiency of software production and, thus, interaction, functionality, collaboration and adaptability end up being more significant insofar as they streamline processes without losing quality.

The significant use of agile methodologies – why?

Even though the use of agile methodologies has become popular and steadily growing, we can perceive that in past decades movements have been made to find better techniques for software development. The major issue is that, in the current technological age of broad and wide-ranging communications, we have been valuing the efficiency and speed of software development with increasing intensity. We are living in the “click” era, that is, by clicking on a button, we can buy a product or contract a service. Consequently, this triggered the need for software to be developed as quickly as possible.

On the other hand, many companies still use the so-called “waterfall model”, which dictated the guidelines of the software development life cycle before agile methodologies became popular. In simple terms, we can imagine the development using a waterfall model as a ladder where we can only go up to the next step after climbing the previous step. Although it has several benefits, specifically due to its solidity and richness in the topics of specifications, this model ends up hindering the flow of processes, making it extremely difficult for those involved to deal with any type of unexpected event. Additionally, the time spent in the planning phase is extremely large as it requires a very detailed analysis, predicting each phase of the cycle. Comparing the current model with the old one, we can understand the reason for preferring agile methodologies.

How do agile methodologies impact software testing?

Agile methodologies have tools and principles useful to any area, from marketing to human resources, even including design. They adapt to the particularities of each sector and always allow innovating and improving the efficiency of processes. Therefore, it is natural that the software testing area would also be affected in many cases, especially considering its close relationship with the software development life cycle, thus not being uncommon to hear the term “agile tests” related precisely with this cycle. As it is a new way of acting in development processes, it is also natural that there are variations in the way of implementing the agile tests, which will vary according to the organization of sectors, projects and teams within a company.

In practice, how are agile tests?

Sharing a bit of my own experience, I can exemplify a type of implementation. To begin with, let’s imagine a traditional company, even if it adopts agile methodologies. Following the usual workflow, a meeting is held to define what will be developed, the requirements needed and how tasks will be fragmented. Programmers will develop their responsibilities separately and, in many cases, what has been developed is a barely noticeable fragment at code level. It will be only after the development of all tasks and with the final product ready for delivery, when testers will be able to start validating what has been developed. After testing, the product is delivered to the customer and the process is repeated with a new product.

Nevertheless, let’s suppose that the tester found a problem with the product: there was a button, which should exist, but it was neither specified nor developed. Within this flow, there is no more time to talk to the customer, nor to the analyst, to specify, develop and test again. Even in an agile methodology, the process ends up in a cast, due to the restrictions imposed and divisions created in the work of each of the parties involved. Truth be told, in most cases, this flow works well and problems like this can be easily solved with the customer, with the team’s commitment to deliver the functionality in the next product. Nevertheless, based on the principle that we can always improve and offer greater efficiency, imagine the implementation of agile tests in this process.

By comparison to the process described above, let’s imagine that instead of waiting for the final product to start the testing, the tester can simply verify immediately the task performed by the programmer, practically in real time. In this way, the programmer’s task will not receive the status of “completed” until it is also validated by the tester. Thus, once all tasks have been completed and the product is ready for delivery, a new test phase begins, in which the tasks have already been validated, leaving only a final integration test to be done.

Now, we go back and imagine the situation in which an important button for the product’s operation was not included in the development. By identifying the problem, the tester can quickly initiate a dialogue with the analyst and programmers, include the task in the development flow and, if necessary, realign priorities, solving the matter. In this form of work, the parties involved do not act individually, but together. The tester is always aware of the requirement details provided by the analyst, and the programmer, in turn, knows what has already been validated by the tester, and so, communication with the customer is transparent.

Hence, remembering the guiding principles of agile processes, there is emphasis on the interactions of the parties involved, we deliver a functional and quality product with the customer’s agreement and all this is provided with high adaptability to the unexpected events that are intrinsic to the software development process.

What can we conclude?

There are cases where the implementation of agile tests is very positive but, with my professional experience, I can easily identify some positive and negative aspects:

Negative:

– Usually, it is necessary to have a specific testing environment, which demands a specific time exclusively dedicated to the maintenance of this environment;

– It requires testers with a higher level of programming knowledge, since testing is often done at code level;

– It requires a high level of integration between analysts, programmers, testers and all other parties involved in the project, including the customer, and depending on the team/project dimension, this is not always easy to accomplish.

Positive:

– Being correctly implemented, an agile test usually adds quality to the delivered product;

– Information flows more transversely between the parties involved in the project, which reduces the number of mistakes due to lack of communication;

– The number of open bugs is drastically lower, as they are reported and solved still in the development phase;

– There is an increase of the testers’ technical knowledge as it is required access to the projects.

Considering all the above, we can see that in agile methodologies, or agile tests, there is no magic model that will solve all our problems. This is a fact! But, as we know, each project is unique and has its own characteristics and particularities. When we speak of agile methodologies, the most important is not following every step or principle “to the letter”, but seeking the continuous improvement of our work processes. Nothing so bad that it cannot be put into operation nor so well that it cannot be improved.”

Lisiane Engel

System Tester – PrimeIT