“Our QA is delaying deployment.” I am sure you’ve heard this before. If you did, then your organization is not testing in an agile way.

Development goes on the one hand, and QA, being the team that verifies, and provides approval, usually goes after the development. They are two separate teams and often developers don’t care what happens unless errors are found.

And vice versa, QA teams don’t care as much what is happening during the development, they just want to verify if everything is ok.

When we go agile, things must change. One of the main objectives of agility is to improve the quality of software, develop a product fast and based on customer feedback (going up to production in shorter cycles, ex. In 2 weeks sprints, every week, every time we make a change etc.), and to always be in line with end user requirements.

To respond quickly, we need a highly collaborative environment. Multidisciplinary teams, capable of producing increases and improvements in the software with the expected quality. In a team there are people of different types:

• A technical part (different profiles of development, systems, etc.).
• A business part (Product Owner).
• The testers are between the technical part and the business part. They help on the one hand the business part to translate what the client wants in tests, which will be what the software must comply with, which ultimately the developers have to implement.

An agile tester provides an intermediate vision between development and business: understands the point of view of the user, but at the same time, have high-level knowledge of the complexity involved in developing software.

The success of the team is to provide what the client wants and needs. And for that, we have to collaborate together and complete all the necessary activities to finish the desired functionality.

• If development ends up implementing something, but the Product Owner does not approve, the functionality is not really finished.
• The same, if QA does not give the ok to the task.
• If development expects feedback from QA and does not give it, it is not agility either.

 

Testers, development, Product Owner … They are a team with a common goal. If one part does not end, everyone’s work is not over.

That is why a user story does not only imply development activities, but also that testing and acceptance tests (QA, Product Owner) must be included in the definition of the end of said history.

 

“It’s QA’s fault for delaying the project” is not an agile thought.

If QA does not finish testing, or couldn’t finish in an allotted time, it reflects poorly on the whole team in general, just as it happens if development for some reason does not end on time.

Although this can occur for a multitude of reasons, it is true that the approach of testing in the agile world is a little different from the traditional one. Not only must we prove at the end of the process.

The objective of the testing is not only to detect failures but to the extent possible, prevent such failures.

Therefore, quality and testing begin in the early stages of development, at different levels (remember that there are different types of tests):

• Level closest to the user: Verify that the acceptance criteria of the user history are met (it can be manual testing, or we have practices like BDD or ATDD).
• Developer level: Unit tests to prevent there being no errors at the component, method, class developed level.
• On the other hand, we divide the work into small tasks, small increments of code, which are then integrated so that everything is simpler than leaving the integration for the end. You must check that integration does not break anything from the rest of the software.
• In addition, we should look for new cases. Do not just stay in simple checks, but at what points the platform could fail (using business knowledge and tester technician)
• And do not just do functional tests. If we need them, let’s execute system tests, load tests, etc.

Team members should consider each other’s work, work together and communicate.

In certain agile companies, we encourage the fact that when a developer has any questions, not only she/he should talk to the Product Owner, but a Product Owner and should be present in the conversation.

 

Agile testing should include automation testing.

It may seem that it is investing a lot in testing. That is unviable in time and resources. That you can not put a tester to verify all these things, that you do not have the personnel.

Yes, it is unfeasible to have a manual testing team run regression tests the entire platform each time code integration is done since this would be very slow and heavy. And certainly, we believe that in this we miss the qualities of the testers.

That’s where you get a balance between automation and manual tests.

Having a set of automation tests will allow us to launch certain verifications very often and with very fast results (for example, a battery of regression tests when the developer integrates its code in the version control, thanks to a platform of Continuous Integration).

But automating tests does not mean that manual testing is eliminated.

The tests that are usually automated could be considered verifications: a machine does not think. The errors that we can detect with these tests are errors that we have already detected before. Or they are what we call “happy paths”, the simplest routes in which an application could fail.

Therefore, a manual tester is essential. Automating these tests will make it easier for testers to work, in the sense that they can dedicate themselves to real, new testing that will add value in each iteration: testing of new functionalities, search for more difficult errors to find, testing new cases. In short, activities that require more of your experience.

Finally, automation tests also help developers.

Having a set of automation tests that run and give us a report that “Everything looks good “, gives us a bit more peace of mind. And this is essential to perform refactoring, improvement of code quality: to have something that guarantees us that the changes we have made have not modified the behavior of the code with respect to what was before.