Be careful, as I will explain, this approach may not be suitable for every situations. You may consider specific requirements if you want to adopt this QA alternative.

During my career, I’ve mostly met teams working without QA. They worked ‘with the means at hand’, delegating testing to functional experts or product owners, and that’s where quality stopped.

Sometimes they were lucky enough to have a QA hero in their team (which I was for a while) who was familiar with testing techniques and automation, but again there was no obligation.

They operated like this, without QA, because they were limited by budget constraints. And although they started from a good feeling, all their methods were not enough to maintain the level of quality in the medium term.

They didn’t have the resources to hire a QA, but what if they could have crafted a real quality strategy ?

This strategy would have been as much a part of their plan as any other objective and would have contributed to the maintainability of good product quality.

Many companies have chosen to embrace such an approach and they dont’t need QA. Mind you, that approach is only possible in certain cases, which we will now look at.

Candidates for a QA-less approach

• Nature of the company’s domain: Companies operating in non-critical domains may consider QA to be less essential in their context.
• Product cost: Bugs will be less of a source of complaints if the product is free or at minor cost.
• Monopoly companies: When a product is well established, it can rely on user feedback to detect defects. This may not be good for its image, but when it’s the ‘best’ product on the market, there’s little risk of losing customers.
• Budgetary constraints: QA is an expensive resource and in the early stages of a product it is not the most important resource. Development without QA may be the best way to get started.

For all these factors, some companies have chosen to embrace such an approach. Let’s take a closer look at the most known case, the creators of the motto “move fast and break things”, Facebook.

Case Study of Facebook

Why

Facebook’s philosophy relies in a development-driven approach where developers are responsible for testing their own code.

This approach is influenced by the nature of the product. As a social media platform, Facebook is not considered an essential service like banking or healthcare. The company has more room to experiment with its development and testing processes.

How

Meta uses many methods to ensure the quality of Facebook. They use the “dogfooding” technique, in which all employees use the application and report any bugs they find. They also use ‘canary’ releases, rolling out changes first to employees, then to a smaller group of real users, and finally to all users. In parallel, they run bug bounty programmes to identify major issues that may have escaped their testing.

There are plenty of other cases to follow, such as Yahoo! or, for smaller companies like ManoMano et OpenClassrooms.

Benefits of this approach

Speed: This approach eliminates the time that would otherwise be spent transferring tasks between separate development and QA teams, thereby accelerating the process.

Cost-Effective: Facebook’s approach to quality assurance can be more cost-effective in the long run. By eliminating a separate QA team, the company saves on the costs associated with maintaining an additional department.

Empowering teams: By distributing quality responsibilities among team members rather than relying solely on dedicated QA professionals. This approach promotes a sense of ownership and accountability throughout the development process.

That was the utopia part. Now, here is the bad part.

Drawbacks

Workload: The main drawback is the additional workload given to responsibles. It’s all very well to say that the role will be taken on by the whole team, but when everyone is responsible, no one is responsible. Someone’s got to take the role and supervise the operation.

Finally, you chose to have no QA to add more responsibilities on your team. Nothing comes for free.

Risk of overlooked bugs: In the absence of a dedicated QA team, there is a risk that bugs will be overlooked. Developers, although skilled at writing code, may not have the same expertise in testing as a QA professional. This can lead to bugs going unnoticed and ending up in the actual product.

Reputation: If you rely too much on end users to find bugs and get feedback, it can have an impact on the user experience and damage the product reputation.

But these disadvantages can be avoided if the method is followed properly and the members are committed to the initiative. So let’s take a look at the methods to be applied to get this approach off to a good start.

Method to do quality without QA ressource

Quality strategy is different for every company. This may depend on the type of product, its positioning, its resources, its objectives…

This method comes into three simple parts: Educate, set goals and monitor to reach them.

First part: Educate

Nobody is equal when it comes to knowledge about Quality. And often, because of a lack of knowledge, there can be beliefs about the role of testers and about testing itself. For the team to be up to date, it is essential to share the same basics. Training and presentations are a starting point for this structuring. The following concepts need to be addressed:

1. Importance of Quality: First, developers need to understand the role of quality in delivering a product that meets customer needs. High-quality software results in fewer bugs, lower maintenance costs, higher customer satisfaction and how it directly impacts their day to day work.
2. User needs: Product owner or functional manager must be responsible for ensuring that users’ needs are understood.
3. Agile Methodologies: This is the base of this approach. Methodologies that encourage collaboration and communication.
4. Code standards: This is the tooling part. Use code linters, git conventions and all the other tools needed to promote optimal coding standards.

A common knowledge

I mentioned presentations or training, but it’s even better when these presentations are an initiative led by the team. Encourage the organisation of meetings on good practices, provoke discussions.

Centralise knowledge and seal it in a wiki. Set up a notion where you will gather all the quality standards you and your team have agreed on.

It can look like this :

Include quality in all discussions

Quality must be a part of your agile ceremonies as much as velocity is.

In fact, while velocity is about ‘how fast we can deliver’, quality is about ‘how well we can deliver’. Discuss to always set the right balance.

Empower the team

You will need to identify the QA hero or heroes within your organization. He/she will be responsible for ensuring the proper implementation of these methods. Without this, this approach remains an additional burden to be carried on the manager’s shoulders.

Second part: Set your goals

Establish and communicate clear quality standards for the product. This could include performance metrics, user experience standards, defect tolerance levels or anything else.

Some examples :

An other goal can be more technical and roadmap centric, like : “Define together the development plan for your continuous integration over one year.”

Third part: Tools to reach your goals

Measure

We didn’t say it enough so I repeat “If you can’t measure it, you can’t improve it”.

I wrote an entire article about it, so if you want to go deeper on QA metrics it’s a must read:

Monitor

Monitoring is the first key element in maintaining quality without a dedicated quality assurance team. It’s not only about monitoring tools, it involves keeping a close eye on the product and the development process so that any problems can be detected quickly.

Tools such as application performance monitoring (APM) software can help you track the performance of your product in real time. Regular code reviews and pair programming sessions can also help detect potential problems before they escalate.

Automate

Automation is the second key tool in maintaining quality without QA. Automated tests, continuous integration and continuous deployment (CI/CD) pipelines, all those automations will reduce the risk of errors and speed up the development process.

However, it’s important to remember that automation is a tool, not a solution in itself. It should be used in conjunction with other strategies, not as a replacement for them.

Conclusion

Achieving quality without QA is a challenge, but it can be very rewarding if it’s done well, especially in terms of team collaboration and empowerment.

But be careful not to overload the team with too many new responsibilities at once. You should also ensure that the quest for quality does not compromise the team’s ability to deliver results.

Finding the right combination of collaboration, best practice and automation requires constant evaluation, feedback and adjustment. It’s a lot of work.

Do you have similar methods ?

Who is in charge of this in your company ?

Let’s discuss and move the debate forward down the comments.