Quality assurance and quality control (QA/QC) in project management is much misunderstood. People tend to associate quality with particular methods, when they should really be focusing on results.
A ‘quality’ deliverable is one that’s fit for the purpose specified by the customer. A quality toaster for the home is likely to be completely different to one for a hotel, because of the volume of use each endures. Producing a domestic toaster to catering appliance standards is likely to result in a large and very expensive toaster with few benefits for the home user; do it the other way around and the hotel will end up with cheap toasters that soon break down.
The two major elements of quality assurance in project management are:
- Review and sign off
Review and sign off
A review is the single most effective means of maintaining quality.
It also provides a forum to encourage creativity and ideas: ‘That’s good, but have you thought about doing it this way instead.’ Creative thinking comes more easily from groups than individuals. One person’s idea can spark off a new, even more exciting thought in someone else.
So let your hair down. Review IT code, documents and processes – in fact, review everything you think you have completed. It isn’t just a useful exercise but a cost-effective one. Devoting a relatively short time to a review removes errors early on and reduces the need for expensive re-working later.
All major requirements, deliverables and designs should be reviewed and signed off by the person who is going to use the deliverables or someone they’ve delegated to do it in their absence. This ensures that there are no arguments down the line about exactly what was required.
Consider how you carry out reviews. Although it’s become the norm to send documents by email, it’s more involving and interactive to get interested parties together at a meeting to review the document.
It isn’t hard to organize. All you’ll need is:
- A chairperson
- A scribe to document agreed actions
- The author(s)
- Reviewers, including whoever’s responsible for signing off.
Remember to instruct attendees to read the relevant document(s) before the review, and to come armed with their comments.
If you do nothing else well on your project, do the testing well.
You need to be 100% certain that what you’ve built conforms with what was specified in the Requirements (or Product Backlog if you’re involved in an Agile project). If it doesn’t – and depending on the severity of the faults and their implications to your customer and theirs – you’re going to find yourself with egg on your face and maybe with a lost client.
The most important stage
Get testing wrong and you potentially end up wrecking your productivity, your reputation, your legality or possibly all three. People tend to associate testing with IT, but an untested process can have disastrous results if opened up to the public.
It should go without saying that you should always formally walk through changed processes before implementing them. It should be as unthinkable as opening an untested road bridge or launching an untested plane.
You have to be exceptionally lucky for anything to work well on its first exposure to the real world, so going live without testing is a very risky strategy. Don’t do it.
The other rule with testing is to be thorough; it should be obvious that there’s little point in testing something unless you do it properly. The risks of cutting corners always outweighs the benefits and the costs of fixing something after go-live are much higher than they would have been earlier in the process.
That said, there’s a difference between being thorough and being ridiculously over-cautious. There are reasonable limits to testing!
Phases of testing
You should anticipate covering some or all of the following phases:
- System testing (does what’s been built conform to the specified requirements?)
- Acceptance/user testing (does it work operationally?)
- Performance/stress testing (does it work under load and meet performance requirements?)
- Security testing (for example, are you sure that an IT system can’t be breached or that a process isn’t open to internal or telephone fraud?)
- Model Office Testing (simulating usage in a real working environment – usually this is only carried out in big or complex implementations, such as a call centre set-up where systems, telephony and processes are new and staff have been recruited and trained).
Testing of IT systems is, to an ever-increasing degree, carried out using automated test tools. With an automated test tool, you write the test once and can then run it many times.
Another advantage of automated tests is that they remain after you’ve delivered the system, so if you need to make changes later you’ll be able to re-run the original tests to make sure that you haven’t broken anything. This is commonly referred to as regression testing.
The number of test tools available is expanding rapidly. As I type, QTP by Hewlett Packard is the most widely used automation tool. Selenium is popular, free and can be used to automate the testing of browser-based software, while Axe from Odin and eggPlant from TestPlant are also capable tools with a significant following.
If you’re outsourcing any aspect of the project, don’t trust the external company to do all the testing. You should always carry out final user/acceptance testing in-house, as a quality check on their work, and may find it advantageous to attach a stage payment to them successfully passing the acceptance test. It’s a great incentive for them to work to a high standard, and without cutting corners.
Finding and fixing
You should maintain a fault log throughout testing, showing both open and closed faults, and noting their severity as well as what action is being taken to resolve them. A spreadsheet should be sufficient for this, but there are also bespoke software tools that will do it for you.
HP’s Quality Center is very popular, but isn’t cheap. You might want to have a look at Bugzilla, which is free and widely used but lacks the professional support of paid for packages. The latter provides the functionality to allow you to manage all testing, so it’s worth a look.
As testing progresses, particularly if you have a supplier involved or when the project is substantial, you may want to organize and run regular test review meetings, based around the fault log. I usually run these on a daily basis when I’m a few weeks away from the deadline to complete testing.