- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
... testing is important guys..... if you're hired to test and you lie.... well that's why we have Vinnie and the boys down by the docks on retainer...
Admin
During an internship I was tasked with writing a test to compare the output of an old FORTRAN program (which was used to calculate properties of chemicals depending on given temperature and pressure) with a more recent program written by an external company. My program filled an Excel spreadsheet with the calculated error percentage for various values and colored the cells depending on the percentage. First run, I get a completely red spreadsheet with all errors over 100%. :wtf: I quickly found out that the FORTRAN was outputting values which were precisely the values provided by the other program... multiplied by 1000. As it turns out, the bug was in the FORTRAN program, which has a wrong unit conversion factor. Since everybody else used the defaults output units, nobody did notice before me...
Admin
TL;DR Project screwed up, devs get the blame.
Admin
When I was in testing we had so many WTF like this and they never got fixed. The biggest one is when the test never ran and it still reported pass. We got suspicious when it was able to test every checkin without any delay while other tests took hours. Once we fixed the issue, it was all red and took some time to find out when the product regressed. This test issue wasn't fixed. If it doesn't mount the NFS correctly then it will do it again.
Admin
project screwed up?
no TestDev writer screwed up by lying to make the tests pass. ProgDev found out about it and fixed the tests so they no longer gave false positives.
TestDev was rightly fired for that (and is damn lucky Vinnie didn't get a call for some new cement shoes) and management overreacted and canceled entire project.
do yes dev got blamed but only because other def fracked up big time and it wasn't caught until it had spread far enough that big bosses noticed when it fell apart.
Admin
Tester was rightly fired, but if the project was that important, it's odd there wasn't a single outsider (project manager, or some developer that was not involved) checking the progress.
Provided the story is true, of course. For all we know, the reason that all tests failed was because Derek was not good at porting FORTRAN.
Admin
well it was frontpagified.
i'm assuming that there's a kernel of truth to the story still under all the artificial drama.
for all we know the original submission ran along the same lines and the same length of my summary. (either one of them)
Admin
The truth can be hidden inside that story: there is more than one path to the top of the mountain. It may well be true what's written, but what's hidden? Will Derek find the courage inside him to confess? Can the tester find another job? Tune in next week!
Admin
They were probably stored in kilovalues due to the limitations of the input textbox.
Admin
I sometimes wonder, in a project like this, who's checking that the calculations are still correct. If the original code was that fubar'd, how are they certain the results from the original are still correct?
Actually, while reading, that's what I thought the real WTF was going to be; they'd find out the original code had been incorrectly calculating numbers.
Admin
+1
It would probably be better to write tests for the original program (to at least be sure that it works correctly) and then check if they work with the new program.
Admin
OMGWTFBBQ!?!?!
Are we returning to sensible TDWTF content?
Admin
Admin
Ah yes, the output of the new system must exactly match the output of the old system, regardless of correctness. I know it well. At my first gig we made telephony switches. We had a HUGE codebase that had accreted over time, written almost entirely in assembly and an in-house "high level" language with a buggy pessimizing compiler. (You know, one that examines the code and emits the least efficient assembly possible). This thing was built to run with real TTYs. The kind where the color of the display was determined by the kind of paper you loaded. Automated tests weren't really a consideration.
Naturally the hardware aged, and new versions of the processor were introduced. We made a couple attempts to replace the original with the newer, faster models... And each time we gave up, because we couldn't be sure that the new timings wouldn't change something subtle and cause phone calls to be billed ever so slightly differently. We considered adding wait states and underclocking the new processors, but in the end it was decided that with no test suite there was too much risk.
And that buggy pessimizing compiler? A new version of it had been made that emitted cleaner code and fixed a bunch of the bugs. Naturally we couldn't use it. The parts of the system where this language was used weren't so timing sensitive, but we had no way to be sure that the emitted code even did the same thing as the old compiler. In fact, we knew that it didn't because some of those compiler bugs were fixed -- and something might be depending on the behavior of those bugs!
Near the end of my tenure we replaced the proprietary point-to-point links between processing nodes with the hot new 10Base2 ethernet stuff all the kids were talking about. But no one could figure out exactly how the existing code worked, so it was easier to design the hardware to emulate the old links than it was to actually rewrite the code (and risk subtly changing the behavior!) for the new hardware. That same thought also brought us hard disks that exactly mimicked the old 9-track tape drive interface.
Good times, good times...
Admin
You could have just worked with marketing to release a new billing schema along with the hardware/software changes.
Hell, even off a 6 month discount to customers as a way to buy them over.
Nope, instead, we're going to live with this crap solution until we are so behind our competitors that we have to fire 10% of our employees to keep up, and make the change at the same time.
Admin
Clerk: The new report doesn't match the old one.
Me: Ok, I'll investigate.
<2 days of headscratching later>
Me: The old report was rounding incorrectly and giving you bad info, possibly costing the company thousands of dollars.
Clerk: They should match and they don't, so your report is wrong.
Me: The misrounding is causing factory process A to miscalculate setup parameter B for product C and make bad product more often. This isn't a problem, it's a breakthrough!
Clerk's Boss: They should match and they don't, so your report is wrong.
Me: We've been looking for this problem for a long time now. It's something the operators have complained about repeatedly.
Clerk's Boss's Boss: They should match and they don't, so your report is wrong.
Me: but...
My Boss (with half his ass chewed off): Put the same mistake into your report so they'll shut up.
Since the problem had been going on so long and the operators knew to override the setups for that product (even though they didn't always do it right), management was afraid that fixing the problem would cause more bad product than it prevented.
I don't work there anymore.
Admin
I prefer the answer.
The cost to train the employees to anticipate the new values is higher than the cost of those employees making mistakes recalculating the actual values.
The hell why you need computers then?
Admin
The opposite just happened. Having recently revamped a report, the manager wanted to compare the old versus the new. When they realized the old one was producing worse numbers, they were like, "Where are these extra numbers coming from?" and we said, "It's been reporting wrongly almost since inception, go with the new one." Their response: "Fix the old report so we can compare the loss." :facepalm:
Admin
How can we fix the old one, such that the old one is comparable to the new one, without just accidentally making the old one just like the new one.
How much fail is acceptable in the old one to do a comparison.
Admin
ho, this reminded me of the Rogue Warrior books: one of their jobs was to Test the security of Army bases by attempting to break in...BUT the army people tried to RIG the tests instead of actually improving security! considering that some of those bases they "tested" had NUCLEAR WEAPONS in storage, and they successfully infiltrated many of them by DRIVING THROUGH THE MAIN GATE AND WAVING AT THE GUARDS WITHOUT EVEN SHOWING IDs...YIKES!
Admin
Sounds like how government handles quality issues. Education system falling apart at the seams? Lower the testing and graduation standards (a US states have gone so far as to no longer require a foreign language and simply don't offer high-level maths). Workers taking too much vacation making the department look bad? Introduce sick leave. Maintenance of vehicles costs too much? Sell the old ones and buy new that don't require as much maintenance (...for now).