An Agile Team who doesn’t care about Quality isn’t Agile at all.
Why do we test?
We tend to think testing is all about quality but tests are way more about designing your code then prove if it’s working. They are guides that help the developer knows if he is doing the right thing in the right way. They also help the developer to properly define responsibilities and have a quick feedback about the produced software.
It’s team’s problem!
The quality of a produced software is a team responsibility, not a QA or Tester.
“So, what does a QA do on an Agile Team?”
The QA role on an Agile Team is to know which test use in each situation and how to do this tests. Everyone on an Agile team should be ready to do a testing task, the QA role is to help when necessary.
Agile Testing Quadrants
This tests quadrants help us to know which tests use and how they face our software.
Technology-Facing x Business-Facing
While the business-facing tests verify how the data is presented and validate whether the software meets the acceptance criteria proposed by the customer, the technology-facing tests verify that the data has been calculated correctly and validate the software’s operation trying to detect possible execution errors.
Supporting the Team x Critique Product
Tests that support the team are those tests that allow the team to feel confidence in the product delivered. Thanks to these tests, it is possible to know if the software produced is meeting the criteria proposed by the client and allow the developer to know if his code is working as expected.
On the other hand, the tests that criticize the product try to take it to extreme cases, in order to detect bugs that normally would not be perceived. This prevents the software from failing on aspects such as load and security.
Testing before developing
Sometimes, immersed in a problem while developing a software, we may end up losing sight of the whole and fail to develop part of the scope of the software.
Writing the appropriate tests before developing can prevent this from happening. It seems complex to think about testing before developing, right? However, it is much less difficult than it seems!
There are several methods to test before you develop. In BDD, for example, you can write tests for the features before you start developing. Functional examples can also be useful where a BDD does not fit. Here’s how a feature test can make the difference:
A team needed to develop a software that would alert the support team when an order was too much time without a definitive status, because this could indicate a problem related to order processing. The requested software would allow the support to view the orders and recreate them if necessary.
However, the team was exploring a totally uncertain territory and they did not know exactly which tools to use in the alert’s development. Because of it, they spent so much time researching and developing the ‘alert part’, and they completely forgot that this alert would not always indicate that the order was really in trouble, which, for example, could simply be a slow processing and the order should not be recreated. At the time of delivery, the alert had only one link allowing the re-creation of the orders.
This error was only noticed at the time of the client’s review. And, with all his reason, the customer disapproved the review and justified: “The support team can not re-create a order without seeing its data. We need to decide whether or not it is necessary to recreate it.”
That problem could easily be avoided by writing an example:
In the event that one or more orders remain for more than 10 minutes with a non-definitive status, I would like to receive an alert that would allow me to verify their information and have the option to re-create the ones I deem necessary.
E2E, when to use it
End-to-end testing simulates user behavior, so it’s the closest test of reality we can do. However, they are expensive to develop, maintain and execute. In addition, they do not provide accurate feedback on where the error lies. For these reasons, they should be used in cases where it is not possible to test at lower levels such as Integration or Unit.
Unit Testing
Unit tests test the smallest possible unit of your code. For this, they often use data mocks or other features. They are easy to maintain, inexpensive to run and have accurate feedback. When failures occur, it is possible to identify precisely where the error is. Unit testing gives developers more confidence in the code they produce.
TDD
TDD is the practice of writing the unit test before your code. I don’t think anyone sees TDD as a bad idea but still few people use it.
I really like testing, but even to me, writing tests after the code is already done is a pain in the ass. I have that feeling I could be doing something else but I’m right there writing tests to something I know works.
It generates a serious problem of “tests by formality” or “tests that test nothing”, in addition to greatly increase the time spent to do the tests, because a code that was not made to be tested will be refactored several times to become “testable”.
TDD helps the developer to design the code. As the test is written before, the code is already written testable and there’s no time spent on refactoring. Besides that, the responsibilities will be well defined since the developer have to plan it all before writing the code avoiding complex methods with lots of responsibilities.
Consequences of Testing in a wrong way
The consequences of wrong testing are formality tests. In fact, they test almost nothing and only aim to reach the coverage of the code. Testing this way causes excess bugs and the team to spend a lot of time correcting them.
So the only correct way to test is TDD?
Certainly not. But it was the only effective solution I have found so far.
Worse than testing on the wrong way is not testing at all. Sometimes, testing on the wrong way makes the team feel it’s wasted time since they don’t fully get the benefits of testing and spend more time than usual to write the tests.
That feeling of being wasting time writing tests is false because even the team is spending more time to finish the product, they will spend less time to solve bugs and will have fewer bugs as well.
So, why do we test?
We test to ensure we don’t lose the big picture, allowing us to meet the client acceptance criteria majesty with fewer bugs and greater quality. Also, allowing the code to be maintained and assuring when a change is made it won’t screw the entire product.
