- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- 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
The problem wasn't the messages were terse. The problem was the manual tester couldn't figure out a way around them. They were a symptom of a show-stopper bug.
The developers must have memorized a sequence of specific keystrokes, and ran these over and over again, to get back to the point in the code where they were developing.
Admin
Anonymous Bob said:
Woah, did the forum software just misinterpret those at-signs as being e-mail addresses? This may be one of the coveted Self-Referential WTFs...
----
Yes, the regexp was something like \ .@. wich is to simple even for this forum.
Admin
Do NOT use regular expressions to validate email addresses, unless you are CERTAIN that your regular expressions catch ALL possibilities. For example, http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html
It's much easier and safer to validate that there's an @ in it.
Admin
Actually it does. The program doesn't know what date the user is trying to enter, but since the program has in fact rejected the attempt, it certainly knows at some level why it is being rejected. This reason may or may not match up with the user's intention, of course, but as I read the original memo to the developers, they are being asked to display that reason, not what the user should do about it. Now, whether or not that reason has been passed up the stack to the interface level instead of just the simple "PASSED/FAILED" status being returned has to be taken into consideration, but I can certainly see why the customer would want to see that data.
I see no excuse for holding up testing, though.
Admin
umm... under windows XP... it even tells u 'Network cable unplugged'.... see... Microsoft CAN get one thing right.
but lets leave it there.
Admin
Matching nested parens cannot be done with regexes (actually, only arbitrary-depth nesting; if there's a finite upper bound on the nesting depth, it's okay) -- I thought this meant you were wrong, because WTF would they allow comments to be nested? But then I checked the RFC at http://www.ietf.org/rfc/rfc0822.txt?number=822 and found (section 3.4.3):
Sigh. So...
foo(blah) [email protected] is valid and equivalent to [email protected]
foo((blah) bar)@domain.com is valid and equivalent to [email protected]
foo((blah) [email protected] is invalid
(the last two being the opposite of how C-style slash-star comments work).
The only reason I can think of for them to have specified this behavior is if they specifically wanted to make it impossible to validate addresses with a regex. We might even conclude that (drumroll)...
The real WTF is RFC0822, section 3.4.3!
Admin
While it'd be nice to trap for all invalid emails, it's not that easy, or worthwhile. For example, how could you possible trap "[email protected]" as an erroneous email address. This is why many web forms have you type in your email address twice. Because doing so usually makes you realize if you typed it in incorrectly the first time.
The date thing is a problem. When I work with clients, I ask them how deep the date-checking abilities should go, then give them what they ask for.
Admin
I don't see the problem here with the testers' comment about ambiguous error messages with dates, although he/she has gone a little too far in-depth of what kind of message should be displayed.
There's a difference between "The value you have entered is in an invalid format. Dates should be entered in the format MM/DD/YYYY." and "The date you have entered is invalid.".
That's not exactly saying "There are not 30 days in February.", it's simply letting the user know that the error is in the date itself, not the format in which they have entered it.
As for email addresses, I think the only checking should be that it contains a single @ symbol and does not contain invalid characters such as a colon or semicolon. There are many formats an email address may take, but they are the general rules which all must adhere to.
Admin
Man. Haven't you ever heard of loop back email validation.
Admin
Bug Report:
Our testers tried clicking everywhere for about 20 minutes and only saw the same black screen. Luckly a tech guy walked passed, and told us to turn on the computer, or we would have been stuck for hours.
This will be very confusing to users...if someone tries to use the mouse for more than a moment or two when the computer is off, please print an error message to the screen that tells them to turn it on and where the switch is.
We need this resolved so we can continue with testing.
Admin
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.
Admin
This QA guy is pretty reasonable. I've dealt with a QA team that would have halted a round of QA on the date bug. Then two days later they would halt the second round after encountering the email 'bug'. Their justification was that once a show-stopper was found all testing would stop. It's like an editor rejecting a manuscript one line at a time.
One IT fellow we outsourced to rejected a spreadsheet I emailed saying 'the value in this cell should be in the format AM99999 and not AK99999. If he was in the same room I would have strangled him.
Admin
Admin
Regular expressions CANNOT validate matching parenthesis (or matching symbols of any kind) where the number of left-hand symbols must match the number of right-hand. Its mathematically proven. Now, some implementations of regular expressions (such as .NET) have EXTENSIONS that do allow you to validate them correctly, but regular expressions by themselves cannot do it. There is a whole area of study called Formal Language Theory that studies these kinds of things.
Admin
Admin
Admin
The real WTF here is, that they did not use comboboxes as inputwidgets for dates.
Admin
This is actually a valid requirement. Sometimes, you are just entering an already fixed date (e.g. the expiry date of incoming goods). Doing that with a date picker is cumbersome. In other cases, you are selecting a date, where the calendar-like view of a date picker helps you to see the weekday, week number etc. of a given date.
Admin
Talk about ridiculous feedback.
Admin
Dear -- Name Withheld --,
Adding the level of error checking you require - which is not in the current specs -- would roughly double the application size, development time and, of course, the price. If these figures are ok with you, please drop by one of these days to sign the new contract.
Regards,
Sridhar
Admin
One useful skill in IT is to learn to translate from what users say to what they probably mean. In this case, the user probably means "while this application is running, the screen saver should be disabled".
Admin
If you want to go ahead and read up on regular expressions, and the finite automaton that are used to recognize them, and then read up on context-free grammars and the push-down automata that recognize them, well, that would probably enlighten you a little bit more about how you're talking out your ass.
By definition, regular expressions CAN NOT recognize matching parens. If there are some extensions somewhere to regexes that can, well fine. But that doesn't generalize to the entire class of languages considered to be regular. Really, if someone were to be able to recognize them using DFA, then they would have broken Chomsky's hierarchy of grammars. That'd be awesome, but I don't think that's likely.
Tony
Admin
Guys, you are missing the point here! The real WTF is not the program but the client who tested it! Seriously, does an error message really need to be that specific ("Duh, you've entered three @ signs but an email address can only take one")?! While the date validation could really be a bit more specific, I think that the email validation is sufficient. Well, I don't want to see the code of an AI validation algorithm which explains the error in very detail.
So the real WTF is that the client is whining about minor problems and thus stops testing.
Admin
Does anyone actually type the email address twice??? WTF???
Admin
How hard is it to add specific tests for some specific, common data entry errors, and return a more appropriate text string?
It doesn't have to be absolutely comprehensive, but it should be able to identify some of the most common problems.
Test for non-numeric input in the date ("Date must be numeric"). Test for out-of-range inputs ("Entered date of February 29, 2005 does not exist" ... clearly the application is already doing this check, but not returning a descriptive return code.). Other errors (e.g. month of "0", or multiple such errors), "Invalid date. Use format MM/DD/YYYY")
Similarly for email. Check for illegal characters. Check for the absence, or multiplicity of "@" characters. The absence of anything before (or after) the "@". ("@ cannot be first or last character.")
After the "simple" checks are passed, more general checks (with more generic error codes) can proceed.
The code is obviously checking for certain errors before proceeding. I wouldn't expect it to describe every possible error, but data validation should do better than a binary result.
Admin
:) This post made my day :)
(Or was it meant to be serious??? WTF?!?!?)
Admin
Townsend? You fag.
Admin
Some forms get clever and prevent you from pasting text into those boxes.
Admin
Yes, my post was deadly serious! It looks like the program already does the most important checks for date and email validation. I am not saying that you should not do validation, but I also think that you should not explain every possibility of mistyping an input in enormous detail.
Pseudo code:
if not email.validate()
{
ShowMessage( "Email does not match pattern [email protected]");
}
is fine with me!
Admin
Of course, that doesn't do any kind of meaningful validation. And would have let through the invalid mail address the testers used (the one with all the @ in), but blocked the valid one (which was all A's).
So, ummm. WTF?
And to the guy who claimed you can't match paired brackets with regexps, you're wrong. It's arbitrary levels of nested brackets that cause problems.
Simon
Admin
Ok, ok :) The fun (?) part was (for me) that there were about 50 posts before yours that said the same thing :)
Admin
Wipe them testers out. All of them.
Admin
Or use the favorite error message of a one-time-colleague of mine:
"Compatibility Error has occurred. User upgrade required."
Admin
Ah, ok. I was too lazy to read all previous pages :)
Btw: My Name is Sven, not Svennis.
Admin
Bah, then it's back to 'Anonymous' then ;)
Admin
The real WTF is the lazy testers using any excuse to not test.
Admin
Might as well keep on spamming... Nope, the real WTF is the lazy Eye-Dee-Ten-Tangos that don't read the previous posts before writing their own copies :P
Admin
Programming is the process of removing the bugs from an empty directory tree. The first bug in most such empty directories is that they don't produce an executable when "make" is run. Then you have to fix "the executable doesn't do anything", followed by "the executable doesn't do everything", and "everything the executable does is wrong". Eventually, you get to "some things the executable does are wrong". At that point, you should remind the user how many bugs have already been removed from the piece of crap they gave you to start from.
I disagree..
Programing is implementing as code a design. So your code match your design AND is flexible enough to adapt to changes in the design.
THEN you need to validate your implementation AND design against a real user (GAMMA tester) or fake user (BETA tester). Often this result on implementation errors, or design errors. Or changes on specifications (specification error?). So you adapt your code and your documentation; and your specifications (if needed); to fix this problems.
You will never hunt all errors If you start with buggy code. You sould try to start and continue with error-free code has posible. IMveryHO.
--Tei
captcha: grapes
Admin
I would have preferred that he added "LISY", because that's the way I always ended up spelling it on those ultraloud clickety-clackety IBM tactile-feedback keyboards.
Which makes me sort of scoff at the testers in this article; they obviously weren't raised during the era where a "helpful error message" consisted of classics like
?SYNTAX ERROR
and
Bad command or file name
and that was it.
--
$0.02
Admin
The tester's comments by themselves make sense. The improvements he suggests are real improvements, and they're quite possible to implement. Good error messages are much too rare.
However, the WTF is that these are considered such huge bugs that not only are they a showstopper for production, they even make all further testing impossible! That's just beyond ridiculous.
The tester probably didn't feel like testing that day, and looked for the first excuse to be found.
Admin
You seem to be missing the part where testers work from external demands. IE: it doesn't matter if it's "wavable" bugs for the tester IF an external quality assurance security says that "This wont pass our demands because <insert dumb reason>." I think it's fairly safe to say that the developer in this case wrote the program without bothering to make sure he met the specified standards required for the product, which is NOT the testers "WTF".
I get the /sigh feeling that most developers are under the misconception that QA people are there to make their day worse, whereas they are actually there to make sure the application under tesing passes EXTERNAL demands for product quality. This means, they are there to save the developer a shitload of time.
-Chae
Admin
I'm yet to see "a one line regex" that could check whether a given email address is valid or not (there are very few that even manage to check if the address is syntactically valid).
And, to be more on the point, I've seen some rather confused testing reports in the wild; latest example was when a multinational company complained that changing social security number of a user doesn't automatically update the birth date of that user (this needs a bit of explaining; in my country you can always read birth date from social security numbers, however, this doesn't hold water in many other countries where the said company also conducts business - besides, it was never requested to even attempt anything like that in the specification...)
Admin
I do not agree, but IMO the problem is not as severe as the testers make it seem. The error messages should be an explenation of *what* is wrong rather than just state that something is wrong.
I'll keep that in mind for further coding...
Admin
This is sooooooooooooooo true. In the company I'm currently working at, we had a young lady dedicated to project management and QA, and she took the job very seriously. Especially the QA part. Sometimes it was annoying, but it was thanks to her that so many projects went pretty well at that time. Two years ago, she was demoted to doc writing (to make place for the company owner's son), and eventually left. Since then, quality observably degraded, despite the best efforts of the development team to do QA themself (the new "project manager" is more of a MS project guy, making deadlines and stuff, but not too concerned with the actual product)
Brrrrrrrrrrrrrrrrrrrr
</insert>
Admin
Austria?
Admin
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.
Admin
All regular expressions can be implemented using a finite state machine, basic result of computer science. Finite state machines cannot check if a string with an arbitrary number of parens has all of them matching, since that would need an arbitrary number of states.
If you feel different, please show us a regular grammar for a language that contains exactly the strings of the form '()', '(())', '((()))', etc.
That said, the "regular expressions" present in modern computer languages have more features that make matching matching parens possible; but that just means they're not real regular expressions.
So you're both right.
Remco
Admin
A regular expression is a well-defined term, that corresponds both to the language it describes and the machine required to recognize that language.
The various extensions that are out there which allow some languages to match arbitrarily deep matched nested parentheses prevent those languages from having regular expressions by definition.
Admin
Admin
Who said it was deployed? I think you need to go back and reread it.