Do I need QA for my Adobe Experience Cloud Project?

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.” 

In most businesses, the people who build the product do not also do the QA testing. The same goes for code development. If you are testing your own work, then you are not going to catch bugs that someone with a fresh set of eyes can.

“It is going to slow things down.” 

There is no guarantee that it will slow development down at all. In fact, if you look at a project from start to finish, you will likely see that having QA in the process accelerated development time overall. As Lauren explained, testing is always going to happen. “Testing is going to be performed regardless of whether or not a QA Engineer is on the project. Skipping QA doesn’t make development go faster, and it often has the opposite effect.”

If a developer has to stop and test something then it means that they aren’t working on the next feature. It can also shift where and when that testing is going to be done, not to mention by whom. The last place you want a problem being found is after it is in production, by a user of the website, the ultimate tester, and finder of bugs. If you don’t do it then you should expect the need for hotfixes and possible production outages, leading to lost time.

“Quality Assurance adds to the cost.”

Cost is the most commonly cited reason not to use Quality Assurance engineers, so let’s explore what it can actually cost. While not every project is the same, we have seen trends in project work when quality assurance engineers aren’t used. We've found that QA testing takes about 30% as long as the development. So, if a developer spends 100 hours on a project, the QA will require around 30 hours. This cost is offset because a development team can complete the more technical work more quickly. 

To get a better idea of how this works, the image below shows an example of a 6-month AEM project, comparing the costs incurred by utilizing a QA engineer and a developer vs having the developer handle both feature work and QA responsibilities.