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.
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’.
- Use specialist skills across Sprints
- Use ‘slack’ to deepen specialist skills
- Use ‘slack’ to refactor
‘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.
- 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.
- 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.
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?
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.