Hacker News new | ask | show | jobs
by shpiel 5080 days ago
In my, albeit short, experience I have found that the "do you have testers?" and "do you fix bugs before writing new code?" to be overkill for most consumer-facing web applications.

They are very important if the software is mission-critical or if there is some sort of physical cost to shipping patches. But if you can continuously update the live site its not that big of a deal if a bug gets out. It will be noticed soon, often by your users, and then you fix it and that is it.

This works if the developers and other stakeholders at the company are testing the product themselves and are responsive and can triage bug reports quickly.

Having an up-to-date schedule can often be unrealistic as there can be shifting priorities and developers should be flexible to move around and respond as necessary.
2 comments
xxpor 5080 days ago
>But if you can continuously update the live site its not that big of a deal if a bug gets out. It will be noticed soon, often by your users, and then you fix it and that is it.

You consider this acceptable? "Don't worry, if there's a bug, our users will tell us, no need to test!"

link
shpiel 5080 days ago
Yes. Not all bugs are the same in terms of end-user impact and how they affect the overall performance of the system. You can expend a lot of resources trying to track down every single last glitch in many cases you should. However, if you have the luxury to be able to push updates and fixes at any time and you a free non-critical service, its better to just have a culture of fixing things quickly and allocating resources to more high-priority things like adding new features.

More eloquently stated: http://www.quora.com/Quality-Assurance-QA/When-is-not-having...

Ideally, most of the testing should be automated and engineers should be writing test cases as they build features.

link
codinghorror 5080 days ago
basically the Joel Test is out of date in a few areas. It reflects a Microsoft Excel development-centric view of the world. The way Excel was built and shipped in 1993 no longer reflects the way most software is built and shipped today.
link
excuse-me 5079 days ago
It's aimed at shipping shrink wrapped software to a large market but it's still worth thinking about for different markets today.

It's just that all absolute statements about what you must do are wrong - except this one!

link