Nurturing a Quality Focused Approach in a Team of Developers

🗄️ Archive
1

Hello everyone,

Due to changes in the organisation structure at work, I find myself working in an Agile team that consists purely of developers and a product owner (i.e. no dedicated QA). As the designated “Quality Champion” of the team, it is my job to implement initiatives in the team that encourage and nuture a development lifecycle with a focus on quality.

Some of the initial ideas that I have to implement this approach are:

  • Ensure that all team members understand that everyone (including product owners) are responsible for quality - quality should be owned by everyone in the team
  • Encourage a BDD / TDD approach to developing new Agile coding stories
  • Make sure that Acceptance Criteria are defined up front for all new Agile stories, and all ACs are met before a story can be closed

What are some of your ideas on how I can grow a Quality Focused culture within my development team?

Looking forward to your responses!

1 Like
2

Your ideas are technically sound, but part of testing is knowing the weaknesses in an approach. So I’ll start with those:

  1. Quality owned by everyone is a cultural problem that can be difficult to establish. A team that’s restructured to have no testers sends the message that quality isn’t important. Also if people don’t already want to consider quality in their job and they don’t feel like that have to for any reason, then they will not. Be careful of being formally responsible of ensuring the private feelings and resulting actions of other human beings.
  2. BDD/TDD are useful development tools, but they’re not testing. “Encouraging” is easy to do, but it usually results in no practical changes - you need to either have people who want to do it or make them feel like they have to.
  3. Acceptance criteria are nice, but they are woefully insufficient. They describe some thing it should do at some time under some condition on some platform and miss out a vast chasm of valuable things to look at. They also tend to forget everything it shouldn’t do, and they also tend to miss out on actually providing a good, working solution to a human’s real problems. “ACs are met” is a minefield, as something can be met as described but not have much value because of the fuzziness of communication and interpretation, and some people think that a BDD check means that the check title (e.g. “test valid login”) is genuinely testing that criterion, and it’s not.

I mention these because I don’t want you to pick up a difficult problem with vaguely defined edges and find yourself in trouble. I don’t know you or your company but “Quality Champion” sounds like a nonsense title designed to make a company feel better about not having a solid test strategy and set of quality processes underlined by an expert risk-analysis and context-based methodology. If you have a political title then one might argue you only need to do a political job, and I’d probably advise you to watch out for being treated politically. Again, I don’t know your situation, I’m guessing, but there it is for what it’s worth.

Okay other ways to encourage quality:

  • Insist on testability - this would usually be your testers’ job. Make sure you can hook into your code where you need to, make sure you have tools to help operate or observe your product and its inputs/outputs, ensure you have required logging/alerts, make sure that you can operate it in a reasonable environment before production, and so on. Here’s a great resource on testability: http://www.satisfice.com/tools/testability.pdf
  • During kick off (or whatever you do) ask as many questions as you can about things that might go wrong. the HTSM is very useful for thinking about what might be needed and what might go wrong and what you might all do to test your product (http://www.satisfice.com/tools/htsm.pdf).
  • Question anything and everything that feels unsaid or unexplored. If you see a document or diagram or lazily put together sentence use critical thinking to explore the possibility that part of it is not understood or defined, or might not be true, or might not be important, or might be incomplete in an important way. If you can think why it might matter, or you don’t understand something so you can’t evaluate if it might matter, you should say something about it.
  • Break stories down more. Smaller pieces are easier to deal with. Don’t forget that coding and testing aren’t usually 1:1 - sometimes you need next to no testing for a huge code project, sometimes the inverse is true. In one extreme example I spent a month testing a 1-day coding story.

Hopefully those are helpful - happy to answer any questions. I might come back and add more later :).

5 Likes