When Agile started to catch and organizations started to adopt it, it presented a utopian solution: self-organized groups that are 100% devoted to reaching the desired goal - software that the clients want.
Furthermore, and more related to testing, the Agile manifesto or its derivatives (SCRUM for example) don’t mention the word “tester”. It seems that testers are not wanted or are the black sheep of Agile. The Agile was designed for programmers, product owners, and scrum masters. Not for QA.
To remedy the testing missing part from the manifesto, the wonderful book (that I think any Testing Engineer should read), Agile Testing was published.
While there were many insightful ideas about testing in general and about testing in an Agile environment, I always got the feeling that the described scenarios were utopian ones. The team members are always eager to learn, the ego is left outside the room, there is a constant learning experience, the communication is perfect, everyone cares about quality and in general everyone is committed and has nothing on their minds other than a satisfied customer. And the tester? He becomes more technical because of his or her proximity to the programmers, and the programmers learn about testing. Perfect combination, right?
Agile doesn't consider the people who are contributing their parts and maybe are less willing to be 100% committed, people that need managing to motivate them, people that like X and not Y so they will take from the board only certain tasks, which will lead to tension in the team. Maybe shy people who will not speak up about pressing issues in front of the team. In other words, the human factor was opted out of the design. For this reason, unfortunately, the situation de facto, according to my experience and of others, is much closer to dystopia in regards to testing and quality.
Here are the failures of Agile in the testing perspective:
The testers isolation
This is one of the major issues. Usually, there is one test engineer in a team, perhaps two. They don’t have the basic option of consulting with peers.
Yes, they can go and talk to their peers who are located elsewhere, have a QA guild, etc. But I am interested here in the real world, and in the real world, a tester will not bother his peers when there is a problem or a question. Even if in the case of a big problem they will, in most - they will not. As one of the Agile ideas is sitting together to increase professionalism, this is deprived of the testers.
Lack of inputs
Related to isolation. Who is checking what the tester is testing? If the team cares, they can contribute a lot, but they are not professional testers.
Because of the lack of reviews and maybe training, and the lack of written tests, you don’t know what the tester has tested. You can ask her or him: “Did you test the login?” And they will reply by “Yes”. But they meant they did happy tests (correct credentials), while you expected them also to test the sad path (wrong credentials).
Yes, in a perfect world, there will be a review, but when the team (programmers) ask the QA they don’t always know what to ask or maybe sometimes they don’t ask because they think the tester will be offended.
When there are no managers, it is easy (and natural) for the testers to go to their comfort zone.
Leadership
In the Agile Testing book, each team member is a manager. Not in the sense of having people under their authority. This is only a part of what is a manager.
Being a manager is, if we count a few, the ability to make decisions, to know how to delegate authority, to help drive the team toward quality even if the situation is stressed.
For example, I worked for many years with outsourced testers. The relationship was great and they did a great job. Then Agile teams started to work with the outsource guy, led by the team’s tester. This was a disaster because the local testers, did not know about managing and were not trained didn’t coordinate expectations, didn’t monitor the work, etc.
Career
Maybe not related to the day-to-day tasks, but a programmer in an Agile world can change his/her position to be CTO for example. What is the next role of the tester?
Influenced by the team commitment
If the team is not strong, the tester is bound to be influenced by the team. She or he is not challenged, and the bugs they find aren’t treated well enough. In the “old” days, the QA team leader could try at least to change the situation.
System-level view
Each team sees its feature/s. Who sees the whole system from a tester POV?
Once, when you had one QA team they covered all grounds. Now, each tester knows his/her features well. But how this feature interacts with another - it is a completely different story.
Other things QA managers did and are missing in Agile
Professional evaluation, needed training, consulting the testers on professional and non-professional issues, being the tester's advocate if needed, focal point on version status. Who does that in an Agile environment? Let’s think about the vision (and this is true for programmers as well). While the team is busy with day-to-day activities - who thinks about improving the infrastructure? Embracing new technology? Changing the methodology?
Automation
It is expected that the tester will write automated tests. But, automation is coding and coding is a profession. You can’t write good automation code when it is 20% of your job.
The result - is bad code, hard to maintain, and in the end automation project failure.
Programmers were supposed to tests
But most programmers I met preferred to write new features.
Programmers don’t like maintenance or bug fixes. So in the end the tester is not doing his/her designed role, to help the team to test, but does all the tests.
To sum it up
So yes, there are some cases of Agile success in regard to quality. But I think in most cases everyone is doing Agile because thus the fashion dictates, and it is cheaper (no managers and managers development of the people).
But has the quality improved? I doubt it very much.
Comments
Post a Comment