How to create a 'quality-centric culture' within a team/organization?

Question

I have recently talked to the head of the quality department of another company and they struggle with the problem that the developers still think quality is actually the QA's job. They work in iterations and have one dedicated Tester in each team.

So, my question is how to create a 'quality-centric culture', where also developers feel responsible for high product quality and participate activly? How did/do you guys handle the motivational part?

Answer 1

I feel like certain teams or people are in need of tough love when it comes to this. When there is a quality issue, point out that it could have been prevented by the rest of the team following some best practices. For example, if there are frequently broken builds, broken deploys or entire features that are blocked or not functional due to bugs you can point out that these can be prevented by:

1. Basic quality unit tests
2. Validation in a development environment prior to check-in
3. Possibly code reviews
4. Continuous integration

Being in a constant cycle of devs throwing code over the wall that is broken with major issues makes it impossible for QA to do their job, especially with only one QA resource per team. Articulate to your team that you can't test the product if it is not in a testable state and that is their responsibility. Don't sit and take the blame for things that are not your fault, or people will continue to make it all QA's fault.

After finding bugs, suggest ways that the development team can prevent them in the future i.e. add unit tests around a feature where bugs frequently appear or deploy to a development environment and do basic tests if any changes were made to the deploy.

Maybe even every time you waste X hours dealing with a completely broken build, deploy or feature, suggest that you need an additional X hours added to the schedule to complete your testing, or suggest that you need X hours of developer resources to participate in testing to catch up. Make sure everyone sees that you are blocked and this will affect your ability to do your job and find potential bugs. At the end of a release if there are bugs, you can point to all of the time spent unable to test as one of the causes.

You need to be cautious to do this in a productive way and make it clear you're trying to improve quality, not point fingers or place blame. Usually when confronted with facts and understanding how this affects your ability to do your job, developers will take the logical approach and help out.

Answer 2

One way could be to get them to do end time with the end users and customers so they are aware of the impact of their work and don't just interact with a keyboard and screen.

The company has to have a culture of it as well and it has to come from the top with managers leading by example

A quick google for 'culture of quality' will bring up lots, e.g., http://www.aleanjourney.com/2012/05/creating-quality-focused-culture.html but be aware it's not easy otherwise everyone would be doing it.

Answer 3

Part of this starts at the top. Among other things, the team's performance should be judged in terms of quality. You need to choose your quality metrics carefully so that the team's goal is to improve quality rather than just improving the metrics. For example, if you measure the team by bug count, people will stop logging bugs.

Organizations go through phases where the tradeoffs change between quality, pace, and resources. Larger, more risk-averse customers expect higher quality than early adopters. If your product requires more quality than it used to, your management needs to make that clear.

Another part of this is allowing time/money to be spent on improving quality. It might mean new tools/training/staff, but it might also mean slowing down the pace of development so that developers have more time to find/fix bugs before they declare they're finished.

You may also need to change some of your staff. This can be painful, and it should be done thoughtfully, but if a developer is prone to low-quality code, the right answer may be for them to switch to a different role or a different organization. This holds true for testers, too.

I suggest approaching quality improvements incrementally. If you want to insert automated unit testing into a team that doesn't use it, start with some modest goals. Pay attention to what works and what doesn't, and be prepared to change tactics where necessary.