For many companies, the price tag that comes with investing in enterprise software can be significant. And as a result, many internal implementation teams feel the pressure to cut services to ensure that the initial price is as low as possible so the team can more easily maximize the ROI. More often than not the area that organizations want to cut is Quality Assurance. This is problematic. While this may be a short-term solution, it can be a haphazard approach to development that leads to costly problems down the road. Let’s explore a few of the fallacies about QA we come across most often.
“Microsoft and Google don’t use a QA team so why should I?”
While it might appear on the outside that they don’t have Quality Assurance teams, in reality, they just changed how their teams were structured. They found their QA to be so critical that they embedded their quality process directly into their development teams. Instead of treating testing as an outside department, they were folded in to be more effective.
“If they were good developers then they wouldn’t need QA help.”
Or said another way, the need for QA means that you don’t have good developers. This seems like a fair assumption, so we talked to Lauren Cousin, VP of Quality Engineering at Hoodoo to get her take on it. “Developers are very good at their job,” she said. “Unfortunately, most people forget that they are also human beings that make mistakes like everyone else. Clean code is always the goal, but just like great writers can make a typo, great developers can also make the equivalent of a typo in their code. Expecting perfection without review is setting yourself up for disappointment, frustration, and surprise costs.” She further explained that developers and QA engineers serve different roles “A developer’s job is to produce workable tools. A Quality Assurance engineer’s job is to ensure that everything functions together cohesively. These are fundamentally different tasks.”