• Phlip (unregistered) in reply to Brendan Kidwell

    The problem wasn't the messages were terse. The problem was the manual tester couldn't figure out a way around them. They were a symptom of a show-stopper bug.

    The developers must have memorized a sequence of specific keystrokes, and ran these over and over again, to get back to the point in the code where they were developing.

  • (cs) in reply to keith ray

    Anonymous Bob said:

    Woah, did the forum software just misinterpret those at-signs as being e-mail addresses?  This may be one of the coveted Self-Referential WTFs...
    ----

    Yes, the regexp was something like \ .@.  wich is to simple even for this forum.

  • Rob (unregistered) in reply to Dave

    Do NOT use regular expressions to validate email addresses, unless you are CERTAIN that your regular expressions catch ALL possibilities.  For example, http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html

    It's much easier and safer to validate that there's an @ in it.

  • (cs) in reply to lrb
    lrb:
    "Since the program knows what is incorrect about the date, it should tell the user, instead of leaving it up to him or her to figure out."

    The problem is that the program doesn't always know what is wrong with the date.

    Actually it does.  The program doesn't know what date the user is trying to enter, but since the program has in fact rejected the attempt, it certainly knows at some level why it is being rejected.  This reason may or may not match up with the user's intention, of course, but as I read the original memo to the developers, they are being asked to display that reason, not what the user should do about it.  Now, whether or not that reason has been passed up the stack to the interface level instead of just the simple "PASSED/FAILED" status being returned has to be taken into consideration, but I can certainly see why the customer would want to see that data.

    I see no excuse for holding up testing, though.

  • (cs) in reply to James Boxer
    Anonymous:

    Obviously, this testing team would like an alert to pop up... informing the user...




    umm... under windows XP... it even tells u 'Network cable unplugged'.... see... Microsoft CAN get one thing right.
    but lets leave it there.
  • (cs) in reply to Gene Wirchenko
    Gene Wirchenko:
    Apparently, text in matched parens is permitted as comments.  The comments are ignored but are part of a valid E-mail address.  Matching parens can not be done with regexes.

    Matching nested parens cannot be done with regexes (actually, only arbitrary-depth nesting; if there's a finite upper bound on the nesting depth, it's okay) -- I thought this meant you were wrong, because WTF would they allow comments to be nested? But then I checked the RFC at http://www.ietf.org/rfc/rfc0822.txt?number=822 and found (section 3.4.3):
    Comments nest, so that if an unquoted left parenthesis  occurs
    in a comment string, there must also be a matching right
    parenthesis.
    Sigh.  So...

    foo(blah) [email protected] is valid and equivalent to [email protected]
    foo((blah) bar)@domain.com is valid and equivalent to [email protected]
    foo((blah) [email protected] is invalid

    (the last two being the opposite of how C-style slash-star comments work).

    The only reason I can think of for them to have specified this behavior is if they specifically wanted to make it impossible to validate addresses with a regex. We might even conclude that (drumroll)...

    The real WTF is RFC0822, section 3.4.3!

  • raj (unregistered) in reply to Dave

    While it'd be nice to trap for all invalid emails, it's not that easy, or worthwhile. For example, how could you possible trap "[email protected]" as an erroneous email address. This is why many web forms have you type in your email address twice. Because doing so usually makes you realize if you typed it in incorrectly the first time.

    The date thing is a problem. When I work with clients, I ask them how deep the date-checking abilities should go, then give them what they ask for.

  • (cs)

    I don't see the problem here with the testers' comment about ambiguous error messages with dates, although he/she has gone a little too far in-depth of what kind of message should be displayed.
    There's a difference between "The value you have entered is in an invalid format.  Dates should be entered in the format MM/DD/YYYY." and "The date you have entered is invalid.".
    That's not exactly saying "There are not 30 days in February.", it's simply letting the user know that the error is in the date itself, not the format in which they have entered it.

    As for email addresses, I think the only checking should be that it contains a single @ symbol and does not contain invalid characters such as a colon or semicolon.  There are many formats an email address may take, but they are the general rules which all must adhere to.

  • StuperGenius (unregistered) in reply to ammoQ

    Man.  Haven't you ever heard of loop back email validation. 

  • (cs) in reply to Mike K.

    Bug Report:

    Our testers tried clicking everywhere for about 20 minutes and only saw the same black screen.  Luckly a tech guy walked passed, and told us to turn on the computer, or we would have been stuck for hours. 

    This will be very confusing to users...if someone tries to use the mouse for more than a moment or two when the computer is off, please print an error message to the screen that tells them to turn it on and where the switch is. 

    We need this resolved so we can continue with testing.

  • Jeremy Lakeman (unregistered) in reply to paddy

    Any error displayed to the user based on invalid form input should as a minimum contain:

    Which field(s) is in error, or be displayed immediately when leaving that field

    Precisely what the application is looking for.

    "The date entered is not valid. Dates must be entered in the MM/DD/YYYY format." seems ok though I wouldn't word it that way.

    "The email entered is not valid." is not a *good* error message since it doesn't describe what the application requires of the user. Though I would expect any vaugly internet savy user to know what an email address should contain.

  • Ben (unregistered) in reply to Mike K.

    This QA guy is pretty reasonable.  I've dealt with a QA team that would have halted a round of QA on the date bug.  Then two days later they would halt the second round after encountering the email 'bug'.  Their justification was that once a show-stopper was found all testing would stop.  It's like an editor rejecting a manuscript one line at a time.

    One IT fellow we outsourced to rejected a spreadsheet I emailed saying 'the value in this cell should be in the format AM99999 and not AK99999.  If he was in the same room I would have strangled him.

  • awfwaf (unregistered) in reply to paddy
    paddy:
    Bug Report:

    Our testers tried clicking everywhere for about 20 minutes and only saw the same black screen.  Luckly a tech guy walked passed, and told us to turn on the computer, or we would have been stuck for hours. 

    This will be very confusing to users...if someone tries to use the mouse for more than a moment or two when the computer is off, please print an error message to the screen that tells them to turn it on and where the switch is. 

    We need this resolved so we can continue with testing.
    I've had stuff like that.
     
    "When using application, my computer's monitor should never turn off." - Uh, OK.  What if you turn off the monitor by unplugging it?
     
  • nimrand (unregistered) in reply to Mike K.

    Regular expressions CANNOT validate matching parenthesis (or matching symbols of any kind) where the number of left-hand symbols must match the number of right-hand.  Its mathematically proven.  Now, some implementations of regular expressions (such as .NET) have EXTENSIONS that do allow you to validate them correctly, but regular expressions by themselves cannot do it.  There is a whole area of study called Formal Language Theory that studies these kinds of things.

  • awfwaf (unregistered) in reply to nimrand
    When I get really ridiculous feedback like this, I just give them an even, fair response.
     
    For both of them, I would explain that the way validation is done is to check for the correctness of a value, not to go through a bunch of "incorrectness" routines.  This is done because there are far too many conditions for incorrectness.  Therefore, if you want to have very specific error messages for all sorts of conceivable invalid data, that would add considerably to the cost of a system.
     
    I would then list them about 20 examples of invalid data that they didn't think of that would result in different error messages.
     
     
  • awfwaf (unregistered) in reply to nimrand
    Anonymous:

    Regular expressions CANNOT validate matching parenthesis (or matching symbols of any kind) where the number of left-hand symbols must match the number of right-hand.  Its mathematically proven.  Now, some implementations of regular expressions (such as .NET) have EXTENSIONS that do allow you to validate them correctly, but regular expressions by themselves cannot do it.  There is a whole area of study called Formal Language Theory that studies these kinds of things.

    Wait a second.  So you're telling me that someone out there added these things... called extensions...  to regular expressions...  that give regular expressions the ability to match parentheses...  So that means that regular expressions can in fact, match parentheses?
  • b00nbuster (unregistered) in reply to awfwaf

    The real WTF here is, that they did not use comboboxes as inputwidgets for dates.

  • (cs) in reply to emurphy
    emurphy:
    In the last system I wrote, the users wanted to be able to enter in a date in a textbox with either a date picker or just by typing. It wasn't because they were advanced users. It's because they wanted "options," maybe dependent on whether they were in a clicking or a typing mood. Sounds stupid, but if they are paying the bills...


    This is actually a valid requirement. Sometimes, you are just entering an already fixed date (e.g. the expiry date of incoming goods). Doing that with a date picker is cumbersome. In other cases, you are selecting a date, where the calendar-like view of a date picker helps you to see the weekday, week number etc. of a given date.
  • John Hensley (unregistered) in reply to awfwaf
    Anonymous:
    Wait a second.  So you're telling me that someone out there added these things... called extensions...  to regular expressions...  that give regular expressions the ability to match parentheses...  So that means that regular expressions can in fact, match parentheses?

    Talk about ridiculous feedback.

  • (cs)

    Dear -- Name Withheld --,

    Adding the level of error checking you require - which is not in the current specs -- would roughly double the application size, development time and, of course, the price. If these figures are ok with you, please drop by one of these days to sign the new contract.

    Regards,
    Sridhar

  • (cs) in reply to awfwaf
    Anonymous:
    "When using application, my computer's monitor should never turn off." - Uh, OK.  What if you turn off the monitor by unplugging it?
     


    One useful skill in IT is to learn to translate from what users say to what they probably mean.  In this case, the user probably means "while this application is running, the screen saver should be disabled".

  • Tony (unregistered) in reply to awfwaf
    Anonymous:
    Wait a second.  So you're telling me that someone out there added these things... called extensions...  to regular expressions...  that give regular expressions the ability to match parentheses...  So that means that regular expressions can in fact, match parentheses?


    If you want to go ahead and read up on regular expressions, and the finite automaton that are used to recognize them, and then read up on context-free grammars and the push-down automata that recognize them, well, that would probably enlighten you a little bit more about how you're talking out your ass.

    By definition, regular expressions CAN NOT recognize matching parens.  If there are some extensions somewhere to regexes that can, well fine.  But that doesn't generalize to the entire class of languages considered to be regular.  Really, if someone were to be able to recognize them using DFA, then they would have broken Chomsky's hierarchy of grammars.  That'd be awesome, but I don't think that's likely.

    Tony

  • Sven (unregistered)

    Guys, you are missing the point here! The real WTF is not the program but the client who tested it! Seriously, does an error message really need to be that specific ("Duh, you've entered three @ signs but an email address can only take one")?! While the date validation could really be a bit more specific, I think that the email validation is sufficient. Well, I don't want to see the code of an AI validation algorithm which explains the error in very detail.

    So the real WTF is that the client is whining about minor problems and thus stops testing.

  • (cs) in reply to raj
    Anonymous:
    ...This is why many web forms have you type in your email address twice. Because doing so usually makes you realize if you typed it in incorrectly the first time...

    Does anyone actually type the email address twice??? WTF???
  • (cs)

    How hard is it to add specific tests for some specific, common data entry errors, and return a more appropriate text string?

    It doesn't have to be absolutely comprehensive, but it should be able to identify some of the most common problems.

    Test for non-numeric input in the date ("Date must be numeric").  Test for out-of-range inputs ("Entered date of February 29, 2005 does not exist" ... clearly the application is already doing this check, but not returning a descriptive return code.).  Other errors (e.g. month of "0", or multiple such errors), "Invalid date.  Use format MM/DD/YYYY")

    Similarly for email.  Check for illegal characters.  Check for the absence, or multiplicity of "@" characters.  The absence of anything before (or after) the "@".  ("@ cannot be first or last character.")

    After the "simple" checks are passed, more general checks (with more generic error codes) can proceed.

    The code is obviously checking for certain errors before proceeding.   I wouldn't expect it to describe every possible error, but data validation should do better than a binary result.

  • (cs) in reply to Sven
    Svennis:
    Guys, you are missing the point here! The real WTF is not the program but the client who tested it! Seriously, does an error message really need to be *that* specific ("Duh, you've entered three @ signs but an email address can only take one")?! While the date validation could really be a bit more specific, I think that the email validation is sufficient. Well, I don't want to see the code of an AI validation algorithm which explains the error in very detail.

    So the real WTF is that the client is whining about minor problems and thus stops testing.

    :) This post made my day :)

    (Or was it meant to be serious??? WTF?!?!?)
  • Screaming Asshole (unregistered) in reply to Dave

    Townsend? You fag.

  • (cs) in reply to impslayer
    impslayer:
    Anonymous:
    ...This is why many web forms have you type in your email address twice. Because doing so usually makes you realize if you typed it in incorrectly the first time...

    Does anyone actually type the email address twice??? WTF???


    Some forms get clever and prevent you from pasting text into those boxes.

  • Sven (unregistered) in reply to Coughptcha

    Yes, my post was deadly serious! It looks like the program already does the most important checks for date and email validation. I am not saying that you should not do validation, but I also think that you should not explain every possibility of mistyping an input in enormous detail.

    Pseudo code:

    if not email.validate()
    {
      ShowMessage( "Email does not match pattern [email protected]");
    }

    is fine with me!

  • (cs) in reply to Rob
    Anonymous:
    Do NOT use regular expressions to validate email addresses, unless you are CERTAIN that your regular expressions catch ALL possibilities.  For example, http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html

    It's much easier and safer to validate that there's an @ in it.

    Of course, that doesn't do any kind of meaningful validation. And would have let through the invalid mail address the testers used (the one with all the @ in), but blocked the valid one (which was all A's).

    So, ummm. WTF?

    And to the guy who claimed you can't match paired brackets with regexps, you're wrong. It's arbitrary levels of nested brackets that cause problems.

    Simon

  • (cs) in reply to Sven
    Svennis:
    Yes, my post was deadly serious! It looks like the program already does the most important checks for date and email validation. I am not saying that you should not do validation, but I also think that you should not explain every possibility of mistyping an input in enormous detail.

    Pseudo code:

    if not email.validate()
    {
      ShowMessage( "Email does not match pattern [email protected]");
    }

    is fine with me!

    Ok, ok :) The fun (?) part was (for me) that there were about 50 posts before yours that said the same thing :)
  • Mr. Sidious Guy (unregistered)

    Wipe them testers out. All of them.

  • bandad (unregistered) in reply to Xargon

    Xargon:
    They should re-code it so all errors are reported as: "A critical failure has occured between the keyboard and the chair."  I'll bet the testers replace their desks before they get it.

    Or use the favorite error message of a one-time-colleague of mine:

    "Compatibility Error has occurred. User upgrade required."

     

  • Sven (unregistered) in reply to impslayer
    impslayer:

    Ok, ok :) The fun (?) part was (for me) that there were about 50 posts before yours that said the same thing :)

    Ah, ok. I was too lazy to read all previous pages :)
    Btw: My Name is Sven, not Svennis.
  • (cs) in reply to Sven
    Anonymous:
    impslayer:

    Ok, ok :) The fun (?) part was (for me) that there were about 50 posts before yours that said the same thing :)

    Ah, ok. I was too lazy to read all previous pages :)
    Btw: My Name is Sven, not Svennis.

    Bah, then it's back to 'Anonymous' then ;)
  • Cynos (unregistered) in reply to Kiss me, I'm Polish
    Anonymous:
    The real WTF here is so many coders thinking they're smart and funny, yet can't recognise a tester that is smart and funny.
    I hate generic error messages like "Invalid e-mail" - they don't tell you what's wrong, since it's obvious for the coders. Users don't see the difference between a webpage and Excel, remember that.
    Face it - you don't write for yourselves. You write for these "monkeys". Nobody cares if *you* can handle the application.

    The real WTF is the lazy testers using any excuse to not test.

  • (cs) in reply to Cynos
    Anonymous:
    Anonymous:
    The real WTF here is so many coders thinking they're smart and funny, yet can't recognise a tester that is smart and funny.
    I hate generic error messages like "Invalid e-mail" - they don't tell you what's wrong, since it's obvious for the coders. Users don't see the difference between a webpage and Excel, remember that.
    Face it - you don't write for yourselves. You write for these "monkeys". Nobody cares if *you* can handle the application.

    The real WTF is the lazy testers using any excuse to not test.


    Might as well keep on spamming... Nope, the real WTF is the lazy Eye-Dee-Ten-Tangos that don't read the previous posts before writing their own copies :P

  • anonymous (unregistered) in reply to Alun Jones

    Programming is the process of removing the bugs from an empty directory tree. The first bug in most such empty directories is that they don't produce an executable when "make" is run. Then you have to fix "the executable doesn't do anything", followed by "the executable doesn't do everything", and "everything the executable does is wrong". Eventually, you get to "some things the executable does are wrong". At that point, you should remind the user how many bugs have already been removed from the piece of crap they gave you to start from.

    I disagree..
    Programing is implementing as code a design. So your code match your design AND is flexible enough to adapt to changes in the design.

    THEN you need to validate your implementation AND design against a real user (GAMMA tester) or fake user (BETA tester). Often this result on implementation errors, or design errors. Or changes on specifications (specification error?). So you adapt your code and your documentation; and your specifications (if needed); to fix this problems.

    You will never hunt all errors If you start with buggy code. You sould try to start and continue with error-free code has posible. IMveryHO.

    --Tei

    captcha: grapes

  • The 2-Belo (unregistered) in reply to Rick

    Rick:
    Many years ago, 2 decades or there abouts, I was working on a version of a BASIC language interpreter that AT&T was testing for resale. One of the key developers frequently mistyped the LIST command so he added LSIT to the language.

    AT&T testers complained because LSIT wasn't documented. :)

    I would have preferred that he added "LISY", because that's the way I always ended up spelling it on those ultraloud clickety-clackety IBM tactile-feedback keyboards.

    Which makes me sort of scoff at the testers in this article; they obviously weren't raised during the era where a "helpful error message" consisted of classics like

    ?SYNTAX ERROR

    and

    Bad command or file name

    and that was it.

    --
    $0.02

  • Remco Gerlich (unregistered)

    The tester's comments by themselves make sense. The improvements he suggests are real improvements, and they're quite possible to implement. Good error messages are much too rare.

    However, the WTF is that these are considered such huge bugs that not only are they a showstopper for production, they even make all further testing impossible! That's just beyond ridiculous.

    The tester probably didn't feel like testing that day, and looked for the first excuse to be found.

  • Chae (unregistered) in reply to no one
    Anonymous:
    Anonymous:

    Second!

     

    More seriously, it makes you wonder if the developer wrote once and tested naught!

     

    did you guys even bother to read the entire thing..? It's quite obvious here that the WTF is with the testers, not the coders.  The coders seemed to have done an adequet job of error proofing the application, but the testers seem to expect the thing to me idiot proofed X10



    You seem to be missing the part where testers work from external demands. IE: it doesn't matter if it's "wavable" bugs for the tester IF an external quality assurance security says that "This wont pass our demands because <insert dumb reason>." I think it's fairly safe to say that the developer in this case wrote the program without bothering to make sure he met the specified standards required for the product, which is NOT the testers "WTF".

    I get the /sigh feeling that most developers are under the misconception that QA people are there to make their day worse, whereas they are actually there to make sure the application under tesing passes EXTERNAL demands for product quality. This means, they are there to save the developer a shitload of time.

    -Chae
  • UTU (unregistered) in reply to Mike N
    Anonymous:
    If the code did more sophisticated checking, we'd point and laugh because the coder added ridiculous complexity where a one line regex would have sufficed.


    I'm yet to see "a one line regex" that could check whether a given email address is valid or not (there are very few that even manage to check if the address is syntactically valid).

    And, to be more on the point, I've seen some rather confused testing reports in the wild; latest example was when a multinational company complained that changing social security number of a user doesn't automatically update the birth date of that user (this needs a bit of explaining; in my country you can always read birth date from social security numbers, however, this doesn't hold water in many other countries where the said company also conducts business - besides, it was never requested to even attempt anything like that in the specification...)
  • (cs) in reply to no one
    did you guys even bother to read the entire thing..? It's quite obvious here that the WTF is with the testers, not the coders.  The coders seemed to have done an adequet job of error proofing the application, but the testers seem to expect the thing to me idiot proofed X10

    I do not agree, but IMO the problem is not as severe as the testers make it seem. The error messages should be an explenation of *what* is wrong rather than just state that something is wrong.

    I'll keep that in mind for further coding...
  • (cs) in reply to Chae
    Anonymous:
    <insert dumb="" reason="">
    I get the /sigh feeling that most developers are under the misconception that QA people are there to make their day worse, whereas they are actually there to make sure the application under tesing passes EXTERNAL demands for product quality. This means, they are there to save the developer a shitload of time.


    This is sooooooooooooooo true. In the company I'm currently working at, we had a young lady dedicated to project management and QA, and she took the job very seriously. Especially the QA part. Sometimes it was annoying, but it was thanks to her that so many projects went pretty well at that time. Two years ago, she was demoted to doc writing (to make place for the company owner's son), and eventually left. Since then, quality observably degraded, despite the best efforts of the development team to do QA themself (the new "project manager" is more of a MS project guy, making deadlines and stuff, but not too concerned with the actual product)
    Brrrrrrrrrrrrrrrrrrrr
    </insert>
  • (cs) in reply to UTU
    Anonymous:
    in my country you can always read birth date from social security numbers,


    Austria?
  • UTU (unregistered) in reply to sao
    sao:
    under windows XP... it even tells u 'Network cable unplugged'.... see... Microsoft CAN get one thing right.
    but lets leave it there.


    Yes. It also tells you that when the cable most definetly is plugged (on both ends to be even more exact) but the router/whatever it is on the other end happens to be out of electricity. So much for Microsoft getting one thing right.

  • Remco Gerlich (unregistered) in reply to Mike K.

    All regular expressions can be implemented using a finite state machine, basic result of computer science. Finite state machines cannot check if a string with an arbitrary number of parens has all of them matching, since that would need an arbitrary number of states.

    If you feel different, please show us a regular grammar for a language that contains exactly the strings of the form '()', '(())', '((()))', etc.

    That said, the "regular expressions" present in modern computer languages have more features that make matching matching parens possible; but that just means they're not real regular expressions.

    So you're both right.

    Remco

  • (cs) in reply to awfwaf
    Anonymous:
    Anonymous:

    Regular expressions CANNOT validate matching parenthesis (or matching symbols of any kind) where the number of left-hand symbols must match the number of right-hand.  Its mathematically proven.  Now, some implementations of regular expressions (such as .NET) have EXTENSIONS that do allow you to validate them correctly, but regular expressions by themselves cannot do it.  There is a whole area of study called Formal Language Theory that studies these kinds of things.

    Wait a second.  So you're telling me that someone out there added these things... called extensions...  to regular expressions...  that give regular expressions the ability to match parentheses...  So that means that regular expressions can in fact, match parentheses?
    No, because a regular expression "plus extensions" is not a regular expression any more.

    A regular expression is a well-defined term, that corresponds both to the language it describes and the machine required to recognize that language.

    The various extensions that are out there which allow some languages to match arbitrarily deep matched nested parentheses prevent those languages from having regular expressions by definition.

  • Granma Nazi (unregistered) in reply to just some guy
    Anonymous:
    Anonymous:
    R.Flowers:

    You forgot .museum, .info, .biz and all the country codes!  You also need a button that says "more dots"!


    You also need a button that says, "more cowbell"!
    And you need to tak away the buttons that say 'less letters' and replace them with ones that say 'fewer letters' ...
  • (cs) in reply to Code Monkey
    Code Monkey:

    Is it just me or is everyone skipping the giant WTF their process. Why wasn't the testing done prior to deployment?

    Who said it was deployed? I think you need to go back and reread it.

Leave a comment on “The Bug is in the Details”

Log In or post as a guest

Replying to comment #:

« Return to Article