• Alun Jones (unregistered) in reply to ParkinT
    ParkinT:

    <FONT size=4>If debugging is the process of removing errors,</FONT>

    <FONT size=4>the Programming must be the process of <FONT color=#ff0000>inserting</FONT> them.</FONT>

    Not true.  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.

  • Dustman (unregistered)
    Alex Papadimoulis:

    If you type "03/30/2005" in this field, it gives the following message: "The date entered is not valid. Dates must be entered in the MM/DD/YYYY format." We then typed in "MM/DD/YYYY" in the same field and it provided the same exact message. This will greatly confuse the users.

    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. Typing in "02/30/2005" should tell the user something to the effect of, "although the month and year are correct, there are not 30 days in February, only 28."

    Until my powers as a Time Lord are returned to me, I can't fulfill a request for something to have happened last year. The fact that nobody, including the readers here, spotted what wrong means that the testers have a point.

    It's still no excuse for this being tested after deployment, nor for the snotty attitude.

  • Alun Jones (unregistered) in reply to Eli

    Anonymous:
    Actually, you can't really validate a string as an e-mail address using just a regex.  I know everybody believes that, but you can't.  If you believe that, you haven't really read the RFC completely.

    Then again, when was the last time anyone needed to put a COMMENT in the middle of an email address?

    Oh, I don't know - "[email protected]"

    is slightly less helpful than "[email protected] (John Smith, my manager)"
  • mpeters (unregistered) in reply to Dave
    Anonymous:

     I frequently see [email protected] or [email protected] and plenty of others. 



    But those are valid email addresses. Aside from sending an email to them, there's no way to know that they don't really exist. And sending an email and then waiting on the response from the server would make this form submission much longer than the user probably wants to wait.
  • (cs) in reply to bobnik
    Anonymous:
    Quite a lot of developer arrogance here...
     
    While the testers weren't exactly polite, their complaints and reaction are absolutely valid. This is assuming that descriptive error messages was part of the requirements, and that they set high standards for usability and quality.
     
    Any demanding guidelines for usability will tell you that when validating user-entered data, your system feedback has to explain exactly what is wrong with ill-formed or illegal values.
     
    The testers could have gone on, obviously, but there was really no point when there were so many basic problems on the first form. They would be wasting their time pointing out the same things over and over again. From their point of view, the system was incomplete. Better to send it back to the developers, have them fix this whole class of problems, then test the finished system.

    Perhaps, but surely you have to assume that the person knows what date they want to enter or what their e-mail address is? If they do, it's just a case of them having to figure out the typo, which they can probably do much more accurately that the computer. And if they don't, all that providing further feedback would do is give them more hints as to how to come up with something that passes the checks without necessarily being correct.

    I suppose you could argue that the date format could be made clearer, but that's a fairly common way of representing it, including on paper forms, so unless there's some specific reason...

  • (cs) in reply to GalacticCowboy
    GalacticCowboy:
    R.Flowers:

    How about ".co.uk"?  And is . a valid character in the dropdowns?  I have two e-mail addresses that have . in them...  (on the username side)


    Sure. That'll be $250,000, please.
  • (cs) in reply to Dr.Jekyll

    Anonymous:
    The email regex looks like this (from Perl's Regexp::Common module): (?:(?-xism:(?:(?-xism:(?-xism:(?-xism:(?-xism:(?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*[^\x00-\x1F\x7F()<>\[\]:;@\,."\s]+(?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*)|(?-xism:(?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*"(?-xism:(?-xism:[^\\"])|(?-xism:\\(?-xism:[^\x0A\x0D])))+"(?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*))+)?(?-xism:(?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*<(?-xism:(?-xism:(?-xism:(?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*(?-xism:[^\x00-\x1F\x7F()<>\[\]:;@\,."\s]+(?:\.[^\x00-\x1F\x7F()<>\[\]:;@\,."\s]+)*)(?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*)|(?-xism:(?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*"(?-xism:(?-xism:[^\\"])|(?-xism:\\(?-xism:[^\x0A\x0D])))+"(?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*))\@(?-xism:(?-xism:(?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*(?-xism:[^\x00-\x1F\x7F()<>\[\]:;@\,."\s]+(?:\.[^\x00-\x1F\x7F()<>\[\]:;@\,."\s]+)*)(?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*)|(?-xism:(?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*\[(?:\s*(?-xism:(?-xism:[^\[\]\\])|(?-xism:\\(?-xism:[^\x0A\x0D])))+)*\s*\](?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*)))>(?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*))|(?-xism:(?-xism:(?-xism:(?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*(?-xism:[^\x00-\x1F\x7F()<>\[\]:;@\,."\s]+(?:\.[^\x00-\x1F\x7F()<>\[\]:;@\,."\s]+)*)(?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*)|(?-xism:(?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*"(?-xism:(?-xism:[^\\"])|(?-xism:\\(?-xism:[^\x0A\x0D])))+"(?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*))\@(?-xism:(?-xism:(?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*(?-xism:[^\x00-\x1F\x7F()<>\[\]:;@\,."\s]+(?:\.[^\x00-\x1F\x7F()<>\[\]:;@\,."\s]+)*)(?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*)|(?-xism:(?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*\[(?:\s*(?-xism:(?-xism:[^\[\]\\])|(?-xism:\\(?-xism:[^\x0A\x0D])))+)*\s*\](?-xism:(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)+|\s+)*))))(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|(?-xism:\s*\((?:\s*(?-xism:(?-xism:(?>[^()\\]+))|(?-xism:\\(?-xism:[^\x0A\x0D]))|)+)*\s*\)\s*))+)*\s*\)\s*)*))

    While I appreciate that someone thought this up, wrote it down, and most likely tesated it, all I can think of is: Gaaaaaaaaaaaaaaaah !!!??!?!?!

     

  • Benjimawoo (unregistered)

    Of course, all arguments aside about the verbosity of validation messages, it is still based on the rather naive assumption that users are actually going to read what's on the screen in front of them.

  • Alun Jones (unregistered) in reply to makomk

    Definitely some developer arrogance in the comments.

    Typing "02/30/2005" should not give you an error that implies your formatting is incorrect.  The formatting is correct, but the values supplied are invalid.

    When testing for an invalid email address, you should report what you discovered that made the email address invalid.  It is not enough to say or imply that the email address doesn't match your regexp, and that's all you'll say.  You have to say "more than one '@' sign", "no '@' sign", "no dots", "no user-name part", "no domain name part", etc.

    It's always a good idea to have some user representation early on in the development of an application, so that you don't spend weeks / months / years building something that is almost, but not quite, entirely unlike what the user wanted.

  • (cs) in reply to bobnik
    Anonymous:
    Quite a lot of developer arrogance here...
     
    While the testers weren't exactly polite, their complaints and reaction are absolutely valid. This is assuming that descriptive error messages was part of the requirements, and that they set high standards for usability and quality.
     
    Any demanding guidelines for usability will tell you that when validating user-entered data, your system feedback has to explain exactly what is wrong with ill-formed or illegal values.
     
    The testers could have gone on, obviously, but there was really no point when there were so many basic problems on the first form. They would be wasting their time pointing out the same things over and over again. From their point of view, the system was incomplete. Better to send it back to the developers, have them fix this whole class of problems, then test the finished system.

    Yes and no.  You are correct when you say that "..Any demanding guidelines for usability will tell you that when validating user-entered data, your system feedback has to explain exactly what is wrong with ill-formed or illegal values..".  However, the problem with the original post is that the testers stepped way past what you were talking about and were asking for the system to somehow magically divine the users original purpose in entering the (invalid) value or values.

    As an earlier poster said, while it is perfectly valid to say that "2/30/2005" is an invalid date, it is NOT valid for the system to make an unwarranted assumption that the user intended to enter "3/30/2005" and respond with a validation message to that effect.  The user could just as easily have meant to enter "2/20/2005".

    And with what, exactly, should the system have prompted the user when the user entered a date of "mm/dd/yyyy"?  "I'm sorry, but there are only dd days in mm."?

    No.  The furthest Sridhar should go here would be to say that "The date you entered was invalid.  A valid date matches the pattern mm/dd/yyyy".  If that isn't good enough for the customer, cancel the contract and walk away.  If they're going to be this anally retentive about this, you are going to loose a lot more money in the long term trying to support them than you'll end out making from the contract.
  • (cs)

    ::facepalm::

  • J. B. Rainsberger (unregistered)

    A perfect example of what happens when you don't negotiate requirements until the very end. In this case, by deploying the entire application on the last day, Sridhar missed the opportunity to deal with both these issues before the testers decided they were showstoppers.

    Here is how I'd like to see this happen in real life:

    1. Sridhar ships the first screen.
    2. The testers try it, then complain about the error messages.
    3. Sridhar explains that a better error message on the date field will cost a little more, but that a better error message on the e-mail field will cost a lot more, and things like "ending in .com or .net" even lead to incorrect behavior. (My e-mail address ends in .info, for example.)
    4. Whoever pays for this project can then decide whether to spend the money on better error messages.

    Sridhar can use this information to adjust his estimates for all the remaining screens, the Gold Owner gets to decide where to invest his or her money, and the testers have realistic expectations of what the system should do.

    Of course, the real WTF, in my opinion, is that the programmer, tester and customer didn't talk to each other while this project was being built.

  • (cs) in reply to Benjimawoo

    Anonymous:
    Of course, all arguments aside about the verbosity of validation messages, it is still based on the rather naive assumption that users are actually going to read what's on the screen in front of them.

    "We appreciate your interest in our application.  Unfortunately, we were unable to verify some of the items you entered on the registration form.  This is undoubtedly our fault.  Please click 'OK' to continue.  By clicking OK, you give consent that three ninja chickens, a rabid wombat and the original developer of this module will engage in a cage match to the death.  It is entirely possible that you may hyperventilate at this point; we have it on good authority that it may be beneficial to lie quietly on the floor with a paper bag over your head.  If the condition does not pass within a quarter hour, read back through your entries and verify that you have not in fact entered your Visa number in the e-mail field by mistake.  This is a common occurrence and our site administrator certainly appreciates your thoughtfulness in funding his online shopping habit."

  • no name (unregistered) in reply to Alun Jones
    When testing for an invalid email address, you should report what you discovered that made the email address invalid. It is not enough to say or imply that the email address doesn't match your regexp, and that's all you'll say. You have to say "more than one '@' sign", "no '@' sign", "no dots", "no user-name part", "no domain name part", etc.

    Have you been paying attention to this thread?

    I suggest you go back and reread it. Pay special attention to the regex's linked to. The RFC is not trivial. Email addresses can be much more complex than the simple examples you are used to.

    If it takes a monster regex like those to get a simple true/false binary validation, imagine how many thousands of LOC it would take to give detailed reasons for which pieces of the RFC the input violates. Do you really think the clients want to pay for that? 99 times out of a 100 they don't.

  • rycamor (unregistered) in reply to mrprogguy
    mrprogguy:

    WWWWolf:
    Good luck coding an address validator! I mean, while you can validate a the correctness of an email address with a quite simple regex (http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html), writing an error handler that explains exactly what's wrong with the address would be surprisingly tricky. Bonus points if the error message ends "... (RFC 2822, section 3.4.1, sentence 3 - We know you don't care, we're just trying to annoy you)"

    Actually, you can't really validate a string as an e-mail address using just a regex.  I know everybody believes that, but you can't.  If you believe that, you haven't really read the RFC completely.



    The One True Email Regex.
  • (cs)

    "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.  For example if, I type in 30/2/2006, one interpretation with what is wrong is that 30 can't be a month.  Another is that the program doesn't accept other than standard American date format.  Another could be that the user meant 3/02/2006, and the first 0 just needed to be moved over to the right of the right of the "/". 

    Bottom line is the program can't read the user's mind, and there are often multiple ways multiple ways to interpret what someone meant when they type the wrong thing.  If the customer wants that level of detail, they need to supply the same level in the requirements.  Every possible error that they want a customized message for needs to be mapped to the customized message that it goes to.  This does not appear to have been in the spec or the author of the testers are even more inept than I thought.

    I've seen this behavior by testers and more particularly by customers time and time again.  I once had a boss that wanted to make sure all names entered into the system were in mixed case.  However he wanted us to allow the user to type names in using whatever case they wanted and not to change the case if they didn't enter it as mixed case and not to give any error messages if they didn't enter the name in as mixed case.  Just how he wanted us to perform this miracle is beyond me. 

     

  • (cs) in reply to no name
    Anonymous:
    When testing for an invalid email address, you should report what you discovered that made the email address invalid. It is not enough to say or imply that the email address doesn't match your regexp, and that's all you'll say. You have to say "more than one '@' sign", "no '@' sign", "no dots", "no user-name part", "no domain name part", etc.

    Have you been paying attention to this thread?

    I suggest you go back and reread it. Pay special attention to the regex's linked to. The RFC is not trivial. Email addresses can be much more complex than the simple examples you are used to.

    If it takes a monster regex like those to get a simple true/false binary validation, imagine how many thousands of LOC it would take to give detailed reasons for which pieces of the RFC the input violates. Do you really think the clients want to pay for that? 99 times out of a 100 they don't.



    A good compromise might be to use the monster regex for validation; if it fails, check a few common mistakes. The first check would be to see if it starts with "http://" or "www." (*), for those users who can't tell an email adress from a web adress. Such simple checks should be enough for 98% of all mistakes that really happen.

    (*) I know, I know, [email protected] is a perfectly valid email adress. But remember we only check if the regex fails, so it wasn't [email protected]
  • (cs) in reply to GalacticCowboy
    GalacticCowboy:

    Anonymous:
    Of course, all arguments aside about the verbosity of validation messages, it is still based on the rather naive assumption that users are actually going to read what's on the screen in front of them.

    "We appreciate your interest in our application.  Unfortunately, we were unable to verify some of the items you entered on the registration form.  This is undoubtedly our fault.  Please click 'OK' to continue.  By clicking OK, you give consent that three ninja chickens, a rabid wombat and the original developer of this module will engage in a cage match to the death.  It is entirely possible that you may hyperventilate at this point; we have it on good authority that it may be beneficial to lie quietly on the floor with a paper bag over your head.  If the condition does not pass within a quarter hour, read back through your entries and verify that you have not in fact entered your Visa number in the e-mail field by mistake.  This is a common occurrence and our site administrator certainly appreciates your thoughtfulness in funding his online shopping habit."

    Bravo.  Well done.[Y]

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

     I frequently see [email protected] or [email protected] and plenty of others. 



    But those are valid email addresses. Aside from sending an email to them, there's no way to know that they don't really exist. And sending an email and then waiting on the response from the server would make this form submission much longer than the user probably wants to wait.


    Assuming of course that the system does not just eat emails instead of bouncing bad ones back.
  • (cs) in reply to bobnik
    Anonymous:
    Quite a lot of developer arrogance here...
     
    While the testers weren't exactly polite, their complaints and reaction are absolutely valid. This is assuming that descriptive error messages was part of the requirements, and that they set high standards for usability and quality.
     
    Any demanding guidelines for usability will tell you that when validating user-entered data, your system feedback has to explain exactly what is wrong with ill-formed or illegal values.
     
    The testers could have gone on, obviously, but there was really no point when there were so many basic problems on the first form. They would be wasting their time pointing out the same things over and over again. From their point of view, the system was incomplete. Better to send it back to the developers, have them fix this whole class of problems, then test the finished system.

    WTF?  You have no idea, do you?  Just plain clueless.

  • (cs) in reply to bobnik
    Anonymous:
    The testers could have gone on, obviously, but there was really no point when there were so many basic problems on the first form. They would be wasting their time pointing out the same things over and over again. From their point of view, the system was incomplete. Better to send it back to the developers, have them fix this whole class of problems, then test the finished system.


    Well then the tester's "point of view" is the real WTF here, if in their point of view they thought that an error message telling them that "date format has to be mm/dd/yyyy" then they thought the system was telling them they had to enter a date of "mm/dd/yyyy" and could not understand why that did not validate.

    Why are so many of you guys defending the tester's note?

    They were upset that they were told that [email protected]@[email protected]@[email protected]" is not a valid address
    They thought it was a problem that the (literal) "mm/dd/yyyy" did not validate as a valid date after the system told them the format had to be "mm/dd/yyyy"
  • no name (unregistered) in reply to rycamor
    The One True Email Regex.



    You should pay more attention to the pages you link to:
    This regular expression will only validate addresses that have had any comments stripped and replaced with whitespace (this is done by the module).

  • John Hensley (unregistered) in reply to Matt B

    Well it's not like anyone actually uses explicit routing anymore.

    (right?)

  • Josh (unregistered)

    No! You've got it all wrong! The real WTF is the people who responded to this post thinking that it was bagging the developers. Obviously many testers read this site and are themselves producing WTF's all the time (I mean, how else would new posts become available...).

  • Reinier (unregistered) in reply to R. Tyler Ballance

    No doubt the testers were being sarcastic - the point is that users won't understand the error messages. And I think they're right. So this is a case where the initial thought is, indeed, "WTF?", but on second thought, I hope, the developers can only agree.

  • John Hensley (unregistered) in reply to Matt B
    Matt B:

    They thought it was a problem that the (literal) "mm/dd/yyyy" did not validate as a valid date after the system told them the format had to be "mm/dd/yyyy"

    In an international setting that is a damn good criticism, even though it was expressed stupidly. The software should at least give an example that spells out a date in the local language and shows the corresponding formatted date.

  • (cs) in reply to Mr Beeper
    Mr Beeper:
    If the application had been coded in Lisp over 40 years ago (tm), each time an error gets raised it would initiate a live voice chat session (preferably with video) so that the programmer could explain face to face what the problem is, as well as offer some helpful suggestions for gettng the data input correctly.


    You need the video in order to read their lips, since they are speaking with a lisp...
  • Sound (unregistered)

    Anybody mentioned user friedly error messages? This is how it should be done...

    Please enter valid date in (d)d-(m)m-(yy)yy format:

    30-2-2005 ...

    Incorrect date format, date must conform to following expression: ^((((3[01]|[12][0-9]|0?[1-9])-(0?[13578]|1[02])|(30|[12][0-9]|0?[1-9])-(0?[469]|11)|(2[0-8]|1[0-9]|0?[1-9])-(0?2))-([0-9]{2}|[0-9]{4}))|([12][0-9]|0?[1-9])-(0?2)-([0-9]{2})?([02468][048]|[13579][26]))$

    yeah right

  • Moi (unregistered) in reply to rycamor
    Anonymous:
    mrprogguy:

    WWWWolf:
    Good luck coding an address validator! I mean, while you can validate a the correctness of an email address with a quite simple regex (http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html), writing an error handler that explains exactly what's wrong with the address would be surprisingly tricky. Bonus points if the error message ends "... (RFC 2822, section 3.4.1, sentence 3 - We know you don't care, we're just trying to annoy you)"

    Actually, you can't really validate a string as an e-mail address using just a regex.  I know everybody believes that, but you can't.  If you believe that, you haven't really read the RFC completely.



    The One True Email Regex.


    That's one Helluva emoticon.
    														</span>
    
  • Bungalo Butt (unregistered) in reply to R.Flowers
    R.Flowers:

    You forgot .museum, .info, .biz and all the country codes!  You also need a button that says "more dots"!
  • Becca (unregistered) in reply to mrprogguy
    mrprogguy:

    WWWWolf:
    Good luck coding an address validator! I mean, while you can validate a the correctness of an email address with a quite simple regex (http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html), writing an error handler that explains exactly what's wrong with the address would be surprisingly tricky. Bonus points if the error message ends "... (RFC 2822, section 3.4.1, sentence 3 - We know you don't care, we're just trying to annoy you)"

    Actually, you can't really validate a string as an e-mail address using just a regex.  I know everybody believes that, but you can't.  If you believe that, you haven't really read the RFC completely.

    If you follow the link you'll notice that the module in question doesn't actually just use a regexp. It seperately strips comments which then allows it to validate via regexp.
  • (cs)

    I have encountered both date and email validations and have come to the conclusion that most validations probably shouldn't be attempted because to validate them right would just be too hard.  Most of my problems now are dealing with coworker's broken validation techniques.  FYI, Canadian postal codes contain letters as well as numbers.  If you want to include Canada in the country field, don't restrict the postal codes to only 5 digit numbers.

    For dates, I prefer dropdowns for day, month and year because people will type the month and the day backwards and for days under 12, the software can't know the difference.

    As for email addresses, the RFC is intentionally vauge.  It basically says it takes the form of [email protected]  There is a regex for domains, but the user part is defined to be okay so long as the mailserver accepts it, and it can accept or reject any format it chooses.

    But if you are going to validate the domain, at least use the right regex.  On my last job, I once went to website registration page which required a valid email address to view its products for sale.  My email address at the time was [email protected]  The website only allowed two dots in the domain part.  I ended up having to use my boss's email address since he got a special one with only one dot.

  • just some guy (unregistered) in reply to Bungalo Butt
    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"!
  • (cs) in reply to Dave
    Anonymous:

    So the WTF is that the customer wanted better error handling?

    > 03/30/2005

    I assume this was 02/30/2005 as used a bit lower down. The error message *is* deceptive, it indicates that the format is wrong but the actual problem is that the date is not valid.

    On the email validation, anybody here who deals with people typing in emails knows that they get it wrong a lot of the time. I frequently see [email protected] or [email protected] and plenty of others. The customer had it wrong to some degree--any domain such as .info can have emails as well--but still, it would be good to be more specific about what was wrong. A few regular expressions can handle this easily.



    I'm not sure that regular expressions are the best way to go for email validation.  Here iare regular expressions that will validate email addresses:
    http://ex-parrot.com/~pdw/Mail-RFC822-Address.html
    http://www.regular-expressions.info/email.html

    David

  • tomhath (unregistered)

    There are two sides to every story, and I suspect there is a lot more to this one. From the tone of the memo I assume the specifications for the system made it pretty clear that the system was supposed to validate all user input and provide meaningful error messages. So when the customer tried the software out and it failed this requirement, he apparently decided to send it back for a rewrite before investing anymore time on it. Not sure where the WTF is here.

  • chuck norris (unregistered)

    these testers are dumbasses. also known as "a pain in the arse".
    if they really want all that dumbshit-exact-errormessages like -- mhm [email protected] -> "That email sounds ridiculous. get another, that sounds better" -- they should wild-billieboy and his M$ dumbasses, pay them about 3million bucks only for that errormessages and shut up.
    i've had such a customer myself, after about one month i told him, that the program was already as he wanted it, he should leave me alone and pay the damn bill.
    he paid and i put all his email-adresses on my spamlist.


    When God said, "let there be light", Chuck Norris said, "say 'please'."

  • chuck norris (unregistered) in reply to chuck norris
    Anonymous:
    these testers are dumbasses. also known as "a pain in the arse".
    if they really want all that dumbshit-exact-errormessages like -- mhm [email protected] -> "That email sounds ridiculous. get another, that sounds better" -- they should wild-billieboy and his M$ dumbasses, pay them about 3million bucks only for that errormessages and shut up.
    i've had such a customer myself, after about one month i told him, that the program was already as he wanted it, he should leave me alone and pay the damn bill.
    he paid and i put all his email-adresses on my spamlist.


    When God said, "let there be light", Chuck Norris said, "say 'please'."


    Me, Chuck Norris deos nto make splleing msitakes.
    If you think, threr aer spleling-mitsakes in the above text, you should notiec, that your language is worng and borken. :D
  • Jon (unregistered) in reply to tomhath

    The real WTF is with the people who think that the super-gigantic regex is JUST for checking a plain email address. It's for validating the 'To' field of an email message, which can contain lots of stuff besides plain email addresses.

  • (cs)

    An irritation that no one has mentioned is that the test report considers each date field's validation a separate bug.

    True, they at least seem to abbreviate it by saying things like "Renewal Date: Same problems as Requested Date."  But if they're going to repeat that for every date field in the system... well, no wonder they didn't want to continue with their testing!

    I guess I can understand an unschooled customer doing something like that.  However, I've encountered testers who do it and, like most people, I would get very irritated at having 72 bugs written up, one for each date field.  True, it gives one the opportunity to knock out 72 bugs in one fell swoop, but I've seen pointy-haired bosses get involved and decide that the programmer must be pretty awful since he wrote something with so many bugs in it....

    As for validating e-mail, a few posts have mentioned that there are more top-level domains than ".com" and ".net", but it needs to be pointed out that top-level domains are still being created!  I think the discussion for ".tel" is still ongoing, for instance.  And let's not forget that every time a country is formed or unifies, a new two-letter country code is created (and others may be removed).

  • (cs) in reply to GoatCheez
    "Let me make sure that my verification code is five billion lines wrong"

    Ha!

    The testers suggested that when you put in "02/30/2005" it tells you that the month and year are correct but they put in the wrong day. How do you know? What if they really meant to put in "03/30/2005"? "I put in the wrong month, but it told me that the month was right and the day was wrong."

    You can still stick to saying what you can be sure of: "February only has 28 days, so the month and/or day must be wrong here."

    So in all seriousness, if you were the developer in this situation, and you got that response back from the testing team..
     
    ..What the heck would you do?

    "Yes, but". In this case it would be "yes, we can do that, but it will be $X extra because this was not in the original spec". Set $X high enough that they won't pay it, and/or that it will compensate for your hair-pulling if they do.

    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...

    Not stupid at all, there may be multiple people using this screen and they want each user to be able to pick whatever method that particular user can best deal with. Besides, surely there are umpteen drop-in controls that implement a text-box-plus-date-picker correctly?

  • (cs) in reply to chuck norris

    Anonymous:

    i've had such a customer myself, after about one month i told him, that the program was already as he wanted it, he should leave me alone and pay the damn bill.
    he paid and i put all his email-adresses on my spamlist.

    An intermediate option is to require them to pay in advance for all future work.  Of course, if they smell sue-happy, then by all means issue an explicit "we will no longer do any work for you" notice as soon as humanly possible.

     

  • tim (unregistered)

    that's an official "pebkac"

  • (cs) in reply to tim

    Anonymous:
    that's an official "pebkac"

    143 responses (or replies or whatever) and you beat me to it... DAMN YOU! [:P]

    http://en.wikipedia.org/wiki/Pebkac

  • (cs) in reply to Alun Jones
    Anonymous:

    When testing for an invalid email address, you should report what you discovered that made the email address invalid.  It is not enough to say or imply that the email address doesn't match your regexp, and that's all you'll say.  You have to say "more than one '@' sign", "no '@' sign", "no dots", "no user-name part", "no domain name part", etc.

    It's always a good idea to have some user representation early on in the development of an application, so that you don't spend weeks / months / years building something that is almost, but not quite, entirely unlike what the user wanted.

    NO! NO! NO! NO!

    With something like an email address, you should say "address invalid/incorrect" and leave it at that. Let the user look at their email adress and figure out what is wrong. Worst case scenario they can compare what they have written down to what is in the box on the screen.

     

    If you tell the user "no domain name part" the user is going to go.. WHAT THE FUCK is a domain name part? Where do I get a domain name part?

    Keep it Simple. "email is wrong" is good enough.

    No lieing to the user, and telling the user a perfectly formatted, but incorrect date, is incorrectly formatted is also bad.

  • Dwayne Hicks (unregistered) in reply to Moi
    Anonymous:
    Anonymous:


    That's one Helluva emoticon.
    														</span></div></BLOCKQUOTE><br><br>+1 for the only comment that made me laugh out loud.<br>
    
  • Anonymous Bob (unregistered) in reply to Alun Jones
    Anonymous:

    Definitely some developer arrogance in the comments.

    Typing "02/30/2005" should not give you an error that implies your formatting is incorrect.  The formatting is correct, but the values supplied are invalid.

    When testing for an invalid email address, you should report what you discovered that made the email address invalid.  It is not enough to say or imply that the email address doesn't match your regexp, and that's all you'll say.  You have to say "more than one '@' sign", "no '@' sign", "no dots", "no user-name part", "no domain name part", etc.

    It's always a good idea to have some user representation early on in the development of an application, so that you don't spend weeks / months / years building something that is almost, but not quite, entirely unlike what the user wanted.



    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...
  • (cs) 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"!

     

    more cowbell!

  • (cs) in reply to VGR
    VGR:
    An irritation that no one has mentioned is that the test report considers each date field's validation a separate bug.

    True, they at least seem to abbreviate it by saying things like "Renewal Date: Same problems as Requested Date."  But if they're going to repeat that for every date field in the system... well, no wonder they didn't want to continue with their testing!

    I guess I can understand an unschooled customer doing something like that.  However, I've encountered testers who do it and, like most people, I would get very irritated at having 72 bugs written up, one for each date field.  True, it gives one the opportunity to knock out 72 bugs in one fell swoop, but I've seen pointy-haired bosses get involved and decide that the programmer must be pretty awful since he wrote something with so many bugs in it....


    Agreed on this. I used to work at a company that developed an enterprise CMS. We had a testing team that didn't understand what a CMS was used for - so we'd have them test a site that had, say, a shared left navigator that appeared on every page of a 200-page website... and if there was a bug in that left navigator we would receive 200 bugs.

    While I can understand the importance of having a clueless tester to make catch any  implicit assumptions about your system that require prior knowledge... it shouldn't mean that every tester (or the manager) is clueless. A lot of developer time was wasted marking those bugs as "duplicate".
  • keith ray (unregistered)

    Did anyone notice that this memo came from a USER, not a tester!

    "those persistent users can find a bug hiding in any corner"

  • Mike K. (unregistered) in reply to Gene Wirchenko
    Gene Wirchenko:
    Matching parens can not be done with regexes.

    Sincerely,

    Gene Wirchenko

    You can't be serious?

    Just because YOU don't know how to write a regex to match matching parens, doesn't mean that it can't be done.

    WTF

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

Log In or post as a guest

Replying to comment #:

« Return to Article