|
And the one time I do, it crashes. Every other time, I've had it tested and it clears fine, the one time I'm "confident" enough that it could go live without a hitch, BLAM..
It only takes once.. -_-
/////////////////
-I’m a DHCP server at a local restaurant. This chick came up and asked me for my address, and I told her she was out of my scope
-Why do Java Programmers wear glasses? Because they don’t C#
|
|
|
|
|
LOL,that's exactly my experience
|
|
|
|
|
We used to, but only few times.
It was more a result of pressure and bad communication than arrogance and vanity.
|
|
|
|
|
I have in the distant past built and deployed untested, beyond basic it doesn't fall over, patches directly to production environments.
Now, nothing leaves 'the building' without documented test notes. That way if a client comes to us saying we've deployed kack, we can show how we tested the kack and what the results were. It saves heavily on legal fees.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
Mind you, I have been guilty of causing a different bug by fixing the original. And not spotting that when I released the software.
And, I did get someone to fly from Glasgow to Hampshire, pick up some new EPROMS and fly back - with exactly the same software as he started with. But that's not untested software, it's just untested EPROMS. Oops.
And at the same company we had one programmer who had rotating bug syndrome: Fix A causes bug B. Fix B causes bug A. Repeat until the customer threatens to sue...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Manfred R. Bihy: "Looks as if OP is learning resistant."
|
|
|
|
|
OriginalGriff wrote: I have been guilty of causing a different bug by fixing the original. And not
spotting that when I released the software.
Me too and I hate it when that happens, so embarrassing!
Ali
|
|
|
|
|
+5 for rotating bug syndrome, my dev counterparts do that. I log a call to fix bug a, comes with bug b, send to fix b, returns with a. and so on, till i get frustrated and fix it. then get an email, ooh have you tried " x y z", and " x y z " turns out to be what i did. lol
|
|
|
|
|
"Software testing can be used to show the presence of bugs, but never to show their absence."
It is a fact of life.
|
|
|
|
|
This is true, but way too much software gets released without any apparent quality control having been done: Microsoft Betas, anything by Corel...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Manfred R. Bihy: "Looks as if OP is learning resistant."
|
|
|
|
|
R. Erasmus wrote: but never to show their absence."
Although software testing cannot show the absence of all bugs, it can surely show the absence of a particular bug?
Ali
|
|
|
|
|
I think this is along the lines of Rummy's "unknown unknowns"
|
|
|
|
|
Alison P wrote: the absence of a particular bug
on this computer at that very moment in time.
|
|
|
|
|
Actually I don't agree.
Here is a simple example to illustrate what I mean, if I forget to clear a variable when required in a function then I fix that bug and retest, I have established 'the absence of that bug' on more than just that computer at that very moment in time. That particular bug has been fixed on all computers all the time.
Although I fully accept that there could be any number of other bugs that may appear on other computers at other times, I do believe that by fixing then testing I have proven beyond reasonable doubt that I have truely fixed that particular bug.
If I didn't believe that I think I would have to give up programming and become a baker or something that requied less logic.
Ali
|
|
|
|
|
OK, if you actually locate a bug, yes.
My statement mostly applies to passing tests - yet another reason for automated tests 8where applicable).
|
|
|
|
|
That may very well be so, but that's not an argument to skip the test altogether.
It's a fact that you can only find your lost carkeys if you look for them. How many keys you're about to find, remains to bee seen.
Bastard Programmer from Hell
|
|
|
|
|
I 100% agree with that. Testing is required... Whether formal (dependant on the need, by specialized software testers). Or super informal (by the developer himself). Or informal (by another developer). Why I mention two informal's here is because it is better for someone else to test your code, but if left no choice, which is in many cases the case the former would have to do.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
|
A short (real) story:
A dev thought he was above having bugs. His colleagues managed to prove he had a critical bug, no less.
When he was shown the bug he reacted as such "I will not let reality confuse me", got up and went back to his cube.
Alberto Bar-Noy
---------------
“The city’s central computer told you? R2D2, you know better than to trust a strange computer!”
(C3PO)
|
|
|
|
|
hopefully he was then fired for being unprofessional and being a general twit?
|
|
|
|
|
Yep... Oh now there are 2 of "them"
To Err is human but to make a mess you need a computer
Alberto Bar-Noy
---------------
“The city’s central computer told you? R2D2, you know better than to trust a strange computer!”
(C3PO)
|
|
|
|