Why QA tasks should not be delegated?
Most IT teams require a huge number of roles that are sometimes impossible to cover with existing staff. And the first thing to do in such cases is to distribute tasks among the team members. Here we’ll try to think why the delegation of QA tasks is dangerous for your product.
Usual store
Let’s imagine that you are a PO of a new IT product in a company. Product is perspective, competitors are behind you but not so far and you are going to hire a team as soon as possible. You are thinking about all your previous projects, past experience and decide that you need three BE developers, two FE developers, a QA specialist (of course with knowledge of auto tests), a scrum master, a business analyst, and a UX/UI designer. Then after budget estimation, you understand that the project cannot afford so many team members and you need to decide who is actually required.
OK, code cannot write by itself, so developers are required. You decide to survive with 2 BE developers and 1 FE developer which has already been on vacation this year.
You can gather requirements, but let’s be honest, you have a lot of other things to do apart from creating tasks in Jira and maintaining documentation. So at least business analysts can take responsibility to help you with it.
You cannot start working without a prototype, so you need a UX/UI designer.
Everybody is highly motivated with new products, worked with scrum before and there is no need for a scrum master now.
You are already out of budget but who is going to be responsible for testing? After several discussions, you with your team come to a mutual agreement that business analysts can also cover test scenarios in the beginning. But as soon as the product will grow — we’ll hire a QA engineer.
Development has started, several months passes and everything works perfectly but stakeholders are waiting for more features. UX/UI designer works in advance, as usual, all prototypes and ready for development and you decide to hire more developers. Yes, everybody remembers that we planned to hire QA, but new features are coming, it is so exciting! Of course, you have some bugs, that they are not critical and already backlogged, so no worries.
The product is growing and stakeholders are happy. The technical backlog is bigger than expected, but most of the team members know how to resolve critical issues and restore the system.
Debt snowball
But let’s think about these minor bugs from the bottom of our backlog. What was the root cause of them? A code review was done. Business analyst checked functionality. Why did they appear?
Unfortunately, proper testing cannot be done in parallel with the main activities. The product owner and business analyst understand processes and can test functionality, but usually, bugs appear in “special” cases which sometimes are not described in the acceptance criteria.
QA specialists have this superpower to find bugs, usually in some special cases. Yes, it sounds obvious, but I’d like to highlight the long-term advantages of having QA in a team from the beginning.
One of the problems with bugs in the system is that they require attention. In the beginning, you do not have many issues, so it looks like the team can manage testing without QA. But the quality of testing is too low and when you have thousands of lines of code — it becomes more and more complicated to investigate which place should be fixed. Also, it’s easier to fix code that you wrote 1 day before than code written several months ago.
Focus time
Every developer knows how difficult it could be to switch from one task to another one. Some really complicated tasks require deep focus for more than 1–2 hours. So in an ideal world, a developer can focus on 1 task during the day and start a new one when the previous one was closed.
It takes some time to focus and the most productive time starts after 10–20 minutes of a task. So we can agree that an increase in focus speeds up the development process.
In the real world of course we have a lot of other deals, discussions, investigations, and urgent tasks and that’s why working days are not as ideal as we wish from a focus time perspective.
Still, this is not so bad, of course, our focus is decreasing by the end of the day, but code review and discussions are also part of our working time and we cannot avoid it.
But what happens when a developer is distracted by everyday small issues which were not fixed in the beginning?
- “Cron job failed again, could you please restart it?”
- “Oh, there is an internal server error, could you please check the logs?”
- “Report is loading more than 1 minute, please have a look”
Usually, most such small issues could be fixed in the beginning after proper testing. And sometimes they do not require deep analysis, because you already have this edge case happening in production. But developers have to switch from sprint tasks and implement hotfixes.
As a result, we have another picture of focus time.
Of course in reality more events are happening during the working day, but the main idea is that less focus on tasks means less quality and speed of development.
Long-term view
We need to fix these bugs as soon as they happen in production. But we also have regular features in progress and we cannot afford to lose the sprint. And every time team has to make a decision: fix an old bug just right now or finish the current task and plan to fix it in the next sprint? The team has a commitment before business to deliver features on time and one time it becomes a never-ending story.
Such bugs could be highlighted by QA in the beginning, but we did not have a responsible person, and speed of development was the priority. And that’s true, the absence of bugs highlighted by QA allows the team to close tickets faster. Look at the diagram below:
Developers are focused on tasks and usually, after code review they are closed, so they can start working on the next one. But with QA involvement cycle time will be increased due to found bugs and issues.
But after several months of work without proper QA testing, you will face more bugs and known issues and it will take more time on investigation.
After years of such an approach, sprint velocity will decrease dramatically:
It becomes more and more complicated to understand how many story points a team can take in a sprint. Sometimes it’s required to stop development and spend a full sprint on the technical backlog. And of course loss of focus time leads to new errors and a slow development process.
Final thought
Of course, there are a lot of different reasons why Quality Assurance is important from a business reputation perspective, but I want to highlight the strategic advantages of keeping QA in a team from the beginning. Sometimes it seems that some QA activities could be delegated to other team members, but it is not fully true. This is just a false representation of a well-distributed responsibility, and one day this time bomb will become a threat to the further development of the project.
