Quality Assurance
Testing never stops
Quality Assurance (QA) team members are the aspect of development teams that probably the least staffed. That said, I have seen teams crushed by QA and the addition of a single person would have saved the project and the company.
At every step of a system, testing is required. QA is a part of development, and anyone who tells you otherwise is either incompetent, inexperienced, or lying to you. Small systems don't always need a QA team member, but as soon as you get to a point where you are consistently improving the system, you need this team member.
What normally happens
This is the way it goes:
The primary stakeholder or stakeholders (the entrepreneur building or funding the system), hires a developer or development team to build the project.
If they didn't hire a team and just hired people, they just figure that their developers can test themselves. This is the first mistake.
As the system starts to form the team is focused on build, not testing, so no one is building tests.
The system launches, but is not yet breaking even.
As soon as the system launches users start uncovering bugs. But now the team is focused on delivering the next set of features, not fixing bugs. The system starts losing users due to bugs. It's acceptable at this point, but annoying.
The team realizes that the amount of time it is taking to test is GREATER than the amount of time it takes to build new features, so less and less testing gets done.
Now there are big issues in the system, and the team realizes that the have to start building automated tests and bring on a QA team member. But now, it is going to take months to build all these tests. They can't easily add new systems without testing, so they are stuck.
Users are getting frustrated with the speed of issues being resolved and new issues popping up every time the team makes changes, so the system churn goes up and revenue goes down.
Now things are getting bad and the team realizes how much money they're losing due to not having a QA team member and automated tests.
If they had just had that QA person to begin with, they would have been able to pay for them with just the losses from churn, but now they have an image problem as well as a development problem.
They start with a QA person, but it takes them months to get familiar with the system and tons of money has been lost.
What does a QA team member do?
They test and build tests.
"Of course" you're probably saying to yourself, anything else?
Actually, yes. In the beginning, when there isn't as much testing to do or tests to build, your QA team member can also double as a documentation or knowledge base builder. They are going to know every aspect of the system inside and out, so they can help the development team with documentation initially. The QA team member is also going to be a developer. Very often, they are a front-end developer who LOVES finding bugs and writing automated tests to keep them from happening.
Can't developers just test their own work?
No. They can't.
I would love to say that developers will check their work and catch all the issues they create, but having been a developer, designer, and project manager it just doesn't work that way. When you're 'in the zone,' you're so focused on the task at hand that simple issues can easily fly by you. It is just the way that most people are wired. Even great developers still miss simple issues.
However, this is often the difference between an experienced developer and a less experienced one. The experience whispers in the back of your mind "you always miss stuff, you NEED to go back and check everything." Greener developers haven't missed enough issues to realize they must check everything all the time.
I wish we could just plug developers into the Matrix and load the 'Issue Checking' program, but we're not there... yet.
Last updated