Slashdot Mirror
Bug Pushes Vista Out to November 8th
IntelliAdmin writes "Microsoft originally targeted October 25th for Vista's release to manufacturing, but a last-minute bug that 'took most of the Vista team by surprise' has caused an unexpected delay, said Ethan Allen, a quality assurance lead at a Seattle high-tech company that tests its products for Vista. Allen said the Vista team discovered the bug, which 'would totally crash the system, requiring a complete reinstall'. Vista now has a new RTM date of November 8th" A reader wrote in to point out this story originated with Paul Thurrott.
If you didn't actually need to re install vista after the crash, they probably would have went ahead with the date and patched it up later. But honestly, who really expected vista to not get delayed again.
I would guess its got something to do with the security and DRM authorisation side of things.
It might not be as technically damaging as a filesystem bug, but with the DRM tied into everything if it fails the system will be left goosed.
I remember the cryptographic service failing on Windows XP causing problems, but this was fixable because it wasn't at the core of the system.
liqbase
1) Vista has suffered from massive flaws, bugs, etc. ever since it was still called Longhorn.
2) Most of the IT community believes there's no chance Vista will be released on time.
3) Microsoft swears on its collective mothers' graves that Vista will be released on time.
4) Weeks before the scheduled release, a "massive and totally unexpected" bug forces the release to be postponed.
Smart money says that MS cooked up the bug to buy themselves an extra week or two of code/debug time. That money also says that in two weeks, they'll find another massive flaw, and so on...
First rule of trauma: Bleeding always stops.
Our company did last year, city of Vienna did, it should work out very nicely for you too. Our former XP users love KDE.
No need to put yourself through pains when you can improve security, save money and achieve a good deal of vendor independence all at the same time. Why support the Microsoft monopoly by paying ridiculous prices for bug ridden software with DRM restrictions, when you can run Free software on the industry standard (and thus inexpensive) hardware?
Knowing everything I know now, I only regret that we did not migrate to GNU/Linux sooner.
That, my friends, is what you get if you rely too much on automation and don't do enough manual poking around. For those who lack context, there's a strong push in Windows to do as much testing through automation as possible. As often happens when a $1M exec bonus depends on something, the underlings got a little overzealous and either fired software test engineers or "up-converted" them to "software development engineers in test" who were then told to write automation. The effect of this is that you have bits and pieces of Vista that are tested really well and other bits and pieces that aren't tested _at all_. One needs to remember that when your automated test case finds a bug and that bug gets fixed, it's not likely to find more bugs in the same code path. This doesn't mean there are no bugs in the code. This means there aren't more bugs _in this exact code path_ that test case exercises.
But... It's not exactly easy to find EVERY bug that there could be. A software tester is a software tester, not a typical user. Programmers are programmers, not typical users. They/We don't even always think to do things the way a user would do them.
I'm a programmer, and I know that I definitely (Firefox, I love your spell checker!) don't use the program the way our users would. If I want to get to a certain point in the program, I typically use the fastest route to get there, not always the most probable route that a user would take. After writing some code, I try to be thorough in testing the results, but since I don't use the program the way the user would use it, I don't always think of the scenarios where a bug might have crept up. (That's why software testers are so important, but I think we need to cut them a little slack, sometimes, too.)
I just got done trying to get Vista RC2 running on a spare hard drive, to get a "real machine" feel for the thing.
My experience -- It sucks.
1. The thing doesn't have support for my SATA controller. Gigabyte board, Ali SATA controller. I had to use the XP drivers. Tell me that Gigabyte/Ali are no name brands that no one's heard of. Not a deal breaker, as there's a work around.
2. Install is extremely slow. My personal idea is that every step along the way, the install is trying to find an IDE hard drive for some reason, but since I don't have one, I'm having to wait for timeouts. I'm not sure if this is the case, though.
3. Once you get in... My Geforce 3 can't handle Aero, so MS helpfully turned it off. The default theme is ugly as snot, with huge window borders (4-5 pixels), baby blue in color. Trying to change this baby blue color yielded no results; it stayed baby blue.
4. Getting used to the explorer shell again (I use Geoshell on my windows boxes) is a pain. What they've done to Explorer makes it less user friendly, instead of more user friendly. Granted, I don't use Explorer very often either (I use Directory Opus on my windows boxes), but even XP's Explorer is better/more usable.
5. The thing that made me finally throw my hands up in frustration. Somewhere in the 6 hours I had it running, I managed to completely lock myself out of Control Panel. Every time I'd try to go in there to get to something, it would crash. Whether I did it off the Start button, whether I did it from Explorer, it didn't matter... Explorer would crash. Another co-worker had this happen on a VM install of Vista, but he got around it by using MMC and manually adding in the plugins of whatever he wanted.
For RC2, this is a sad state. I remember, back in the day, happily running NT4 Beta 2 for months and months. Oh well.
It is obvious that you have never worked in the QA department anywhere. Automated testing has its place. However in my +8 years of experience as a QA engineer after you're past Beta, automated tests will rarely find bugs.
The problem with automated testing is that it is "rigorous, predictable and regular". End users are NOT. If all users could be counted on doing the same thing the same way every time then automated testing would be all you need.
It's the QA engineer's job to take the testing past what a script can do. Let me give you a for instance
Let's say product P crashes if you do X, Y and Z, and your auto scrip finds this. So it gets fixed, and the scrip gets run, and voila, the bug is fixed.
A good tester will see that and explore the fix. Lets say the fix involved the way files are handled in memory. Well X, Y, and Z work now. But a good tester will think "what other parts of the program could be effected by a change in memory usage"? And then find a bug in A B or C that was introduced by the fix.