5 best ways to have the house full of bugs

Mood: Just after sex
Music: Elektrobank

There was a question on the LinkedIn "What are the Top 5 reasons that NEW applications are released to production prematurely?" and just 4000 letters to answer it! Not enough... Full answer published below...

It is quite hard to discuss with such a guru like Joeal Spolsky, who answers perfectly your question directly in the article. Anyway the life is about the challenge, so lets try to watch fellows, who causes that software is immature. They say:

1. We do not need QA!

It sound crazy, but that is true and I met it couple of times. Many software houses do not have the regular QA team! It happens not only because “we can not afford” (the number 5 on Joel’s list), but also because the decision makers believe “we do not need it”! I met once a very clever director, in a mature consulting company, who believed (despite number of my suggestions), that consultants can perfectly find all the bugs, when preparing the demonstrations and installations!

If QA exists, very often these guys are responsible for the other duties like builds, version management or configuration. I know the companies, where one tester is controlling the work done by 15 developers! Joel Spolsky says about 1 tester per 2. Gurock goes even further writing about dedicated software - one per one. In my opinion well trained programmers, who does unit tests can have 1 tester per 3 programmers, but they definitely need QA team, who is focused on testing and nothing else.

2. QA is tiring and boring!

Many people feel it inside their hearts and they are not strong enough to admit it. We are amazed by the possibilities of new technologies and so tired because of countless number of errors. Who like the messenger, who brings the bad news? Who wants to hear about hundred of the very specific situations, when the system does not behave, as it should? Why do we need to repeat the same routine (test script) again and again and again? Ooo my goodness, do you report the same error again? The damn QA team… they are the pain in my ass!

This is why many errors are hidden under the carpet, some inconvenient scenarios are omitted and test reports are so optimistic. It is so rare to hear: "Yes, that is sometimes boring, but it is necessary to do and I will not release the product without having this check list working in 100%!". I promise my QA team nothing else than sweat, pain and… support.

3. I want just demo version!

Very often the sponsors of the projects want just to feed sales forces, so they can present the amazing, break-through functionalities on the conference. The first one, the second one, then there is a first client... lets just install it only for this customer. We will do the real re-factoring later after we cash this deal. The real horsepower is irrelevant until the regular users start to report zillion of bugs and then the witch haunt starts :)

The other variant of this story is “add this, this and this functionality, and keep the quality!”. Sometimes it is simply impossible to froze the scope of the application (especially when agile methodologies are used) and then the application may truly explode with number of functionalities :)

4. Automated, unit self-testing is the panacea!

Part of many agile methodologies is the automated unit testing. Each function should have the shadow function, which automatically tests its effect. The idea is truly great, widely popularized, but even when the company says loudly that they use XP or Scrum only some functions are truly automated. Furthermore, in the situation, it is quite easy to neglect the other type of tests like integration, platform, destruction etc. Do we need it, if programmers do the tests on the lowest level?

Yes, we need them! If you do not do all these things, they will happen sooner or later unless you bankrupt before the first commercial release :)

5. Do not write papers - just test it!

If the QA team is not instructed to document the scenarios, work done, errors – they will not do it! Most of people prefer to speak than to write, to keep the knowledge than to share it. The decision of the final release must be based on hard, written information like the number of bugs per test iteration (how close are we to Zero Bug Bounce ), level of code coverage by tests, performance and security test reports plus number of the others. Feelings are not enough in this business!

QA team is paid for being a couple of steps before any user and knowing the strangest possible way of using the software (Joel’s 3rd story). If the final user is finding some unknown bug, the QA team fails . Not all bugs must be fixed, but all of them must be documented! You can do it only if you keep some reasonable level of documentation – check lists (test scenarios), bugs registry with reproduction list and statistics.



At the end I want to express quite brutally that the most often the business decision makers are responsible for these things as they take care about quality only verbally! Their declarations are not followed by real actions and investments. The regular quality reviews are neglected as the new, cool functionality or the customer behind the door is more important. Most of them are not capable to stay with Sara Ford talking at channel 9 until she gets into the lab. Yes, she is not sexy and she is boring :)

ps.
She probably can not also dance as the one on the videoclip, but she as amazing as the one :)