Carl Bruiners Agile / IT Development Consultant

5Jan/122

Reap the QA rewards by reducing defects

Reducing software defects has huge rewards for a business. I recently put together a slide on the commercial benefit of reducing defects, to quantify this as a cost to the business I put together a simple demonstration on the cost to the business.

Base

  • £58 p/d
  • 10 incoming defects p/w
  • 2 days per defect to fix

Defect Saving - Carl Bruiners

If you reduce the total incoming defects by 40% in the first year you'll save just over £22k, but it is completely feasible to achieve a 99% reduction in your incoming defects and your saving would be £55k p/a.

Any managers reading this will be over the moon, but the developers / testers and release managers will be scratching their heads @ how to achieve this. Defects only occur if you allow them to escape in the first place, look at your testing strategy, automate as much of your testing as possible, achieve continuous integration and aim for continuous delivery. Achieving a 99% reduction would be easier in some environments than others; i.e. a web application is going to be far easier to drastically reduce the incoming defects than a legacy installed application on the desktop (as you may not have the capability to upgrade / update desktop applications as frequently).

27Oct/100

Testing in SCRUM / SPRINT

One of the area's were SCRUM is not very strong is testing. Most of the SCRUM models that have testing (EVERYONE should have testing) as part of their SPRINTs normally adopt XP's TDD. This is completely fine, TDD is great, but there are also additional / alternative ways to gain better QA (Quality Assurance) by implementing a simple QC (Quality Control) framework within your SPRINT's.

My current SCRUM wall has 5 phases;

  • Not Done (SPRINT Backlog)
  • In Progress
  • Ready for Test
  • Test
  • Done

Phase 1 and 2 belong to the developers, before a task card can be promoted to 'Ready for test' it has to be peer reviewed (both at a functional and a code level). Phase 3 and 4 belong to the testers, only a tester can promote a task card to done. If it fails a test, the tester places the item back into phase 1, 'Not Done'.

I find this model enables the team to achieve very high QA. For a task card to be promoted to 'Done' requires it to have passed through two testing phases, firstly the peer review and then the testing team.

If QA is of the most importance (*note: that SCRUM normally has some tolerance built in for bugs, but certain work, such as life critical medical software, cannot afford any bug), then you can introduce an additional testing phase between Test and Done where by a task card must be peer reviewed through a senior tester / another tester before being promoted to Done.

I started of this entry by mentioning TDD, and the simple QC model I have given should ideally be used in addition to TDD (which I am a fan of), so that you enable your team to achieve high QA with minimal disruption to their daily workflow.

Tagged as: , , , , , , No Comments