You’re missing the point — QA, Testing and Agile

Terminology, and more specifically labels, are a real problem. The problem is that what they actually mean often becomes distorted over time. I recently read a whole thread on the word “decimate”;

• What it commonly means — kill, destroy, or remove a large proportion of.
• What it actually means — kill one in every ten of (a group of people, originally a mutinous Roman legion) as a punishment for the whole group.

Normally I would simply argue that is the evolution of a word, and to understand someone’s use of a word you need to see the context it is been used in. In the case of computing being able to understand the context can be difficult, or even impossible. For example, if you talk about “SOA” then depending upon the people involved, their contexts are flavoured by how they learnt the subject. The same is very true of QA, Testing and Agile.

What is QA, Testing & Agile?

I believe that simply fetching the definition of these terms, whilst useful, is no longer enough to discuss them unless you clarify the context. The problem is that a lot of conversations have occurred without this clarification and have stretched the meanings to breaking point.

Misinterpreting Agile

At the heart of Agile is the idea of collaboration. A number of methodologies, training, books, etc. have attempted to construct frameworks to help people ‘become Agile’. That is good, but it has caused a lot of confusion along the way. For example, in the Agile Manifesto it states, ‘Working software over comprehensive documentation’. It seems like an obvious statement, but over a period of time it has often managed to be read as, ‘Software and no documentation’. Similarly, ‘Individuals and interactions over processes and tools’ has become all about the process and tools and lost the collaboration. I am not a psychologist, but whilst I do not know why this happens, I certainly know it does. This means that many companies/individuals that consider themselves as ‘Agile’ are really missing the point. The problems are exaggerated as each misunderstanding has further knock-on effects. For example, consider a typical idea of an ‘Agile Sprint Team’.

Sprint Team

As an example consider a team that is implementing a feature for a web site application. The team requires some SQL Server database work, some Javascript work, some UX design and UI implementation. To help in the flow of the delivery it is a good idea to try to avoid the team switching to other work — sounds sensible. But then the bean-counting gets involved and it seems like there is too much slack in the process. For example, in a 2 week Sprint the database person has finished in 2 days, what are they going to do for the rest of the Sprint? Since, apparently, ‘The Rules’ say they should remain on this work this means they are now idle for 8 days. “This is madness”, rings out. Somehow the answer to this problem was to state that everyone in a team should be ‘multi-functional’. Okay, it is a solution but so is;

• Use specialist skills across Sprints
• Use ‘slack’ to deepen specialist skills
• Use ‘slack’ to refactor

I am not necessarily saying those are better solutions, but for some odd reason they are not considered — the seemingly only option is multi-functional. In my opinion this is not a great option. The ‘jack of all trades, master of none’ is a more appropriate description of multi-functional. When you ask a database expert to make changes to a React.js component or a Javascript expert to write the most efficient SQL query, are you really saving a lot of time and money in the long run? Are you improving the quality of the output? Maybe you are lucky and have a dream team…or is it more likely that you have confirmation bias? That is before we even get to what the UX and UI people are doing with your database.

‘Agile folks’ having apparently mastered this dangerous concept, allowed the idea to bleed into other aspects, namely QA and Testing.

QA vs. Testing

What is a name? Originally there was a skill set in software development known simply as ‘Testing’ — someone that tests the outcomes. It used to be the case that it was ‘developers vs. testers’ with a “them and us”, “throw it over the fence” confrontational culture. ‘Used to be’, who am I kidding, sadly I still see it a lot today. If you are ‘Agile’ then it certainly should NOT be like that. That is one big clue that you are not Agile. I digress slightly. Over time the idea emerged that testing was not just about evaluating the output, but that is was about ensuring the overall quality of the output was good. The problem was that our good friends over at ‘Misunderstanding Company’ struck again. Two misunderstandings have come into play.

1. Much like with the database specialists, rather than seeing testing as a specialist skill, they believed that having multi-functional developers meant that all developers can make good testers.
2. If everyone is responsible for QA, and testers are only responsible for QA, then ergo, everyone else can do the QA role. Thus there is no longer a need for testers.

“Testers only do QA”

This fundamental misunderstanding has horribly evolved from the failing to deal with the ‘too much slack’ issue by doubling-down on the multi-functional myth, and then not understanding the difference between QA & Testing. Now you have a Sprint where the members are not only ‘jack-of-all-trades’ but one of those trades you are hoping for them to be mediocre in, is the highly specialised skill of testing. Does this really sound like the most efficient way to produce quality output?

Where now?

When I am asked about what advice I would give regarding software development, it is to discover what the root issue is that needs be solved. The same is true when you look about how development should be done. The core idea of Agile is to foster collaboration between different members of the team who bring different skills to the table. If you find yourself contemplating getting rid of a whole set of people then really look at what that is solving. If you do not take that time to investigate the root issue, then it is quite likely you may miss the real point of what you are trying to achieve.