|
Our hardware is a large tracked green vehicle. When we need to test properly they lend us one. When that works we go to a shooting range and bite our nails while they drive around and go bang.
The rest of the time we have the same computers set up in a lab, and we can test there as much as we like, but it's never the same. There are always new bugs on the vehicle.
Once we stopped testing at the end of the day and then next day nothing worked at all. It wasn't exchanging messages. I found the IP address of one of the components was wrong. WTF. The project leader confessed he had done some little tests after we'd gone home...
------------------<;,><-------------------
|
|
|
|
|
I can second Davide's post. We have two reasons that we occasionally give users updated software without specific testing.
Sometimes the bug we've fixed is caused by the user's data formatting (we make commercial ink-jet printers), and they will not send us the exact data that exhibited the problem. We understand their secrecy, since the documents they are printing can be financial statements or other data with privacy issue. The only way we can fix these issues is if the customer gives us a precise description of the problem. These issues tend to iterate a few times before an acceptable solution is found.
We also have the hardware problem Davide described. In our case a customer configuration can represent a unique combination of $2-$5 million worth of printing press hardware. We often can't reproduce these issues in-house because we don't have the custom hardware they are using, or they have odd timing arrangements. We use simulation or emulation where possible, but sometimes end up making fixes and sending them out untested. We also send engineers on-site occasionally.
Davide Zaccanti wrote: Sometimes a remote COM interface connected via internet can help, but few customers open their firewalls.
We use Remote Desktop or WebEx if available, but like you most of our customers don't give us access to the machines through their firewalls. We have to rely on diagnostic information generated by our applications, which our service engineers and customers can send us for post-mortem analysis.
Software Zen: delete this;
|
|
|
|
|
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)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
