These days, I'm developing pg_cryobit, a piece of software that'll allow you to manage your PostgreSQL continuous backup strategy with ease.
I stumbled upon Test::postgresql, and at first I was a bit suspicious about it, given the fact the latest version is not recent and that there's no debian build of it.
I decided to give it a go anyway. I installed it manually, and only one dependency needed another manual install. The other ones come as a debian packages (This is one reason why I don't quite like to use the cpan shell).
The tests went smoothly, and in no time I had instances of PostgreSQL ready to test with my own software.
I definitely recommend using it if you're writing PostgreSQL dependent software.
Has anyone has experience with the MySQL flavour of it?
Thursday, 7 October 2010
Wednesday, 6 October 2010
Bugs: Importance classification
Dave Child recently posted his thoughts about bug/feature priorities and asked for contributions, here's mine :)
- Blocker: Prevent any operation on the system to happen.
For instance, your app server conf file is wrong, so it won't even start. Or there's a syntax error in one of your top template. This should never pass your test phase (if it does, you've got a problem).
- Critical: A major feature of the system is broken (or missing in case it's a feature ticket) and prevent the business from operating normally. This should never pass the test phase neither.
Example: If you've got an e-commerce website, the cart does not work, or the checkout is broken.
- Normal: A minor feature of the system does not work, or a major feature doesn't work in a particular case. This could pass the test phase, but it will hurt your reputation.
For instance, your 'share with a friend' link is broken, or the contact us page doesn't work.
- Minor: A subfeature does not work, or a minor feature is broken in a particular case. For instance, redimensioning a textarea doesn't work, failing to provide a valid email in the contact page voids your avatar photo. This could pass the test phase, but only a few of your clients will notice.
- Trivial: Do not prevent anything from working correctly, but still cam harm your reputation.
Example: No feedback to confirm a user has saved its preferences, spelling mistakes, weird ordering etc..
Using this classification, and if you've got an appropriate test plan, your clients should never be exposed to any bugs more important than Normal, ideally only Minor.
- Blocker: Prevent any operation on the system to happen.
For instance, your app server conf file is wrong, so it won't even start. Or there's a syntax error in one of your top template. This should never pass your test phase (if it does, you've got a problem).
- Critical: A major feature of the system is broken (or missing in case it's a feature ticket) and prevent the business from operating normally. This should never pass the test phase neither.
Example: If you've got an e-commerce website, the cart does not work, or the checkout is broken.
- Normal: A minor feature of the system does not work, or a major feature doesn't work in a particular case. This could pass the test phase, but it will hurt your reputation.
For instance, your 'share with a friend' link is broken, or the contact us page doesn't work.
- Minor: A subfeature does not work, or a minor feature is broken in a particular case. For instance, redimensioning a textarea doesn't work, failing to provide a valid email in the contact page voids your avatar photo. This could pass the test phase, but only a few of your clients will notice.
- Trivial: Do not prevent anything from working correctly, but still cam harm your reputation.
Example: No feedback to confirm a user has saved its preferences, spelling mistakes, weird ordering etc..
Using this classification, and if you've got an appropriate test plan, your clients should never be exposed to any bugs more important than Normal, ideally only Minor.
Subscribe to:
Posts (Atom)