This column went a long way! We started at the beta tester’s shacks, moved on to your lab-and now, it will go right into your mind. Just in case you are joining in now-here are the old parts:
The art of beta testing-On unprotected betas and beta fraud
The Art of beta testing-On testers
The Art of beta testing-Completely outsourcing tests is dangerous
The Art of beta testing-Random testing is useless-structured testing rules
Releases are final-gungho coding hurts
Imagine this situation: all of your beta testers gave your final release candidate an o.k.. You could release the software right now-but then you still have that tiny idea. This feature takes just five lines of code-you go ahead and implement it quickly. Then, you test it and release the convolute created. Having the testers go over it is pointless, as:
Stuff that works+Stuff that works=Stuff that works
While this method can work well, you always risk inserting a bug. A single line of code can cause a race condition in another module. Since you dont test the program as whole, this bug can move into the released version.
My method here is simple. I disable the running configuration of the program in PODS until it is released. This way, should ‘the inner kid’ take control, the program simply desnt build-and the alert reminds me of the release candidate.
That feels better. My mind is dumped, and thus I overcame an old problem of mine. However, the ball is now in front of your feet. Tell us about your strategies!
Related posts:
Content, RSS
Twitter
My/Our strategy is not inserting new features after testing is OK.
A tested version is an stable version an a new untested version ist “de facto” an unstable version!
Do not distribute unstable versions!