- 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 real WTF is that the developer and the tester had such different ideas of what the product should do. Are there no grownups in the shop?
Admin
You can make whatever assumptations, just what you say actually classifies YOU as one far from professional development, sorry.
Especially because you even failed to recognise that the program in subject DID the validation you talk about and did it correctly too. At least form the testing report we can't deduce a single missed case.
Bad input was rejected with a sensible message. It pointed out the place of the problem. Also let's guess the context: was it a professional program with sole purpose to take random input and provide detailed analysis why it can't be accepted as date or email? Or a Busytown-like toy program for 4-8 year old children? Or it was a form where the user shall enter the actual data he HAS in his mind. Correctly. And validation is there just to look out for typos and format mistakes.
I bet 100:1 on the second case, and in such a program simly stating the entered data is wrong is just enough, the user will read it and retype. The extra info the testers complain about is not needed. Worse, it can be more distraction than help, by the time you parse the message you'll forget what you wanted to type in.
If the specs say nothing about validation of date and email fields the professional solution is to stick with a single message. If they DO say something, the test groul should have follow those specs, and report failure by those points.
Admin
Excuse me, what bugs? Can you point ONE out explicitly?
That's the whole point, the esters in the issue did not feel like testing for bugs, instead looked for a way to drop the work after some BS comments. (Even if we consider the comments valid, they should have gone to the 'improvment TODOs and specs update' list while carry on with actual testing.
Admin
>"I entered a date of 2/30/2006. The error said that the format was wrong.
Can you people READ? Really. In the issue the message was:
"The date entered is not valid. Dates must be entered in the MM/DD/YYYY format."
My English parser says the message didn't state the format of the date was wrong. I states the date is not valid. Besides that it hints that dates shall be entered in what format, a good piece of information far from evident in general.
Admin
Many or most of us agree that saying an invalid date was in an incorrect format is a minor usability bug but that the real issue is project management (the lack of detailed, agreed-upon, requirements) and that the tester did not continue testing. (Finding bugs should be fun for a tester or they should take up a different profession.)
However, on a side note, you have a very good point. If the user is setting up a new email address, then more rigorous validation of email format, user name, and domain, along with more detailed error messages, would be required.
However, we're assuming that in this case, the user is typing in their own email address. If it is invalid, tell them so. They must have typed it in wrong (or have been given an invalid email address for some reason). Possibly verify that there is one and only one '@'. and if not, give an appropriate error message. Otherwise, give a generic error message. Possibly the error message should state that the user should retype the address. Then, instead of sitting there looking at the one they typed in, trying to figure out what's wrong, they try again and hopefully they won't type ',' instead of '.' a second time. In any case, the requirements should be written and agreed upon well, well before the tester gets his hands on the finished project. If they were, then the only problem with what the developer (assuming he followed the requirements) was the minor usability bug.
FYI, I've been a developer, QA tester, and requirements writer and have a lot of respect for people in all those areas that do their job well. I don't see a need for bashing any one type as a group. To say 'testers' are idiots and 'developers' are lazy as some have done on this post is a sign of peevishness and probably not appreciated by most of us. So, why don't you guys that do that sort of thing shut up and get some sleep.
Admin
ROFL, Paula <3 :D
Admin
>> I don't see a need for bashing any one type as a group. To say 'testers' are idiots and 'developers' are lazy as some have done on this post is a sign of peevishness and probably not appreciated by most of us. So, why don't you guys that do that sort of thing shut up and get some sleep.
Sorry for that last. It happens in every forum all the time.
I'm going to shut up now and go get some sleep.
Admin
Exactly why would you need to know which part of an email address was type incorrectly. It might be nice to be told, but that would really be icing on the cake. In 99% of cases, an email address is simply a piece of string information that is being copied from memory or from paper. You don't have to guide the user in creating a valid address, they're just typing the thing. If they get any one key wrong, it's wrong. The best possible input validation would fail horribly at finding typos. Consider this address:
[email protected]
A perfect syntactical validation routine would catch a mistype of the dot or the at sign. If any of the other 18 characters were mistyped, it wouldn't catch it. A validator that actually sends an email would result in a lot of "false invalids". If this application were allowing employees to type in contact email addresses for customers, sending a test email may even violate the CAN SPAM act.
So, to summarize, a generic validation routine isn't great, but isn't bad either. An aggressive validation routine doesn't solve very many problems and possibly violates US Federal law. If you actually need the email address to be correct, simply have the data be entered by two employees independently and compare them. Any mismatches go to a third for a tiebreaker.
BTW, how would you suggest a phone number be validated? My usual suggestion is to do NO validation on phone numbers, unless the numbers will be dialed or processed by an automated system. Why prevent these valid numbers (yes, they are all valid):
1 (212) 555-1212
2125551212
212-555-1212
1800-FLOWERS
555-1212
408-1212
+ 49 711 - 70 10 70
911
0180 - 2 34 54 54
212-555-1212 (hit * and ask for accounting)
Over-validating is just begging for maintenance problems. And, you cannot fully validate anything ever. If a person makes a mistake, they make a mistake. If you could say they were wrong/right with 100% confidence, then you wouldn't have had to ask them in the first place.
As for security and validation, that should always be handled by the appropriate widget. A web widget should prevent html escaping problems, a database widget should properly escape quotes and special keywords like "GO", and so on. Doing one-off validation for security is begging to miss something. If your existing widget doesn't do that now, wrap it in another widget.
Admin
What has already been said pretty much covers the angles, as far as I can tell. Most if not all people here agree that the quality of error messages shouldn't have been a show stopper. There is a great deal of dissonance about whether or not the developers produced error messages which were up to par, although (I say at the risk of being the next flame target :) ) implying that 02/30/2006 is incorrectly formatted seems to be generally disapproved. I personally also agree with those of you who think that the somehwat demeaning tone used by the testers was inappropriate. All in all, it seems that both sides need to be attending their faults and trying to smooth this problem out a bit.
However, there is one thing I can point out which has not yet been mentioned. [email protected] seems to be a perfectly valid mail recipient.
Admin
I had added to the end of that post the sentence:
I just tried to register it and, not surprisingly, it is already taken.
I rather dislike this post editor...
Cheers,
Zachary Palmer
Admin
You need to play the game if you want to get along. Nobody can blame you for not reading other people's minds. What about the following reply:
"Madam,
thank you for pointing out the deficiencies in the test release of our software. As you know, the specifications do not go into a great depth concerning the correct treatment of the various error conditions and the messages supposed to be shown. Therefore, to provide at least a basic form of validation initially, we used standard components for the validation of these fields.
In order to improve the perceived quality of the software we definitely require a more detailed specification. As you seem to be the person who best understands the concerns of the users, please do supply this specification in the following form:
Entered value - Error message
This specification should be given for each field in the entire application. Please provide as much detail as necessary. I beg you to send me this information asap.
Kind regards, ..."
I bet this will greatly reduce the amount of work you will have in rewriting the software.
Admin
What's the test case # that failed so we can use the matrix to find which requirement is incorrect or missing? Oh, wait, that would require a real process... DOH! stupid me.
In crappy shops, testers feel that they have to validate their existence somehow. It could simply be a power struggle and nothing more.
IMHO...
Admin
Check out identify software. It rocks for tracking what actually occured.
Admin
The fact that 90% of the people here, including you, think it's about how much verbosity can be expected of error messages. We have not enough information about that, it's a question of specification, though the testers's expectations border on the unreasonable.
The WTF is refusing to test further because of "insufficient" error messages on the first screen. That goes well beyond "pissy attitude" and into "refusing to do your job" territory.
Admin
Yes, you could shell out $40/hour to your developer to spend a couple of weeks searching out every possible scenario wherein an email would fail. Or, you could hire testers with a clue.
select * from Testers where Clue > 0
0 rows returned
Admin
In OS9 (anybody besides me recall the TRS-80 Color Computer?) the assembly language documentation showed the code for a module named "hepl". It wasn't until I had typed that very thing several times that I got it.
Admin
I agree with those who have posted before me, that this matter would be decided by the wording in a Requirements document. Error trapping will be written for every scenario the document specifically mentions. Seeing that the clients signed the document agreeing to its specifications before I started coding, the testers can eat shit if their complaints aren't in there.
Admin
Sorry, mak... I went to your link and tried to see what you were saying, but it kept being covered up by advertising, so I just gave up and closed the browser window.
Admin
Everybody knows that no developer should test his own product. No matter how thorough we try to be, we can never duplicate all the stupidity of the end user. That's why we have testers to do it for us.
Admin
Admin
Admin
Admin
Wow! A generalisation of my favourite saying "Programming is debugging the empty program."
Admin
But the error message IS correct! It read "The date entered is not valid. Dates must be entered in the MM/DD/YYYY format." which is perfectly fine. The first sentence describes the situation. The second one is additional information that simply does not apply in this case but is still correct.
Admin
For fun you should try to fill in user (mailbox) names that contain a + sign. Perfectly legal. Sendmail does useful things with it. [email protected] will deliver the mail to mailbox "name" and pass "extra" as a parameter so that a mail classifier can do something with it. But on most websites where I tried it they spuriously rejected it.
Admin
No, you can't be serious. Matching parens can not be done with regexes. You obviously never followed a computer science course. I suggest you read up about the difference in power between regular expressions and context-free grammars (and context-sentitive grammars of various kinds, while you are at it).
Admin
poor Sridhar working for the braindead people.
I will pray for your soul Sridhar.
PS: look on jobserve.
Admin
Yeah, but they also tell me that when the power plug to my switch fell out of it's socket! The bastards! Can't they get anything right?!?
Admin
So what you are saying is that the "regular expressions" that are used in actual practice, i.e. those present in modern computer languages (that are not real regular expressions, but extended versions of them), can actually perform matching parens tests to a degree, right?
In that case, the point of the original poster claiming that regular expressions "CANNOT" match parentheses is moot, as we are talking about using practical implementations of regular expressions in modern computer languages -- you know, what we actually use to code with -- not as purely theoretical mathematical models.
-dZ.
Admin
First off it would be a cold day in hell before I would knowingly agree to do any work for you. From your post it you come off as the type of person who knows just enough to be extremely dangerous, but not enough to realize it. It also appears that you might have a reading comprehension problem. I spoke of most applications programming to meet the requirement to be very usable to 80% of the target market. After this there is a point of diminishing returns for every dollar spent to make the system more usable. This is a rule of thumb that not only has been proven to be the case the vast majority of the time by my own extensive 15+ year carreer on working on major enterprise applications for Fortune 500 clients, but more importantly has been proven to be the case by hundred's of thousands of hours of research and documentation of real systems by experts in the software engineering and business fields.
Just recently I finished work redesigning the search engine of one of the most trafficed sites on the World Wide Web (top 100). the site had little if any additional details for users on errors when entering an email address or a date. The target users of the site were the general internet public in the US and Canada. Yet in an extremely competive market, that site was the fastest growing of any of the top 20 companies in it's industry while spending millions less than any of it's competitors in the top 10. (BTW the site was in the 10 in it's industry). Now I can tell you things that I would endorse improving at this company, because they like any company were perfect. However what they did great was provide a terrific and accurate business model to both predict and then measure ROI on features added. Providing the level of detail you seem to thing is needed for dates, internet email addresses, and other relatively simplistic data never showed up in the business model.
So why don't you step out of your ivory tower world and learn something about cost/benefit ratios and what the general internet public really wants most in feature sets. I guarrantee you it's not anal retentive error messages for mistakes that few are going to make besides a typo, and then will probably correct easily with only knowing what field had an error. Will 100% be able to do this? No. But more than 80% will usually be able to do so. If you want to be #1 you spend you time working on features to woo the 80% and not the bottom 20%. I'm sure this doesn't jive with your ivory tower view with your rose colored glasses. But people more concerned with implementing the best and most pratical business plan to recieve a return on investment care a lot.
And you don't need to be a geek and certainly don't need to be a programmer to know that 'MM/DD/YYY' isn't a date and that '@.@.@.@.@' isn't a real email address. People who can't get that, should be directed to an 800 number because they'll have much problems using the software than can be addressed by more descriptive error messages.
Admin
Consider this analogy: You have a bicycle. You put two more wheels on it, but still call it a bicycle. Guess what? That does not make it a bicycle.
With the extensions to REs being discussed, the expressions are no longer REs. They may be very useful, but they are not REs.
Sincerely,
Gene Wirchenko
Admin
It's trivial to use regexes-plus-a-little-code to determine whether parentheses in a string are balanced, of course.
sub is_balanced($)
{
my $string = shift;
$string =~ s/[^()]//g; # strip everything but parentheses
1 while $string =~ s/()//;# strip parentheses in balanced pairs
return $string eq ""; # balanced iff there is nothing left
}
Admin
The real WTF is the use of the rather strange and illogical American date format.
Other than that - the testers are on the ball - the purpose of error messages is to tell the user what went wrong, not give nebulous messages that don't actually say anything useful (as an example I've been fighting with ImageMagick all this weekend with useless error messages which don't actually tell you the real problem: out of memory and out of disc space).
Admin
That's not a very nice thing to say. What's his pretty smart ever done to you?
Admin
Other than the fact that you apparently aren't used to it, what's illogical about it?
Admin
You're right. I was out of line to select * from Testers where Clue > 0. I offer my sincere apology to testers the world over.
It's only the testers mentioned in the original post of this thread who are clueless.
Admin
Hallelujah, brother. Their/they're/there, your/you're, etc. It seems the bug really is in the details. Long live the pedants!
Admin
The fact that the parts are not in order of significance, which is very inconvenient for sorting.
DD/MM//YYYY is fine, as is YYYY/MM/DD, but MM/DD/YYYY is just plain weird.
But the biggest problem is that since DD/MM/YYYY is used elsewhere, you cannot tell what format a date uses just by looking at it if the day is <= 12. It is best to use the ISO standard YYYY-MM-DD when there's any chance that there will in international user base.
Admin
That is a security feature! Why do you think the US achieves surprise in so many invasions?
And don't tell me Europeans are more logical - type in "cal 1752" to see what happened when they were in charge of dates. Nor the Babylonians - you'd think they'd have picked octal or hex if they were going to deviate from decimal, but nooooo, it has to be f'ing base 12.
Admin
The French -- France is in Europe BTW -- came up with a base 10 system, commonly called "metric". It gets commonly used pretty much the world around, except for the U.S.A. The French also came up with a decimal calendar with ten months.
Sincerely,
Gene Wirchenko
Admin
France has a ten month calendar?! I'll pass that on to my Pentagon colleagues - a two month window is just about right...
Oh, hold on - it was not the calendar I was thinking of. Thermidor and Fructidor were the 11th and 12th months. Besides, the French military was pretty good back then.
Again, the refusal of the US to adopt the metric system is a security feature. Invading metrically based armies are more likely to run out of petrol or drive too fast and have accidents.
Admin
sarcasm....
Admin
LOL
There's a reason train track widths were standardized in the US immediately after the Civil War.
Admin
3-4 years ago when I was writing an email address parser that consumed input from users on the internet I found that comments were pretty common.
Admin
They did, however, have a 10 day week (with 3 weeks to the month and 5 days that ddidn't belong to any month) - which was probably the reason it didn't stick: fewer free days. There was also a plan to make a day have 10 hours of 100 minutes of 100 seconds (which would make a second only 14% shorter than with the current system), but it was never implemented because it was deemed too much effort to replace all existing clocks even back then.
Admin
I hope you're not a native English speaker. The second sentence may indeed be just a "helpful hint" thrown in there for the user, but nobody reading those two sentences in that order can possibly be expected to recognize that one is specific to their problem and the other is just general advice.
Admin
obviously
Admin
Fewer than 10% of the nonTechnical people that I know who use a PC as part of their work duties would have a problem distinguishing what was need from the error message given for the date. Of those 10%, more than 80% would get it after a 5 minutes of training. Of the remaining ones, almost no error message would suffice in allowing them to get it. If the users can't get it with the listed error message, then training is probably the best and certainly most economical solution.
I would imagine that given the size of the application in question and the apparent detailed and the apparent customized need for error messages it could easily cost well over $50,000 dollars (figured at $100/hr for time for all business stakeholders, developers, project managers, QA personnel, management, requirements analysts, etc. to derive the specifications, develop them, test them, and completely debug them to client's satisfaction: 5000 total man hours * 100/hour = $50,000) to modify the error handling system to meet client expectations. Now if the client manager who is autorizing payment for this application wishes to fork over the money, then the developers certainly should do it. However, extremely rare is the case where this is justified and even rarer is the case where a manager will agree to expend should a relatively extravagent amount of money for what will most likely be a negative ROI. BTW the $50,000 dollars does not include opportunity cost of delaying deployment and use of the application until the enhanced error messages were added and debugged.
Certainly the error message isn't the most clearest nor does it form a contract describing the desired results with vertually no room for misinterpretaion. However not very much description is needed for the vast majority of computer literate users to discern what needs to go there. It just doesn't make sense to pay for a Cadallic why a Chevy more that meets what is needed.
Admin
5000x100=50,000?
Admin
Sorry, it should have been 500x100=50,000.