• (cs) in reply to C-Octothorpe
    C-Octothorpe:
    SIDENOTE: are there really people who WANT to test? I mean, speaking as a developer looking at the role of QA, it just doesn't seem all that appealing to me. I am not the smartest guy by far, but from my personal experience, QA tends to attract people with the intelligence levels reserved for the mildly retarded (I'd say in the neighbourhood of 100, give or take 10 pts).
    I should point out that in my experience, the few technically-inclined testers with whom I've worked were actually business analysts who also participated in requirements gathering and analysis, documentation, etc. In other words, the best testers seem to be more than just testers.

    Even better, they already had a good understanding of how the software was supposed to work when they went about their testing responsibilities.

  • rfoxmich (unregistered)

    Testing doesn't help at all if the underlying quality of the code is just bad (design flaws fragility etc);

    I'm reminded of my informal rule for live music: The quality of the band is inversely proportional to the number of sound checks they make.

  • (cs) in reply to Tim
    Tim:
    Even if you have coverage of 100% of the lines of code that doesn't mean you have covered 100% of the code paths.
    That's why there's a method of testing called "decision coverage" which is generally done in addition to code coverage.

    Decision coverage doesn't test every single input to a condition.

    What it does is test each possibility (true or false) for each decision, and shows that each input into that final "true or false" has an effect on the decision. Typically if you find an input to the Boolean expression has no effect on the Boolean it's an error of some sort. It also ensures that conditions which are supposed to be mutually exclusive are, in fact, exclusive.

    This way you test all outcomes rather than all possible ways to get that outcome. Of course, this testing is generally used in safety-critical applications where the main goal is safe operation, not some specific functionality; the goal of this testing is to ensure safe states due to (or at least gain a full awareness of the effects of) all decision paths.

  • (cs) in reply to Mr. Orangutan
    Mr. Orangutan:
    Alex Papadimoulis:
    no matter how hard you try, a definitive answer is impossible. At best (i.e., with unlimited resources), you can be 99.999…% confident that there will be no defects in production
    but but 99.999...% IS 100%

    Congratulations, you've found the limit! You see, pendantry can also work against you.

  • VoiceOfSanity (unregistered) in reply to Mr. Orangutan
    Mr. Orangutan:
    Alex Papadimoulis:
    no matter how hard you try, a definitive answer is impossible. At best (i.e., with unlimited resources), you can be 99.999…% confident that there will be no defects in production
    but but 99.999...% IS 100%
    Not really. Let's say you've got a software package that depends on the clock being accurate. But as most folks know, computer clocks are not always that reliable, so that unless you've compensated for that in the program, you will get errors that eventually magnify to the point of failure.

    So while the clock might be 99.999% correct, it's that 0.001 that causes an error and leads to a failure of the equipment tracking an incoming Scud missile to hit the target... which lead to the death of 28 service members. Look at http://www.ima.umn.edu/~arnold/disasters/patriot.html for more information.

  • Mr. Orangutan (unregistered) in reply to VoiceOfSanity
    VoiceOfSanity:
    So while the clock might be 99.999% correct, it's that 0.001 that causes an error...
    99.999% != 99.999...% 99.999... implies the repeating 9 ... as we all should know, 0.999... = 1 therefore, 99 + 1 = 100

    next time i'll just leave my snarky comments to myself ... i'm out of orange crayons, and besides they're obviously not appreciated

  • (cs) in reply to Jon
    Jon:
    I'm throwing a WtfNotFunny exception.
    catch (WtfNotFunnyException wtf) { System.log(wtf); } finally { with (Mood.grumpy) { Activity.returnTo(previousActivity); } }
  • Wonk (unregistered)

    Clearly QA people are not monkeys. They are baboons: http://www.newtechusa.com/ppi/talent.asp

  • Ton (unregistered) in reply to Machtyn
    Machtyn:
    I would like to sub scribe to this the ory about never leaving the house to avoid getting hit by a bus.

    I have some problems with that theory. The main one being that it is crap...

    http://cache3.asset-cache.net/xc/3176763.jpg?v=1&c=IWSAsset&k=2&d=77BFBA49EF878921F7C3FC3F69D929FDC3F7A0BDA4B902D54AE2144BAD5428282D78032B8FE88392A7CFF610D5B4FC25

  • trtrwtf (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    SIDENOTE: are there really people who WANT to test? I mean, speaking as a developer looking at the role of QA, it just doesn't seem all that appealing to me. I am not the smartest guy by far, but from my personal experience, QA tends to attract people with the intelligence levels reserved for the mildly retarded (I'd say in the neighbourhood of 100, give or take 10 pts). This usually results in people three kinds of QA monkeys:

    If you treat testing as a sort of janotorial function, one which I suppose we need but the people we hire to do it aren't really people, not like you and me, we can get it done for cheap by hiring a few interns from the local community college and making the low coder on the totem pole supervise them - well, in that case you get what you deserve, and that's dribbling idiots who can follow a script and that's about it.

    Same with documentation - if you hire the lowest-cost warm body who can possibly be expected to do the job, you can maybe hope for something that's not very embarrassing.

    Imagine if you hired coders that way - oh, wait. Some people do, and that's why this site exists.

    1) The new grad/career switch above-average smart person trying to get into software development. Some people take this path, which is fine, and in some corps a necessary step...

    1. The shitty, change resistant x-developer who couldn't hash it anymore and (in)voluntarily goes into QA. This is more rare as pride usually takes over and they just quit and f*ck up another dev shop with their presence.

    2. The mildly retarded sociopaths who don't have the intelligence or social skills necessary to make it in any other role IT related. They may be able to make something of themselves in another profession, but because they got mad skillz at Halo, they MUST be good at everything IT related, which keeps them in the QA gig.

    I realize this sounds very elitist, which isn't my intention but this is just what I have noticed/pondered...

    Yeah, if you assume that testing doesn't matter, this is what you'll end up with.

    (by the way, IQ 100 is by definition normal - calling people with definitionally normal IQ is, I suppose as clearly elitist as you could get and still be a commoner)

  • (cs) in reply to QJ
    QJ:
    If a seemingly simple change can bring down the entire system, there's something fundamentally wrong with that system and it's ripe for a bit of guerrilla refactoring.
    Alex was talking about change impact. A seemingly simple change could bring down the entire system; the risk is small, but you need to consider the scope of the change you are making.

    Refactoring has a much larger change impact, since it typically touches so much more of the codebase. While my customers certainly don't mind paying shit tons extra to risk breaking their already-working software for no functional benefit, I'm just not too keen on all the extra testing I'd have to do.

  • Fred (unregistered) in reply to rfoxmich
    rfoxmich:
    I'm reminded of my informal rule for live music: The quality of the band is inversely proportional to the number of sound checks they let you see them make.
    FTFY.
  • MadJo (professional software tester) (unregistered)

    Ah, great a testing article written by a developer. (I kid, it's a good article, but I do want to leave a few notes, if you don't mind)

    Testing is done to ensure that the application that's built adheres to the design specifications and business requirements. That doesn't mean fully bug free. So indeed, 'adequate' not 'complete'.

    Someone designs the application, preferably using a standard like UML or something like that, and have the team review it.

    Then someone else develops the application, based on said designs.

    And you get someone else to test said application, with scripts based on the initial documentation, scripts that are reviewed by the team working on the project, written with a standard methodology, like ISTQB or TMAP Next, so that you can ensure the quality of the tests themselves.

    Using this set up, you can be reasonably sure, based on the depth of the used test-techniques, and the used testdata, that there won't be any show stopping bugs (in the specified functionality), and perhaps only minor bugs (again only in the known specified functionality). And with the reviews you'll have closed the "who guards the guardians" gap as well.

    This takes time, money and effort, and not every project has that in abundance (more often than not it lacks the time and resources to fully commit to it, but then you appoint key stakeholders that make time to do a basic review)

    And you can then choose to only really put a lot of effort on the stuff that's critical, those priorities are set by the client, not a developer or a tester, but a client.

    No risk, very little (or no) test.

    On the flipside: no documentation, also no test. If a developer creates a lot of extra (perhaps handy) stuff, but it isn't designed in the specs, how is the tester to know what that functionality does? So, often the choice is made not to test that (or only very rudimentary test, does it do something that isn't terribly bad like lock stuff up?). Unless design specs are written up, and it can be incorporated into the test. Then it will be tested more thoroughly.

    A few extra (and perhaps personal) notes:

    For me as a tester, AGILE development schemes doesn't make a lot of sense, as it can cause a lot of headache, trying to keep track off the changes in the documentation. Moving targets aren't fun if you have to make hundreds of testcases, and the specs change by the day. Especially since testings is almost always done on the critical path, it often makes a very tight rope to do the foxtrot on.

    And you NEVER let a developer test his own stuff, because it'll be hard get a grip on the quality in that case. No one is truly really critical on his or her own creations. "Oh, I know what I mean there. I'll just leave it in." (also testers shouldn't review their own testcases, let someone else do that)

  • Steve (unregistered)

    Arghh the sad depressing sight of developers not getting testing.

    Testing is "A technical investigation done to expose quality-related information about the product under test" (Kem Caner http://kaner.com/)

    What most of you think of testing, is in fact just checking. You don't write unit tests, you are writing unit checks. Thinking about what you need to check, which code paths are relevant, which are not is the testing bit. Writing unit checks is just another thing devs need to learn. (for a better & longer explanation http://www.developsense.com/blog/2009/08/testing-vs-checking/ )

    Far too many developers are just not intellectually suited to doing testing, just as testers are not suited to doing development. That does not mean it is easy.

    I work very closely with my devs, I review their "unit tests", they help me with my automation when needed. Doing this we eliminate a huge chunk of defects at design time. This frees up my time to do the exploratory testing that finds the bug that happen only on certain pre-conditions that would never be found by code coverage.

  • JadedTester (unregistered) in reply to MadJo (professional software tester)
    MadJo (professional software tester):
    For me as a tester, AGILE development schemes doesn't make a lot of sense, as it can cause a lot of headache, trying to keep track off the changes in the documentation. Moving targets aren't fun if you have to make hundreds of testcases, and the specs change by the day.

    That's why you can use a checklist instead of test cases. Or, gasp, carry out exploratory testing. Or use BDD. Etc, etc. Did the entire context driven movement pass you by?

  • Kraagenskul (unregistered) in reply to SpasticWeasel

    Plato is first credited with asking the question in his "The Republic", but the Latin is definitely Juvenal.

  • James Emerton (unregistered)

    Unit Testing is the process of testing a very specific bit of code. Proper unit testing involves mocking out database or file access and testing the operation of a specific class or function.

    Integration Testing tests the full (integrated!) stack of code, such as you might find in a normal runtime. Integration tests will write to the database or filesystem, and as such they are expected to take more time to run than unit tests.

    Unfortunately, there is much confusion surrounding this issue, even among developers. Perhaps this is due to the fact that testing frameworks often have the word "Unit" in their name, in spite of the fact they can be usually applied to any sort of automated testing.

  • Sanity (unregistered)
    Who cares if the there’s 100% code coverage when a unit test has a defect in it? Or if the requirements were misunderstood by the developer? Or if the requirements were wrong? Or if it’s not PCI compliant? Or if it breaks when it gets deployed to production?

    Because, quite frequently, tests are a good place to start when reading the code, and a good way to specify, or at least closely track, whether the code actually conforms to the specifications.

    Then, when things go wrong, you have the test framework as an entire other way to figure out what's going on.

    Also because doing it this way (particularly with unit tests) forces you to design for testability, and such a design has other benefits. Generally, when you need to fix a bug (or "correct a defect," if you like), it's extremely helpful to be able to easily isolate the problem into one small test case. Even if you haven't written the particular test that should fail in this case, it's a lot easier to do if your code has been forced to be testable. And of course, if you do write a failing test, you now have a regression test for when you actually fix it, and a useful tool for the process of fixing it.

    I agree that the real goals should be, well, the real goals. If the choice is between 100% test coverage and being able to deploy to production without breaking things, that's a no-brainer -- tests are a tool to make your program work, but clearly the goal is to make your program work. I just wanted to point out why, if you do suddenly find a really serious defect (like not being able to deploy to production), generally, the more comprehensive your test suite, the better off you are.

    Also:

    it’s not really a problem if Father Cronin needs to type in “ ” for a line break (it probably isn’t even worth your bill rate to fix that defect),

    I guess that's TRWTF, because this makes me weep for my profession. It's not really a problem either if the parishioners need to duck because the door to the church is too low, but I would fix it anyway out of sheer embarrassment -- how hard is it to get this right?

    I understand that Father Cronin doesn't need five nines for his database, and maybe we don't have to care about Unicode support, but there's a difference between a tricky-but-obscure defect that's not worth fixing and having some pride in your craft.

  • (cs)
    A little more than a year ago, I was in the market for kitchen appliances and had a pretty good idea of what I could get with my budget. It wasn’t a whole lot, but then again, neither was my budget.
    These sentences brought to you by the department of redundancy department, which is the department that brought them to you.
  • C-Octothorpe (unregistered) in reply to trtrwtf
    trtrwtf:
    C-Octothorpe:
    SIDENOTE: are there really people who WANT to test? I mean, speaking as a developer looking at the role of QA, it just doesn't seem all that appealing to me. I am not the smartest guy by far, but from my personal experience, QA tends to attract people with the intelligence levels reserved for the mildly retarded (I'd say in the neighbourhood of 100, give or take 10 pts). This usually results in people three kinds of QA monkeys:

    If you treat testing as a sort of janotorial function, one which I suppose we need but the people we hire to do it aren't really people, not like you and me, we can get it done for cheap by hiring a few interns from the local community college and making the low coder on the totem pole supervise them - well, in that case you get what you deserve, and that's dribbling idiots who can follow a script and that's about it.

    Same with documentation - if you hire the lowest-cost warm body who can possibly be expected to do the job, you can maybe hope for something that's not very embarrassing.

    Imagine if you hired coders that way - oh, wait. Some people do, and that's why this site exists.

    1) The new grad/career switch above-average smart person trying to get into software development. Some people take this path, which is fine, and in some corps a necessary step...

    1. The shitty, change resistant x-developer who couldn't hash it anymore and (in)voluntarily goes into QA. This is more rare as pride usually takes over and they just quit and f*ck up another dev shop with their presence.

    2. The mildly retarded sociopaths who don't have the intelligence or social skills necessary to make it in any other role IT related. They may be able to make something of themselves in another profession, but because they got mad skillz at Halo, they MUST be good at everything IT related, which keeps them in the QA gig.

    I realize this sounds very elitist, which isn't my intention but this is just what I have noticed/pondered...

    Yeah, if you assume that testing doesn't matter, this is what you'll end up with.

    (by the way, IQ 100 is by definition normal - calling people with definitionally normal IQ is, I suppose as clearly elitist as you could get and still be a commoner)

    My bad, I didn't realize 100 was normal (I thought 110 or 115 was), so you can keep your vitriol...

    Either way, I'm not disagreeing with you or the whole concept of testing. It is very necessary, however what I was attempting to illustrate is that it is often grossly underrated by management and other key decision makers. This results in conditions outlined in my rant (mouth-breathers going through 'Test Case 43, Steps 1-8'). They are usually only slightly more tech savvy (i.e. setup router) than your average person.

  • Clockwork Orange (unregistered)

    Alex's Soapbox was what made The Daily WTF a keeper. Sadly, we don't get enough of these insightful articles.

    Keep 'em coming, Alex?

  • I Push Pixels (unregistered) in reply to Anonymous

    Depending on where you are, it may be the organization itself that prevents the testers from acting like they know what they're doing.

    As a former tester, I've been on both sides of the equation, and I have been in situations where the lead tester demanded that we stick to the test script, icebergs (and crashes!) be damned, and as a coder, I have talked to the testers and found out, surprise, surprise, many of them have a pretty good idea of what's happening under the hood (even if only from a layperson's perspective), but alas, they've been instructed, on pain of death, to stick to the script and keep their bug reports non-technical.

    I came from the game industry, which is frequently a massive worse-than-failure unto itself and goes out of its way to perpetuate animosity between the engineers and the testing staff, so things may be different.

  • I Push Pixels (unregistered) in reply to I Push Pixels

    That was in regard to the 'qa monkey' comment.

  • Sobriquet (unregistered) in reply to trtrwtf
    trtrwtf:
    (by the way, IQ 100 is by definition normal

    No, the distribution of IQ is normal. 100 is the expected value.

    - calling people with definitionally normal IQ [retarded] is, I suppose as clearly elitist as you could get and still be a commoner)

    I can't be a commoner... not when I'm a citizen of imperialist America.

  • SalukiJim (unregistered)

    How about the REAL WTF here. A company I worked at let all of its testers go, leaving only the actual devs to test. When you ask a dev to test (self included), we have "blinders" on for the list of possible ways to break something...And to this day there is no dedicated test dept. In an IT dept of 40-50 devs, not mom & pop and the chimp :)

  • (cs) in reply to Sanity
    Sanity:
    it’s not really a problem if Father Cronin needs to type in “
    ” for a line break (it probably isn’t even worth your bill rate to fix that defect),

    I guess that's TRWTF, because this makes me weep for my profession. It's not really a problem either if the parishioners need to duck because the door to the church is too low, but I would fix it anyway out of sheer embarrassment -- how hard is it to get this right?

    I chose that example because it's relatively easy to forget to add .Replace("\n", "
    ")     when outputting HTML, and it's something I'm sure we've all done. While that example is trivial to fix, there are plenty of defects that are neither the builder's nor the client's fault, and that are not trivial to fix (let's say, a full week of time).

    The onus is on the party that assumed the risk of the unknown. If it's a "fixed bid" agreement, then it's the professional obligation of the builder to fix and deliver the promised results. But if it's a "time and materials" agreement, the client has to pay to fix it. If they don't think it's worth 40 hours to fix it, even the most dedicated crafstman will not give up a full week just to have a better craft.

  • trtrwtf (unregistered) in reply to C-Octothorpe

    [quote user="C-Octothorpe"] My bad, I didn't realize 100 was normal (I thought 110 or 115 was), so you can keep your vitriol...

    No vitriol intended. Just pointing out that there was a place where you were clearly being elitist. Unintentionally, as it turns out.

    I agree with you on the symptoms, and it sounds like you agree with me on the cause. No fuss, no bother.

  • (cs) in reply to Zelda
    Zelda:
    programmers use all their salary to buy dates

    They call them hookers in these parts...

    Anyway I thought this was the daily wtf, not slashdot.

  • (cs)

    What??? Did Alex become Jeff (Atwood) overnight?

  • clive (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    SIDENOTE: are there really people who WANT to test?

    Have a look at James Bach's stuff - there's a man who wants to test, and appears to be quite good at it.

  • нагеш (unregistered)
    Alex Papadimoulis:

    It’s been a rough couple weeks. Not only did I have all sorts of catching-up to do after Code PaLOUsa, but it also happened to be release week. And oh, do I hate release week.

    And apparently, you also died and coped with alcoholism, at the same time.

  • (cs) in reply to neminem
    neminem:
    Tim:
    In fact, since the number of code paths through the entire code base grows exponentially you have covered some vanishingly small percentage of the code paths.
    I'd argue anytime your input comes from the user or from another system you have no control over the output of, you've covered exactly 0%. A finite fraction of an infinite is, after all, precisely nothing. (We once found a major blocking bug in a process iff the text input to the process started with a lowercase 'p'. That was a fun one.)

    But I'm happy to work at a computer that distinguishes between devs and testers; we certainly are responsible for testing the effects of our own code before checking in changes (that would be your #1), but the "test team" consists of people that were hired for that purpose. I sort of thought it was like that everywhere (well, everywhere where the whole company isn't a couple devs.)

    I recently came across one where a database was happy to store the string "\0\0\0test" when almost nothing else in the environment saw it as anything but an empty string. Good luck writing a unit test for that one before you encounter it...

  • (cs) in reply to C-Octothorpe
    C-Octothorpe:
    SIDENOTE: are there really people who WANT to test? I mean, speaking as a developer looking at the role of QA, it just doesn't seem all that appealing to me. I am not the smartest guy by far, but from my personal experience, QA tends to attract people with the intelligence levels reserved for the mildly retarded (I'd say in the neighbourhood of 100, give or take 10 pts). This usually results in people three kinds of QA monkeys:

    1. The new grad/career switch above-average smart person trying to get into software development. Some people take this path, which is fine, and in some corps a necessary step...

    2. The shitty, change resistant x-developer who couldn't hash it anymore and (in)voluntarily goes into QA. This is more rare as pride usually takes over and they just quit and f*ck up another dev shop with their presence.

    3. The mildly retarded sociopaths who don't have the intelligence or social skills necessary to make it in any other role IT related. They may be able to make something of themselves in another profession, but because they got mad skillz at Halo, they MUST be good at everything IT related, which keeps them in the QA gig.

    I realize this sounds very elitist, which isn't my intention but this is just what I have noticed/pondered...

    I did testing for Xbox 360 games for a year. I loved it, absolutely loved it, and the developers loved me because (since I loved it) I found a ton more bugs than the drooling morons who are usually in that position. And I daresay I'm pretty goddamned good at it.

    The problem is that there's no career in it. The only way to make a career in QA is to move up into management, where instead of actually testing the software, you do nothing but herd the drooling morons around.

    If you're a developer, you generally can work an entire career while still developing software; that doesn't exist in QA.

  • phew (unregistered) in reply to QJ
    QJ:
    frits:
    The 100% code coverage metric is so dumb. Have these people never heard of permutation? I assume that 100% of the code is tested at least informally. I mean do some developers really write code that they've never run before releasing it?

    In some of the places I've worked I've had to opine that it would be nice if the developers checked whether their code actually compiles in the first place.

    No shit. We have about 450 build targets in the automated build system. About a dozen are currently broken. And often it's obvious the code couldn't compile. (In theory, everything is supposed to be peer-reviewed too)

  • (cs) in reply to frits
    frits:
    Mr. Orangutan:
    Alex Papadimoulis:
    no matter how hard you try, a definitive answer is impossible. At best (i.e., with unlimited resources), you can be 99.999…% confident that there will be no defects in production
    but but 99.999...% IS 100%

    Congratulations, you've found the limit! You see, pendantry can also work against you.

    100% confidence is not 100% certainty. You could be 100% confident and 100% deluded.

  • JB (unregistered) in reply to The Ancient Programmer
    The Ancient Programmer:
    Ed:
    Someone needs to explain that last bit to my boss. Badly.

    Why explain it to him badly?

    No, see, his boss is called "Badly". Like "Joe", or "Ed".

  • JB (unregistered) in reply to Mr. Orangutan
    Mr. Orangutan:
    (snip) 0.999... = 1 therefore, 99 + 1 = 100

    So, a = b therefore c + b = d?

    You see, pendantry can also work against you.

  • anon#213 (unregistered)

    I thought the wtf was the fridge being too short. That small amount of useless space would drive me crazy.

  • trtrwtf (unregistered) in reply to anon#213
    anon#213:
    I thought the wtf was the fridge being too short. That small amount of useless space would drive me crazy.

    Your pretty easily driven crazy, aren't you?

  • trtrwtf (unregistered) in reply to anon#213
    anon#213:
    I thought the wtf was the fridge being too short. That small amount of useless space would drive me crazy.

    Your pretty easily driven crazy, aren't you?

  • C-Octothorpe (unregistered) in reply to trtrwtf
    trtrwtf:
    anon#213:
    I thought the wtf was the fridge being too short. That small amount of useless space would drive me crazy.

    Your pretty easily driven crazy, aren't you?

    Your pretty easily driven crazy, aren't you?

  • C-Octothorpe (unregistered) in reply to trtrwtf
    trtrwtf:
    anon#213:
    I thought the wtf was the fridge being too short. That small amount of useless space would drive me crazy.

    Your pretty easily driven crazy, aren't you?

    Your pretty easily driven crazy, aren't you?

  • C-Octothorpe (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    trtrwtf:
    anon#213:
    I thought the wtf was the fridge being too short. That small amount of useless space would drive me crazy.

    Your pretty easily driven crazy, aren't you?

    Your pretty easily driven crazy, aren't you?

    let's watch and see what happens...

  • anon#213 (unregistered) in reply to trtrwtf
    trtrwtf:
    anon#213:
    I thought the wtf was the fridge being too short. That small amount of useless space would drive me crazy.

    Your pretty easily driven crazy, aren't you?

    DAMMIT ITS "YOU'RE", NOT "YOUR"!!!!!!!

  • Mr. Orangutan (unregistered) in reply to JB
    JB:
    Mr. Orangutan:
    (snip) 0.999... = 1 therefore, 99 + 1 = 100

    So, a = b therefore c + b = d?

    You see, pendantry can also work against you.

    Okay, so I skipped a step that I thought should have been obvious to the casual reader here.

    So, if A = 99 and B = 0.999..., then A + B = 99.999... (the original). Since 0.999... = 1, B = 1, thus 99.999... = A + B = 99 + 1 = 100

  • trtrwtf (unregistered) in reply to anon#213
    anon#213:
    trtrwtf:
    anon#213:
    I thought the wtf was the fridge being too short. That small amount of useless space would drive me crazy.

    Your pretty easily driven crazy, aren't you?

    DAMMIT ITS "YOU'RE", NOT "YOUR"!!!!!!!

    Thanks, C-Octo. I owe you a beer. (I love to see them pop like that)

  • Mr. Orangutan (unregistered) in reply to JB
    JB:
    Mr. Orangutan:
    (snip) 0.999... = 1 therefore, 99 + 1 = 100

    So, a = b therefore c + b = d?

    You see, pendantry can also work against you.

    And for the record, I wasn't being pedantic .. I was being snarky ... and now I'm going to be sardonic ... it's "pedantry" not "pendantry"

  • (cs) in reply to Matt Westwood
    Matt Westwood:
    frits:
    Mr. Orangutan:
    Alex Papadimoulis:
    no matter how hard you try, a definitive answer is impossible. At best (i.e., with unlimited resources), you can be 99.999…% confident that there will be no defects in production
    but but 99.999...% IS 100%

    Congratulations, you've found the limit! You see, pendantry can also work against you. <==lol. I Muphryed that one.

    100% confidence is not 100% certainty. You could be 100% confident and 100% deluded.

    Wrong kind of confidence.

  • нагеш (unregistered) in reply to Machtyn
    Machtyn:
    I would like to sub scribe to this the ory about never leaving the house to avoid getting hit by a bus.

    You still run the risk of an airplane crashing through your roof, or heck, a bus running through your front door. Maybe Nagesh and his taxi will let themselves in.

  • Darth Kaner (unregistered)

    I have tested your software. Pray I do not test it any further.

Leave a comment on “Testing Done Right”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article