- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
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.
Admin
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.
Admin
Oh, I don't know - "[email protected]"
is slightly less helpful than "[email protected] (John Smith, my manager)"Admin
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.
Admin
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...
Admin
Sure. That'll be $250,000, please.
Admin
While I appreciate that someone thought this up, wrote it down, and most likely tesated it, all I can think of is: Gaaaaaaaaaaaaaaaah !!!??!?!?!
Admin
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.
Admin
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.
Admin
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.
Admin
::facepalm::
Admin
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.
Admin
"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."
Admin
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.
Admin
The One True Email Regex.
Admin
"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.
Admin
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]
Admin
Bravo. Well done.[Y]
Admin
Assuming of course that the system does not just eat emails instead of bouncing bad ones back.
Admin
WTF? You have no idea, do you? Just plain clueless.
Admin
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 a@b@d@.@.@" 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"
Admin
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).
Admin
Well it's not like anyone actually uses explicit routing anymore.
(right?)
Admin
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...).
Admin
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.
Admin
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.
Admin
You need the video in order to read their lips, since they are speaking with a lisp...
Admin
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
Admin
That's one Helluva emoticon.
Admin
You forgot .museum, .info, .biz and all the country codes! You also need a button that says "more dots"!
Admin
Admin
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 user@domain. 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.
Admin
You also need a button that says, "more cowbell"!
Admin
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
Admin
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.
Admin
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'."
Admin
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
Admin
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.
Admin
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).
Admin
Ha!
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."
"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.
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?
Admin
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.
Admin
that's an official "pebkac"
Admin
143 responses (or replies or whatever) and you beat me to it... DAMN YOU! [:P]
http://en.wikipedia.org/wiki/Pebkac
Admin
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.
Admin
Admin
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...
Admin
more cowbell!
Admin
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".
Admin
Did anyone notice that this memo came from a USER, not a tester!
"those persistent users can find a bug hiding in any corner"
Admin
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