• (cs) in reply to R. Tyler Ballance

         I am going to make the broad assumption that a good amount of the
    people who have responded negatively towards the testers either i) have
    never worked professsionally or ii) are working in a professional environment
    but don't belong (you're unprofessional) or iii) currently are not working
    professionally (hopefully because you were exposed as being the latter).
     
         I can agree that lacking the specifications of the contract makes this
    discussion somewhat nebulous - yes certain error handling may be
    specified by the customer and that would change things.  I think at
    least, error handling should be concerned with the format of the input
    and content should not exactly be expected (it requires extra effort
    on behalf of the developer to provide an application with a database
    of say valid zipcodes, area codes, dates (that was a content error not
    a format error), and other information).  I think the only WTF there
    was that the application did catch the content error (but didn't
    have to) yet failed to classify the error for the user - by saying
    it was a format error.

         In regards to the poster above - have you ever heard of input
    validation?  In order to make a program secure and robust, all
    avenues of input (edit boxes, files I/O, etc.,) should be tested
    with data that is not expected because of the fact that data
    entered by a user can be un-predictable.  This helps avoid
    applications that crash or do other unpleasant things.  Besides
    checking the size of data (which can result in buffer overflows
    for some languages or simply be an insecure password if it
    is too short), the content of the data - in this case I mean
    the data type (string, numeric, and so on) - can result in non-
    canonical representation (security threats).

         Good programmers check everything they can think of.
    Good testers check everything the programmers didn't think
    of    .

    Dr MindHacker
    Open Source Developer
    http://evercrack.cjb.cc

  • (cs) in reply to tomhath
    Anonymous:
    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.


    The WTF here is that the error messages were meaningful enough. It's the stupidity of the testers; they couldn't read the message well enough to see the word format in the invalid date message, could they?
  • (cs) in reply to Dustman
    Anonymous:
    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.

    Huh? What the hell are you talking about?

  • (cs) in reply to UTU
    Anonymous:
    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.



    PROBLEM: Router out of electricity
    SOLUTION: Purchase more electricity, and refill the router.
  • Clay Dowling (unregistered) in reply to Foone

    It may be that the QA department has a policy that they don't continue after a certain number of errors. None of the errors listed were show stoppers though.  I'd like to believe that they understood what a proper email address looked like, or a proper date. Having noted that there were problems with the data validation a good, conscientious tester would have entered valid data and moved on to test other systems.
    As I mentioned, there may have been something in the --snip-- or there may have been a policy against continuing after too many validation errors. Barring those two things, the tester should have continued on, adn should have been taken severely to task for not continuing. If the first screen has this many problems, it's safe to assume that there are lots of problems in the rest of the system as well. The system goes to production a lot faster if those problems are reported as soon as possible.

  • Botia (unregistered) in reply to Foone

    While I do think that they should report better error messages for invalid input, they are validating the fields. QA should report these as requiring more detailed messages but these are by no means show stoppers.

  • Anthony (unregistered) in reply to GoatCheez
    GoatCheez:
    Oh yes, of course, how stupidly retarded of me. Let me rework all of my code and center it around completely 100% retarded monkeys. Let me make sure that my verification code is five billion lines wrong and littered with stuff that will check stuff like:

    (assuming we are using internet only e-mail)

    Given:
    [email protected]n
    Response:
    con is not a valid top-level domain name.



    That would be bad even if it was cheap to do. New top-level domains do appear from time to time, like the new .eu and proposed .sex domains. Not to mention cases like .co.uk<o:p></o:p>

    <o:p> </o:p>Attempting to enumerate all valid email address suffixes and disallow all others will just create ongoing maintenance work, and sooner or later it won't be done and your system will fall into obsolescence faster than it has to. <o:p></o:p>

    <o:p> </o:p>
    Not to mention that very few things piss me off as a user more than a system that won't accept my perfectly valid input.<o:p></o:p>

    <o:p> </o:p>
    In short, it's extra work,  and makes the system less flexible.<o:p></o:p>

  • (cs) in reply to DrPizza

    How come nobody has mentioned requirements? If the requirements mention detailed validation, you do it, otherwise you follow industry standards. In context, it sounds like the requirements did not cover multiple validations of dates and email addresses, so the tester committed a WTF.

    Development shops are partly culpable for this sort of WTFedness by not publishing standards. If the victim had published a UI standard that did nothing more than reference Jakob Nielsen or somebody, I bet the WTF would not have happened.

  • coditza (unregistered) in reply to RyuO

    Guys, the only WTF in this post was: "Your error messages are confusing. Therefor, we won't continue testing until you add better error messages".

    I mean, wtf? I always test the system with GOOD data, then move to bad data.

  • (cs) in reply to Dave

    "A few regular expressions can handle this easily."

    Have you actually SEEN a regular expression that would fully validate an RPC822 compliant email? I've seen one, it's over 6000 characters. and it only tells you if the pattern matches or not, certainly not what parts are wrong and how.

    That doesn't even handle misspellings (hotmal vs hotmail) or TLD validations (.com, .info, .tw, .museum, etc)

    Who the he11 parses an email to that level (short of an ISP)? You match a reasonable pattern, you know if it matches or not, it's a binary result, YES or NO. You have to defer some responsibility and expectation of functional intelligence onto the user. If you tell a user that the email form isn't valid, it's up to them to figure it out.



  • (cs) in reply to a7

    " You joke, but people really do complain about these things. Especially when they insist that they entered something correctly."

    simply handled: "Sir (or madam), you are an idiot, good day"


  • (cs) in reply to Lama Himself

    "

    [image]
    My opinion is that the tester is good but is also a jerk."


    		I would disagree. This isn't being helpful to anyone. Testing should take into consideration reasonableness. It's also apparent there isn't a spec to test against, the tester is making it up as he/she goes. Perhaps the tester show this to the manager and says "look what a great job I do, boss", or gets paid by the byte size of the results document. Not a good tester, just a clueless one.



  • (cs)

    I've always thought that developers should assume the user is unskilled or not that smart.  Programmers need to try to break their code as much as possible so there's less flak from the users/testers to deal with.

    Besides, the error message for the date is incorrect!  The date 02/30/2005 follows the format, but the error message states it's not properly formatted.  The testers should have continued testing, but they are not the only ones to blame.  I would love to see what other errors they found, and perhaps we might see that they were frustrated, not stupid.

  • (cs)

    This field is the most troubling of all.

    Alex Papadimoulis:
    No matter what we put in the field (aside from an email address), the only message we receive is "The email entered is not valid."
  • (cs) in reply to DrMindHacker

    "      Good programmers check everything they can think of.
    Good testers check everything the programmers didn't think
    of    .

    Dr MindHacker
    Open Source Developer
    http://evercrack.cjb.cc"


    The programmer DID test everything. It seems that invalid emails can't get through, therefore, he's performed his validation.

    IF the specs require reporting to this level of detail, then the developer failed.

    IF the specs merely said "validate email" then he's met his obligation.

    IF there are no specs, then I would still side with the developer. A check for valid form is common and reasonable. The tester is out in left field. No program designed by the sane has a requirement for such detail in parsing an email.

    And FYI, I AM professional, and I DO belong where I am. and we have Specs, requirements and a QA/Test team what knows what's reasonable, important and required.

  • (cs) in reply to flobi
    flobi:
    This field is the most troubling of all.
    Alex Papadimoulis:
    No matter what we put in the field (aside from an email address), the only message we receive is "The email entered is not valid."

    Is quoting broken?

  • Gus (unregistered)

    I actually had a problem with a user trying to enter 2/29/2006 as a date for an event in our system. The error message raised by SQL was "Invalid Date", but the user, a reasonably bright person, couldn't figure it out.

    2/29 would be a valid date in 2004, 2008, etc., but not in 2006.

    I'm not going to build an error handler for that one, since the error was already as clear as I think would be appropriate anyway. User just needed to look at a calendar.

    But telling the user the date isn't in the correct format will cause problems and if you don't way to have the expense of free support calls from your end users, making the software tell you difference between misformatted dates and invalid dates would actually save a little time and expense.

    Spending an extra few hours/days in the development stages to build in more detailed, friendly error messages for end users can save a lot of time and money that will otherwise be spent on support calls later. It's all about the return on investment.

  • (cs) in reply to Sven

    <font size="1">

    Anonymous:

    Pseudo code:

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

    is fine with me!


    <font size="2">With that error message, I'd expect to get a call from a user saying, "Why do I have to get a tld email address to use your software?  Why can't I use my hotmail.com account?"

    </font>
    </font>

  • PEBKAC (unregistered) in reply to dalewill

    PEBKAC - Problem exists between keyboard and chair

  • Stan (unregistered) in reply to PEBKAC

    Hey, if the software does not meet requirements it is defective. If the requirements are messages such as the tester wanted, then the software is wrong. If the product is supposed to distinguish itself in the marketplace with the most amazingly friendly messages for novice users, this can't ship.

    When the developer and the tester have such differing opinions on the requirements, the process is the WTF. Who makes these decisions? How do they communicate them to the developer? To the tester?

  • (cs) in reply to DrMindHacker

    DrMindHacker:
         I am going to make the broad assumption that a good amount of the
    people who have responded negatively towards the testers either i) have
    never worked professsionally or ii) are working in a professional environment
    but don't belong (you're unprofessional) or iii) currently are not working
    professionally (hopefully because you were exposed as being the latter).
     
         I can agree that lacking the specifications of the contract makes this
    discussion *somewhat* nebulous - yes certain error handling may be
    specified by the customer and that would change things.  I think at
    least, error handling should be concerned with the format of the input
    and content should not exactly be expected (it requires *extra* effort
    on behalf of the developer to provide an application with a database
    of say valid zipcodes, area codes, dates (that was a content error not
    a format error), and other information).  I think the only WTF there
    was that the application *did* catch the content error (but didn't
    have to) yet *failed* to classify the error for the user - by saying
    it was a format error.

         In regards to the poster above - have you ever heard of input
    validation?  In order to make a program secure and robust, all
    avenues of input (edit boxes, files I/O, etc.,) should be tested
    with data that is *not* expected because of the fact that data
    entered by a user can be un-predictable.  This helps avoid
    applications that crash or do other unpleasant things.  Besides
    checking the size of data (which can result in buffer overflows
    for some languages or simply be an insecure password if it
    is too short), the content of the data - in this case I mean
    the data type (string, numeric, and so on) - can result in non-
    canonical representation (security threats).

         Good programmers check everything *they can think of*.
    Good testers check everything the programmers *didn't think
    of*.

    Dr MindHacker
    Open Source Developer
    http://evercrack.cjb.cc

    The old saying goes, "Don't assume because it makes an ass out of you and me".  IMO, the 11th commandment should have been "Thou shalt not assume".  Most definitely it is not a very professional behavior to make broad assumptions on little to no data. In your 1st paragraph alone, you made more assumptions that most professionals will in a year.  One might wonder either what your definition of professional is or if you have much familiarity with working in an environment that meets the most common definition of professional, but I won't go out on a limb and assume, that would be downright unprofessional.  Besides I've known many who don't practice what they preach.

    Your examples left something to be desired as well.  Especially the part about providing zip codes and area codes.  Having worked extensively with applications that did rely on databases for zip codes and area codes, I can tell you it is far from being a straight forward benefit to the user of the application to add checking against the content they entered to validate that it exists in the corresponding database.  The biggest problem here is that the data is not static.  Zip codes and area codes are constantly changing.  This in most cases creates a window of latency from where a change has been made but hasn't been entered into your database.  This creates the extremely frustrating error for the user where the user enters perfectly valid data only to be told it's invalid because the application's database hasn't yet been updated with the new data.  Even if the latency problem is avoided, an extreme amount of maintence will need to be added to keep the databases up to date. 

    Also, to add the level of detail that the testers requested, will require lots of work.  The extra work is not a problem of programmers being lazy.  It's a problem of costing more money.  Whoever is paying for that application may very well not want to pay for the extra features.  This level of reporting errors is by no means necessary for the program to be used by a reasonably intelligent user with basic internet knowledge from the information that we have available.  To infer anything else would be to make a broad assumption of facts not in evidence.  My experience with working with multiple fortune 500 clients and several .com's is that is the exception and not the rule to request this level of detail in error messages.  Rather than spend money to enhance error messages that money is usually spent on help desks and additional feature which will be of use when correct data is entered. 

    Now this might not sit well with those who dewell in ivory towers.  However most business decision makers ( and that's who usually pays for applications) tend to value ROI much more than meeting some abstract uptopian programming goals.  The ROI on providing the level of detail mentioned in the email is not very good at all compared to adding other revenue generating features unless your target market is either users very below average in intelligence and/or very below average in internet and computer usage.  A good example would be over 60 millionaires who both have money and because of age might not be very computer literate.  But still even here a help desk that can be called would probably be preferred over more expressive error messages. 

    The real WTF is IT people who don't take into consideration the bottom line when arguing how extensive feature sets such as error messaging should be.  I guarrantee you that it is strongly considered where I work when preparing our application for our Fortune 500 clients where I work.  They expect the highest value for their money, and much prefer a more detail reporting on their data than on some trivial data entry error that most of their users don't need any more info that that it's an error.

  • NotAnEggSucker (unregistered) in reply to DrMindHacker
    DrMindHacker:
         I am going to make the broad assumption that a good amount of the
    people who have responded negatively towards the testers either i) have
    never worked professsionally or ii) are working in a professional environment
    but don't belong (you're unprofessional) or iii) currently are not working
    professionally (hopefully because you were exposed as being the latter).
     
         I can agree that lacking the specifications of the contract makes this
    discussion *somewhat* nebulous - yes certain error handling may be
    specified by the customer and that would change things.  I think at
    least, error handling should be concerned with the format of the input
    and content should not exactly be expected (it requires *extra* effort
    on behalf of the developer to provide an application with a database
    of say valid zipcodes, area codes, dates (that was a content error not
    a format error), and other information).  I think the only WTF there
    was that the application *did* catch the content error (but didn't
    have to) yet *failed* to classify the error for the user - by saying
    it was a format error.

         In regards to the poster above - have you ever heard of input
    validation?  In order to make a program secure and robust, all
    avenues of input (edit boxes, files I/O, etc.,) should be tested
    with data that is *not* expected because of the fact that data
    entered by a user can be un-predictable.  This helps avoid
    applications that crash or do other unpleasant things.  Besides
    checking the size of data (which can result in buffer overflows
    for some languages or simply be an insecure password if it
    is too short), the content of the data - in this case I mean
    the data type (string, numeric, and so on) - can result in non-
    canonical representation (security threats).

         Good programmers check everything *they can think of*.
    Good testers check everything the programmers *didn't think
    of*.

    Dr MindHacker
    Open Source Developer
    http://evercrack.cjb.cc


    Go suck an egg.
  • (cs)

    <FONT size=1>ouch</FONT> <FONT size=2>ouch</FONT> ouch <FONT size=4>ouch</FONT> <FONT size=5>OUCH!</FONT>

    Over 220 posts, WTF!  This is soooo simple, really:

    <FONT face="Courier New" color=#000080 size=2>1)  Get all of those testers into one room.</FONT>

    <FONT face="Courier New" color=#000080 size=2>2)  Explain the "results oriented" approach of this project to these people.</FONT>

    <FONT face="Courier New" color=#000080 size=2>3)  Calmly walk out of room.</FONT>

    <FONT face="Courier New" color=#000080 size=2>4)  Release deadly gas into room to "clear out" the testing problem.</FONT>

    <FONT face="Courier New" color=#000080><FONT size=2>5)  Prepend the text "Microsoft" in front of the product name. </FONT><FONT face=Arial size=1>(i know i'm throwing gas on the flames here)</FONT></FONT>

    <FONT face="Courier New" color=#000080 size=2>6)  Release in "Beta" form.</FONT>

    <FONT face="Courier New" color=#000080 size=2>7)  Wait for comments from the legion of loyal M$ followers.</FONT>

    <FONT face="Courier New" color=#000080 size=2>8)  Update product and release as production application.</FONT>

    <FONT face="Courier New" color=#000080 size=2>9)  Keep up with constant patches and service packs which the industry has grown to expect.</FONT>

    <FONT face="Courier New" color=#000080 size=2>10) Collect tons of money and basically rule the world!</FONT>

    <FONT face="Courier New" color=#000080 size=2>11)  Move on to developing and testing next product.</FONT>

    <FONT face="Courier New" color=#000080 size=2>[6]</FONT>

  • Mr. Friendly (unregistered)

    I'm not involved with this project at all, but I'd like to kill the testers with a hammer.

  • Kiss me, I'm Polish (unregistered) in reply to TomCo

    Yeah, right. Kill the testers. They're evil, they complain about bugs in the programs. It makes the developers feel bad. Testers bad! Developers good!

  • (cs) in reply to NotAnEggSucker
    Anonymous:


    Go suck an egg.


    That doesn't generally lead to good application systems.

    DMH clearly got it right - thank goodness no sensible company lets developers test their own systems or develop the user specifications.

    Some commenters get it.  For the rest, here are some clues that you need to get:

    Clue #1:  Application systems are designed for users, not developers.

    Clue #2:  Making  helpful error messages is not only mandatory, it is impossible with definition from the user community.  Proper testing teams are the only line of defense the users have, especially in a world where there doesn't seem to be any mention of user involvement in the specifications.

    Clue #3:  It is unlikely that any of you developers coders (arrogant or otherwise) would have jobs if there were no application users.  Deal with it or you will be as un-funny and bitter as Dilbert.

    The attitude of original WTF commentary was so off the mark, it is not funny.  I almost wonder if there is an unintentional obfuscation-related problem here.  Yes, it would be nice if the testers persevered past one screen so that they could REALLY nail the development team, but frankly, it sounds like they knew that the level of detail and explanation in the couple of message examples was likely to  be representative of the whole.  Yes, users are demanding.  Yes - they do not understand/know/care about stuff that you developers coders think anyone who is not stupid should have learned in 4th grade.  Sorry - that aint the way the application world is put together.

    The attitude of all you Dilberts coders proves to me why there is so much bad code in the world.

  • (cs) in reply to impslayer

    The real WTF is people assuming that just because I wrote something, I know what it does...

  • (cs) in reply to poss
    Anonymous:
    Sounds like the tester hasn't finished writing their test cases, so has come up with a spurious reason to give themselves more time.

    (Yes, seen testers do that....)

    It really looks like this. "We can't continue testing because of these problems" is really a lame excuse to not having finished their work.

  • (cs) in reply to ehabkost

    It is fun to see the amount of discussing about the problems that were reported, when the Real WTF is the "we can't continue testing because of these problems" excuse to not finish the testing work.

    The comments about giving more helpful error messages make some sense, what doesn't make sense is using these "issues" to say that they can't do their work.

  • (cs) in reply to lrb
    lrb:

    DrMindHacker:
         I am going to make the broad assumption that a good amount of the
    people who have responded negatively towards the testers either i) have
    never worked professsionally or ii) are working in a professional environment
    but don't belong (you're unprofessional) or iii) currently are not working
    professionally (hopefully because you were exposed as being the latter).

    I do not know about that.  I have seen obstructionist behaviour before.  There is no reason why a software tester could not be obstructionist.

    Yes, some of the error messages could be better, but it is not a showstopper.  It is worth a comment like: "I entered a date of 2/30/2006.  The error said that the format was wrong.  The date is invalid, but not because of the format."

    This would be a tester doing his job.

    The old saying goes, "Don't assume because it makes an ass out of you and me".  IMO, the 11th commandment should have been "Thou shalt not assume".

    BIG SNIP of excellent material

    The real WTF is IT people who don't take into consideration the bottom line when arguing how extensive feature sets such as error messaging should be.  I guarrantee you that it is strongly considered where I work when preparing our application for our Fortune 500 clients where I work.  They expect the highest value for their money, and much prefer a more detail reporting on their data than on some trivial data entry error that most of their users don't need any more info that that it's an error.


    To add to some excellent comments:

    There is also a cognitive load.  If the application has five error messages for various errors in dates, it is going to be that much more difficult to learn.  Does this really add anything of worth?  Think user-friendly.

    I support an in-house client billing system.  The warning and error messages are kept to a necessary minimum with few variations on a theme.  If a Client Code does not exist, then that is all there is to it.  There are a few areas where there are more checks because of demonstrated need.  For example, an integer dollar amount >=$100 may mean that the decimal point was missed.  Because this is important, there is a warning.  E-mail addresses are not validated at all, because it is not important.  Bang for buck.

    Sincerely,

    Gene Wirchenko

  • Dustman (unregistered) in reply to HatTrick
    HatTrick:
    Anonymous:
    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.

    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.

    Huh? What the hell are you talking about?



    Well, the date entered is for requests, which kind of implies that these are things we'd like to have happen in the future. Thus, the only reason I can see for failing the perfectly-well-formatted date March 30, 2005 would be that it's in the past. The error message, as someone above points out, doesn't mention that the date failed for reason other than format, which is entirely incorrect, and indeed so confusing that hardly any commenter has even noticed that that's what the problem is. If you're not a Doctor Who fan, nor a master of the past-pluperfect-forward-regressive verb tense conjugation, I apologize.
  • Adam (unregistered)

    These business testers are just being unreasonable.  "Do my thinking for me" in the case of the "What's wrong with this email address or date" is absurd. 

  • (cs) in reply to Dustman
    Anonymous:
    HatTrick:
    Anonymous:
    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.

    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.

    Huh? What the hell are you talking about?



    Well, the date entered is for requests, which kind of implies that these are things we'd like to have happen in the future. Thus, the only reason I can see for failing the perfectly-well-formatted date March 30, 2005 would be that it's in the past. The error message, as someone above points out, doesn't mention that the date failed for reason other than format, which is entirely incorrect, and indeed so confusing that hardly any commenter has even noticed that that's what the problem is. If you're not a Doctor Who fan, nor a master of the past-pluperfect-forward-regressive verb tense conjugation, I apologize.

     

    I believe if you go back and view the original post you will see the date has been corrected to 2/30/2005,  The 3/30/2005 was just a typo in the original post.

  • TJ (unregistered) in reply to Cooper

    Hi all,

    lots of emotion in this thread. So, heres mine :)

    I am a professional developer for 10 years now and, in my experience, if you get an email like this something is wrong that no coder can fix.

    My 1st assumption would be that the clients either wants out of the contract or is trying to bargain with me. My 2nd thought would be that, maybe, he just has a bad day and needs to let of some steam.

    In either way what you do is pick up the phone and talk to him.

    Apparently not even a bunch of professional can agree on how to do something like validating an email adress. So theres work to be done here communication-wise. (Either with the client, or as probably in this case, with your laywer)

    Anyhow, theres a good chance that hes a "bad client" and if theres anything to learn from this is to better check out who you're working for next time.

    Probably theres another company better suited for him. Business is so much about clicking, it's scary sometimes.

    There are milliones of coders out there and milliones of customers. Each have there own style of doing things. For me good projects have always been where those styles matched.

    Oh, and if he would have been someone I paid for to test my Software I would have fired him faster then he can say "procrastination".

    To pull of a project you need people that don't just do as you tell them, but also see what needs to be done. ("There's a bug. I write that down. There's the same bug again. I write that down again. There it is again,... this is getting to much work, I make it someonelses problem." vs. "Ok, let's make this thing bullet proof. Ok, that's the same bug all over again. I write that down, send it over and work on somethingelse in the mean time")

    TJ

  • (cs) in reply to Anthony
    Anonymous:
    GoatCheez:
    Oh yes, of course, how stupidly retarded of me. Let me rework all of my code and center it around completely 100% retarded monkeys. Let me make sure that my verification code is five billion lines wrong and littered with stuff that will check stuff like:

    (assuming we are using internet only e-mail)

    Given:
    [email protected]n
    Response:
    con is not a valid top-level domain name.



    That would be bad even if it was cheap to do. New top-level domains do appear from time to time, like the new .eu and proposed .sex domains. Not to mention cases like .co.uk<o:p></o:p>

    <o:p> </o:p>Attempting to enumerate all valid email address suffixes and disallow all others will just create ongoing maintenance work, and sooner or later it won't be done and your system will fall into obsolescence faster than it has to. <o:p></o:p>

    <o:p> </o:p>
    Not to mention that very few things piss me off as a user more than a system that won't accept my perfectly valid input.<o:p></o:p>

    <o:p> </o:p>
    In short, it's extra work,  and makes the system less flexible.<o:p></o:p>



    Ever hear of sarcasm?
  • (cs) in reply to GoatCheez

    Having done some testing of other peoples' designs in the past, once a few silly/trivial/obvious faults are found, it is really tempting to then try to break it as hard as possible. And really satisfying when you do...

    Not big. Not clever. But fun!

  • (cs) in reply to Cooper

    Cooper:
    Anonymous:


    Go suck an egg.


    That doesn't generally lead to good application systems.

    DMH clearly got it right - thank goodness no sensible company lets developers test their own systems or develop the user specifications.

    Some commenters get it.  For the rest, here are some clues that you need to get:

    Clue #1:  Application systems are designed for users, not developers.

    Clue #2:  Making  helpful error messages is not only mandatory, it is impossible with definition from the user community.  Proper testing teams are the only line of defense the users have, especially in a world where there doesn't seem to be any mention of user involvement in the specifications.

    Clue #3:  It is unlikely that any of you developers coders (arrogant or otherwise) would have jobs if there were no application users.  Deal with it or you will be as un-funny and bitter as Dilbert.

    The attitude of original WTF commentary was so off the mark, it is not funny.  I almost wonder if there is an unintentional obfuscation-related problem here.  Yes, it would be nice if the testers persevered past one screen so that they could REALLY nail the development team, but frankly, it sounds like they knew that the level of detail and explanation in the couple of message examples was likely to  be representative of the whole.  Yes, users are demanding.  Yes - they do not understand/know/care about stuff that you developers coders think anyone who is not stupid should have learned in 4th grade.  Sorry - that aint the way the application world is put together.

    The attitude of all you Dilberts coders proves to me why there is so much bad code in the world.

    1. Commercial software applications are developed with extremely few exceptions to serve a business need.  Their purpose is to serve this need in a more economical manner than feasible without the application.  They are not designed for end users, nor for developers, nor for testers.  Although all 3 groups and others as well do factor into the design.  But commercial applications are developed 1st and formost to meet a business need and are constrained by available resources with money being one of the most important resources. 

    2. Making error messages is not mandatory, but it is a good idea.  Without at least some level of error messages, almost all applications will cost more and perform less than with them.  However there is a level when adding more descriptive error messages begins to fall into the rim of diminishing returns and is no longer positive factor in ROI.  Usually with most commercial applications that point is reached long before reaching the level requested by the testers. Proper testing is only one of many, howbeit a very important one, possible ways to insure a usable application by the end user.  Hard to mention user involvement in the specifications when the only artifact is a partial email from tester to developer.  Just because there is no specific mention of you having a brain in  your post by no means should imply that you don't.

    3. It is a rather bold and unsupported assumption to say most programmers wouldn't have jobs without end users.  Since all programmers, at least that I know of, are end users of at least one application, they wouldn't exist themselves.  Certainly without computers there would be no programmer jobs or end users.  Most western societies would be greatly changed.  There are a few primitive societies in the world  which would not be greatly affected, but that would be by and large an exception.  To maintain our society the end user and the programmer are very important to each other.   Things that provide more efficiency to the programmer, usually end up with the user having more and better features.  The less hand holding that end users require to be programmed in, the more features that programmers can provide the end user with. 

    Bottom line, is focusing large amounts of resources to programming to meet the expectations for the 20% most inept group of end users comes at the expense of providing features of little to no value for the other 80% and delaying or canceling features that would be of high value to this 80%.  IMO there is rarely a business case to support providing the level of error messaging being requested by the testers.

  • (cs)

    All I can say about this is welcome to real enterprise development.

    If your programmer didn't pay attention to usability in the error messages provided, the entire system deserves to be shoved back in your face.

    After receiving feedback of this nature from *numerous* customers on *numerous* continents, the interfaces that we write for the company I work for *all* have this sort of behaviour.  If an e-mail address is not in the correct format, there's a Javascript validation function that tells the customer what is expected, and what is wrong.  If the date is invalid, there's a Javascript validation function for that too.

    It's certainly not a WTF for the customer to require appropriate and usable error messages to come out of the system.  Usability is a big part of good programming practice.

    It's disappointing that this wasn't posted as a WTF the other way around.

  • Dustman (unregistered) in reply to lrb
    lrb:

    I believe if you go back and view the original post you will see the date has been corrected to 2/30/2005,  The 3/30/2005 was just a typo in the original post.



    Indeed, so I see now. I suppose then, the lesson is that I shouldn't place real comments until the testers have worked the bugs out of the original post with their test comments. :) What fun!

    Anyways, to sum up: testers, developers, and managers seem to be working hard in this case to make sure nothing works. :( What fun!

    And the real WTF is that in space of a few days I've been corrupted so badly that I can't just take a WTF at face value and laugh. Instead, I poke holes in it like everyone else. How did it come to this?
  • (cs) in reply to baldheadedguy
    baldheadedguy:

    After receiving feedback of this nature from *numerous* customers on *numerous* continents, the interfaces that we write for the company I work for *all* have this sort of behaviour.  If an e-mail address is not in the correct format, there's a Javascript validation function that tells the customer what is expected, and what is wrong.  If the date is invalid, there's a Javascript validation function for that too.

    It's certainly not a WTF for the customer to require appropriate and usable error messages to come out of the system.  Usability is a big part of good programming practice.

    It's disappointing that this wasn't posted as a WTF the other way around.


    Descriptive, useful error messages are crucial, yes.

    But if your web page or application refuses my e-mail address because it ends in ".info" or ".museum" or ".tel" then you can be certain I will not try to use your product a second time.  In fact, you can count on my submitting your program to this site as a WTF.

    Customers are not tech savvy (in 99% of cases), and they won't be aware of such things.  It is our job to inform them that a requirement like "must be .com or .net" will cost them business.  I'd also argue that it is our ethical responsibility to avoid fragmenting the Internet through such actions as locking out ".info" users.

    As for validating e-mail format in Javascript... I hope you read all of RFC 822 before concluding that you knew what the "correct format" is.  And all the RFCs that supersede or amend it.  Respect for that specification is the difference between a professional product and a toy.
  • Anonymous (unregistered) in reply to ammoQ
    ammoQ:
    Anonymous:
    in my country you can always read birth date from social security numbers,


    Austria?

    Yep!

  • (cs)

    Ok.

    After all this discussion,

    <FONT face=Arial size=6>WTF is the *real* WTF?</FONT>

  • (cs) in reply to Jeremy Lakeman
    Anonymous:

    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.



    Why would anybody need to know what an email address should contain?  They know what their email address is, and if what they typed is invalid, it's obviously not their email address, so all they need to do is change what they typed to their actual email address.  Problem solved - nobody needs to know any rules.
    And seriously, who is going to include comments in their email address on a web form?  There's no need to worry about nested parentheses or any of that crap.

  • (cs) in reply to ParkinT
    ParkinT:

    Ok.

    After all this discussion,

    <font face="Arial" size="6">WTF is the *real* WTF?</font>



    Good question.

    The fact that this was posted implying that the testers were at fault for their pissy attitude is my vote......
  • (cs) in reply to ParkinT

    <font style="font-family: verdana;" size="1">

    ParkinT:
    </font>

    <font size="1">Ok.</font>

    <font size="1">After all this discussion,</font>

    <font size="1">WTF is the *real* WTF?</font>

    <font style="font-family: verdana;" size="1">



    <font size="2">Let's see...</font>

    </font><font style="font-family: verdana;" size="1">

    After receiving feedback of this nature from *numerous* customers on *numerous* continents, the interfaces that we write for the company I work for *all* have this sort of behaviour.  If an e-mail address is not in the correct format, there's a Javascript validation function that tells the customer what is expected, and what is wrong.  If the date is invalid, there's a Javascript validation function for that too.

    </font>
    <font style="font-family: verdana;" size="1">
    <font size="2">The fact that they're using Javascript, of course.

    </font>    </font>
  • Mark H (unregistered) in reply to R.Flowers

    The WTF is that the client is trying to annoy the developers. They can't possibly be serious that because the first screen fails on [rather dubious] negative tests that they can't test the other screens. You should positive test the entire application before you even begin negative testing.

    The software does have a misleading error message, but that's only a small WTF.

  • (cs) in reply to ParkinT
    ParkinT:

    Ok.

    After all this discussion,

    <font face="Arial" size="6">WTF is the *real* WTF?</font>


    Your guess is as good as mine :)

    But seriously, how did so many miss it was the customers that did the testing (acceptance test?), on a deployed application? Or am I even worse at english than I thought? Or has Alex been tampering with the original post even more than usual? Who's on first base? WTF??? (He's on third base!)
  • (cs) in reply to ParkinT
    ParkinT:

    Ok.

    After all this discussion,

    <font face="Arial" size="6">WTF is the *real* WTF?</font>



    The gap between the testers' expectations and the developers' understanding of the specifications.
  • (cs) in reply to Gus
    Anonymous:
    I actually had a problem with a user trying to enter 2/29/2006 as a date for an event in our system. The error message raised by SQL was "Invalid Date", but the user, a reasonably bright person, couldn't figure it out.

    2/29 would be a valid date in 2004, 2008, etc., but not in 2006.

    I'm not going to build an error handler for that one, since the error was already as clear as I think would be appropriate anyway. User just needed to look at a calendar.

    But telling the user the date isn't in the correct format will cause problems and if you don't way to have the expense of free support calls from your end users, making the software tell you difference between misformatted dates and invalid dates would actually save a little time and expense.

    Spending an extra few hours/days in the development stages to build in more detailed, friendly error messages for end users can save a lot of time and money that will otherwise be spent on support calls later. It's all about the return on investment.



    if someone is so stupid as to resort to calling my company to ask us why 2/29/2006 is not a valid date then they are probably to stupid to have enough money to actually buy our software.... therefore I would assume they have stolen it and I was prosecute them.  programmers do need to give helpful error messages but they don't have to assume that the people using their programs won't know the concept of a month and how many days there exist in each.

  • (cs) in reply to KenW
    KenW:
    The WTF here is that the error messages were meaningful enough.
    Please, never ever do any work for me.  Heck, do us all a favor and get out of the industry now.  You'll never deliver an application which is usable by the population at large.  The error messages were most emphatically not meaningful enough.
    lrb:
    Bottom line, is focusing large amounts of resources to programming to meet the expectations for the 20% most inept group of end users comes at the expense of providing features of little to no value for the other 80% and delaying or canceling features that would be of high value to this 80%.  IMO there is rarely a business case to support providing the level of error messaging being requested by the testers.
    Ditto.  If you're only providing an application which is usable by the geekiest of end-users, you have added negative value to the business overall.  Go home.  No business needs you. Let a programmer who knows what a real business demands do the work, while you go play some more kiddie games or whatever it is you need to do for entertainment.  Quit dragging down the economy for money that you don't deserve.  Maybe some geeksquad will hire you to fail to provide answers to other geeks, but apart from that this is a lost cause.

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

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article