Well duh, if the bugs are unexpected they can't be open. Also a lot of buggy programs are "free of bug reports." It doesn't mean much until final testing of the finished product (yes programs can be finished products, before the internet there were no monthly patches of shiatty programs). "Zero defects" of the "milestone" is more like "this part of the program is finished and works." If you start to introduce bugs into a finished part of the program, you're either not planning very well or just not programming very well.
1. It is possible to program a bug-free program.
2. Security is not an inherent issue with computing.
3. A program that does not work is not finished
4. Computers are made of 0's and 1's.
5. CODECs are temporary in the computer timeline.
6. x = 2 * y means something different in programming than in math.
I agree (except I have a huge problem with "zero-defect" but I won't get into it here). I'd just like to say about your question "how many possible inputs should you test?" and the answer is: every single one.
You, as the programmer, create the inputs. Therefore you know what they are and what they are for; you wrote them in. Therefore testing them is easy. There's no input without some sort of input statement in your program.
With a robust and highly modular application you can build as many features as you want into it. Each 'feature' should be as self-contained as possible. Global variables and objects are for amateurs (and me if I'm lazy). Like, if you ever see something like this x = myObject.someObject.somethingElse.setX(temp), then you know there's going to be trouble down the road.
"Wouldn't it be nice if you could have more insight into the quality of a product, while it is developed, and not afterwards? Would you like to be able to estimate how many bugs are inserted in the product in a certain phase, and how effective a (test) phase is in capturing these bugs? To optimize your test phases regarding focus and effort in relation to how many bugs they will find? This presentation will show a simple but very effective model that makes it possible: The Project Bug Model. "
There you go, I just inserted "bug". It makes sense: Now it means "how to write buggy software and not give a ****".
Well, he might not but a developer, but I am and, guess what? I think you're an idiot! Bugs are defects. Zero defects means zero bugs. What the hell is a bug then if not a defect? A "thing we didn't think of because I've only been programming for 2 years and I got my degree at an online college and I'm too much of a career-script-kiddy-with-a-job to write code that doesn't break?" How about giving everyone else a break and stop covering your ass with "bugs aren't defects" corporate-bull-shiat-speak.
I thought what was the same was that it is Doom 3. In other words, it is Doom, part 3. Didn't you watch the trailer? Those skull heads are from Doom. I thought Romero was talking about the plot and setting, not the game engine. If he was talking about the engine, umm... well, he would have said that it was completely different and not a "sequel" of the engine at all, right?
heh. It reminds me of one of my favourite snl sketches--Chris Farley as a gigantic baby on 'the Sally show', with guest Tim Meadows as the author of "My God, These Enormous Children With Their Disproportionate
Strength and Inability to Logic Are Sure to Rise Up and Destroy Us"
Slashdot Mirror
Well duh, if the bugs are unexpected they can't be open. Also a lot of buggy programs are "free of bug reports." It doesn't mean much until final testing of the finished product (yes programs can be finished products, before the internet there were no monthly patches of shiatty programs). "Zero defects" of the "milestone" is more like "this part of the program is finished and works." If you start to introduce bugs into a finished part of the program, you're either not planning very well or just not programming very well.
you can just type it in at the ] prompt :)
1. It is possible to program a bug-free program.
2. Security is not an inherent issue with computing.
3. A program that does not work is not finished
4. Computers are made of 0's and 1's.
5. CODECs are temporary in the computer timeline.
6. x = 2 * y means something different in programming than in math.
any old-schoolers care to add some more?
And the question is: Why is security a problem?
PRINT "HELLO WORLD"
hahahahahah. nice!
Please let it be a joke.
Ever notice that people who would say "Dilbert is for losers" are the losers most often featured in Dilbert? Everyone else just doesn't get it.
I agree (except I have a huge problem with "zero-defect" but I won't get into it here). I'd just like to say about your question "how many possible inputs should you test?" and the answer is: every single one.
You, as the programmer, create the inputs. Therefore you know what they are and what they are for; you wrote them in. Therefore testing them is easy. There's no input without some sort of input statement in your program.
With a robust and highly modular application you can build as many features as you want into it. Each 'feature' should be as self-contained as possible. Global variables and objects are for amateurs (and me if I'm lazy). Like, if you ever see something like this x = myObject.someObject.somethingElse.setX(temp), then you know there's going to be trouble down the road.
This [is] a bug? The user reported it is a bug. Does that make it a bug? Is the software defective? Or is that a feature that needs coding?
No, it's not a bug.
No, it's not defective.
Yes, it is a feature that a customer requested.
The issue is not with the product, it is with the customer. It is a customer issue. The customer is requesting a new feature.
I'll have a go:
"Wouldn't it be nice if you could have more insight into the quality of a product, while it is developed, and not afterwards? Would you like to be able to estimate how many bugs are inserted in the product in a certain phase, and how effective a (test) phase is in capturing these bugs? To optimize your test phases regarding focus and effort in relation to how many bugs they will find? This presentation will show a simple but very effective model that makes it possible: The Project Bug Model. "
There you go, I just inserted "bug". It makes sense: Now it means "how to write buggy software and not give a ****".
Well, he might not but a developer, but I am and, guess what? I think you're an idiot! Bugs are defects. Zero defects means zero bugs. What the hell is a bug then if not a defect? A "thing we didn't think of because I've only been programming for 2 years and I got my degree at an online college and I'm too much of a career-script-kiddy-with-a-job to write code that doesn't break?" How about giving everyone else a break and stop covering your ass with "bugs aren't defects" corporate-bull-shiat-speak.
The widget is not fully working. It has bugs. But, in relation to milestone n, it has zero defects, i.e., it passes all of the tests for milestone n.
No, in the relation between the widget and milestone n, you get "ERROR: Variables are not of the same type."
Milestone = Bureacracy. Milestone has been completed.
The product, on the otherhand, is unfinished.
What's actually defective is the way you're thinking about it.
'...existing features pass all test cases' Means bug-free. Or don't you know what a bug is?
...it's perfectly valid for a game to use UDP and say that it's using TCP/IP.
...unless you're setting up your firewall. :P
I thought what was the same was that it is Doom 3. In other words, it is Doom, part 3. Didn't you watch the trailer? Those skull heads are from Doom. I thought Romero was talking about the plot and setting, not the game engine. If he was talking about the engine, umm... well, he would have said that it was completely different and not a "sequel" of the engine at all, right?
...pipe-bombs, lasers, vents you could shoot through, light switches, exploding holes in walls, secrets everywhere....
When I pre-ordered Half-life 2 from Amazon it was going to be out before Christmas... of 2003.
yes...and I look forward to the day of toiling in their underground sugar mines!
heh. It reminds me of one of my favourite snl sketches--Chris Farley as a gigantic baby on 'the Sally show', with guest Tim Meadows as the author of "My God, These Enormous Children With Their Disproportionate Strength and Inability to Logic Are Sure to Rise Up and Destroy Us"
You might want to read a little Ayn Rand
Just to add some balance, you may wish to read a little John Ralston Saul instead. At least he isn't running a cult...errr I mean institute.
nonono it's "Impressive!" :P
Nah, that'd just be excessive.
hehehehehe who got that?
Now if we could only figure out what causes Gulf War syndrome...