Everyone who’s taken part in creating a web page, store or computer program knows two things. Quality is very important. Getting satisfying quality is very hard.

You can think about unit tests, behavioral tests and automatic integration. In fact, you should, because all of these things are very important. In my experience doing IT projects, however, the best quality assurance tools don’t just work by themselves if we don’t use them properly. We have to insert them into a particular kind of process.

The production process doesn’t sound very appealing, especially to a startup or a small, motivated company. I feel the same way – I’m an opponent of all overheads that reduce a team’s efficiency.

That’s why, at Divante, we came up with a simple way at the very beginning that still functions today with just a few tweaks and adaptations.

At Divante, quality assurance checklists – that’s what we’re talking about here – are called DQAS, Divante Quality Standard Assurance :-) The name is a lofty one, and it was created just for our company – as an elegant acronym used for summing up applications for open programmer positions. I always analyze a candidate’s code during the recruitment process, and if it’s not good enough or safe enough, I just write “Your code is not consistent with the DQAS practices applied in our company.” :-)

But that’s beside the point. The lists I’m referring to concern various aspects of project creation in our company:

  • aspects associates with writing code,
  • aspects associated with usability,
  • aspects associated with SEO,
  • aspects associated with project management and customer service.

Checklists can be in the form of simple documents created in Google Docs, accessible to the entire team. Our checklists are informal, often fun – and most importantly – are created by the whole team. In this way they collate the knowledge of an entire, interdisciplinary team.

A quality assurance checklist doesn’t replace expert knowledge and the experts themselves ;) It is the absolute minimum which must always be present for us to think about taking a project to the next stage, presenting clients with the product, or finally moving it “into production”.

I’ve noticed that these lists – if they aren’t too long – also perform an excellent instructional function for new employees. Someone who is joining the team knows right away what standards need to be maintained. Since the lists are created by the team and everyone can add something, everyone feels jointly responsible for quality.

Here’s what part of a list by our programmers looks like:

  • Don’t use the message “No information.” It’s a slap in the face to the user. Make contact with the user and write something like “Currently we do not have the products you’re looking for. Don’t wait, check out our promotions and find something for you!”
  • Commit code to SVN after every change that doesn’t destroy the test version.
  • Before test demonstrations, check if margins are equal everywhere (buttons, images, logo …)
  • If HTML doesn’t work with SEO, it doesn’t work. The structure of headers, semantics, alts, divs instead of tables, metatags, good links
  • Design patterns were made to be used. Whoever doesn’t use them almost definitely writes poor object code.
  • Whoever doesn’t apply DRY rules doesn’t know how to program :-)
  • Cache is also made to be used. Whoever doesn’t cache shouldn’t say that the program runs slowly. It’s got to run quickly.
  • Faster is better than slow. Much better.
  • No favicons on the site is a sign of untidiness.
  • If you’re suddenly attacked by exceptions, it means something going on … Log all exceptions in a file or PHP diary and trace them so code can be debugged. Checklists are great, but they tell you how to run a project. The 10 DQAS Commandments are a matter of a programmer’s honor.
  • Showing exceptions on the production server is like putting naked photos on photo.com
  • “Don’t use echoes like ‘wiener’ or other strange words – they might stay there
  • Kosher programming. (http://pear.php.net/manual/en/standards.php)
  • “Always escape the entrance so you don’t suffer from a code injection!”
  •  …

As you can see, it’s pretty informal :) Of course we have other tools besides lists – a ticket system, version control, unit tests, output tests, security tests. In general – a ton of tests.

During a recent meeting with a client from the fashion industry, the client remarked that “Even your programmers talk about monetizing” – in reference to how our programmers presented a few ideas on how to increase sales online by using recommendations and optimizing purchase paths.

These comments make me happy, and make me think that DQAS works :-) Every employee should think about the ultimate objective associated with our product – sales, views, ….

What do you think about this idea? What quality assurance methods do you use in your business?