Quality can come at no price

“Quality, Features, Time, pick two” is something you hear many times in teams on development projects. I am more a proponent of discussing only Time and Features with clients; but that’s only because I believe Quality can be achieved with a very low effort, following a few simple principles.

You might find that they sound like common sense sometimes but, by (recent) experience, I know there are many places where there is room for improvement!

Test, test, test and test!

OK, we’ve heard it many times from the Agile crowd, but however you do, test has to be done. Not one time, not two times, but all along the development. This is very documented and it really makes a difference:

  • screen usability tests[1]: even if you use just the hallway usability test, it will help making sure you are not going in the completely wrong direction with the UI; 80% of usability blunders can be picked-up in a day’s worth of usability testing and fixed on the fly.
  • automated code tests (unit tests and business cases)[2]: you really have to convince your developers that they can’t release code for which they don’t have automated tests. If it can be tested, it is better designed; if you have a test for a bug, the bug will never appear again (or at least you’ll know it).
  • user acceptance tests[3]: the customers have to be educated to come up with testable requirements; they will do the testing themselves!
  • load tests: if performance is likely to be an issue, test at least at the worst-case expected load level. It is better if the tests are automated.

All in all, it seems like a lot to do, but quick usability tests will avoid complete redesigns (1 day), automated code tests will keep you going free of regression bugs (cost of developing the tests balanced by the gains on regression bugs), UATs will make sure “everyone” understands the requirements (costs included in the requirements specification) and load tests uncover nasty surprises early on (a few days at worst, but gains on redesign at best)!

Choose good working environments

This looks like a pretty standard thought at first but if you try and assess what software people use in your organisation, you will certainly find out that many use programs that don’t fit their needs. And when I say needs, I mean features as well as usability. People will go to unbelievable lengths to have their program (most probably installed by default) do what they want them to.

For instance this doesn’t look good when your testers save emails and paste screen shots in Word documents in order to keep a track of bugs and tests. Have them use a bloody testing database and bug tracker!

Now imagine what you are going to impose to your developers when you chose a development platform. You have to have a pretty damn good reason to choose to have your logic coded at the database level (think PL/SQL) when you know for sure that it is probably the worst development environment possible (except maybe for APL :).

Tooling matters a great deal. It can make the difference between solving a bug in half a day and spending one week with fear gripping your bowels.

Choose your project’s tooling according to your staff skills and not according to some dubious trend. And if that involves implementing a good skills management strategy in your organisation, well, isn’t that what you should be doing anyway?

Check upon your experts

You can be confident about the quality of your software when you are confident in the experts. Those are the one you take your advice from and those you entrust with the development of your system.

Advice can be checked quite easily. You probably can get a good idea of an issue with a bit of googling… but you certainly can find someone in your network who has already gone through the same questions.

Work can be checked too. But it requires a bit more tact. However, if your DBA (OK I have something against databases today, but the point could be made with any one professional… think plumbers) consistently spends more time to do things properly than your good sense is telling you that he should, you might want to know if you can rely on him!

Do those checks regularly. Peer reviewing is probably the approach that yields the most effective results in terms of actually getting the answer you’re looking for, but it implies you have peers at hand that can be diverted from their actual jobs once and again. Also, your team might feel, rightly, that they are under scrutiny… and they might not like it.

The best way to do your checks is to have each member of your team explain what they are doing to the other members of the team. Have them show their code, their database configuration, their UI… peer review will occur naturally. And better, knowledge will trickle down through your team!

Surround yourself with good people

It’s a corollary to the previous one but also a summary for all of this article. If the people you are working with are dedicated to do their best at coding, optimising their environment, not talking BS, testing and developing their knowledge, there is a great chance they will produce good quality software!

Now all you have to do is actually build the system your customer wants!

[1]Register to Jakob Nielsen’s Alertbox and read one or two of his books for a first approach. Most web usability principles can be adapted with good results to rich client UIs.
[2]See JUnit or TestNG for Java, NUnit for .Net, but these principles can be adapted (and indeed found online) for any language.
[3]As a starter, read this article for customer-driven development and testing

Sphere: Related Content

Leave a Reply

You must be logged in to post a comment.