Apparently coalition forces have been setting up decoy polling stations in Iraq. This is clearly the height of idiocy... as Bruce Schneier pointed out on his blog, this will either result in everyone knowing that these places are decoys, or in everyone not knowing - in which case, it doesn't matter to the insurgents which are decoys and which are not.
Of course, there is an additional effect of this practice. It will undoubtedly weaken the confidence of the public in the electoral process. How do you know that your vote was not cast at a decoy? How many decoys were there? Were decoys placed preferentially in areas that disagree with the resistance? It's not unreasonable to ask if perhaps the whole election was indeed a decoy.
Every now and then I get bored. One way I enjoy killing off time is by digging around TinyURL by modifying URLs and seeing what people have found interesting enough to compress. Among the 404s and forwarded news clippings, I sometimes find hilarious sites, otherwise orphaned pages, heated Usenet flamewars and everything else imaginable.
Every once in a while, I'll come across personal information that was probably intended only for the recipient of the link. I guess some people just never think of privacy.
Mike Clark has posted a nice little video that shows CruiseControl in action. I really want to build a system like this at work. I also want to tie the test cases and their status into a burndown chart so that test status can be ascertained at a moment's notice.
In today's post, we're going to look at something every tester should be watchful for: bad error messages. This one comes from a well known RDBMS system's GUI admin tool. Without going into too much detail, one essentially does this:
1. Run a query that retrieves results. 2. Modify a result in the middle of the result set. 3. Close the window.
What happens?
At this point, if you're anything like me, you utter a few unspeakable syllables followed by: "Firehose Mode? Firehose mode?! What the @#%! is Firehose Mode??"
And therein lies the problem. This is a bad error message because it doesn't tell the user anything he or she needs to know.
A good error message explains what caused the error, why the operation cannot be completed and how the user can get the application to do what was intended.
This is an acknowledged problem with the product. We're going to need the information in that support article when we rewrite this error message. What we're seeing here is clearly an API-level message that has somehow gotten into the finished application. It's a perfectly fine error if you're producing a database library. It's unacceptable in an end-user application.
What went wrong? The app tried to write to a cursor and it failed. Why won't it work? "Firehose mode" doesn't support writes mid-stream. How can the user fix it? Scroll down to the last row before making the change.
How about
"Your change has not been written to the database due to limitations in the way this application communicates to the database server. To make your change, scroll to the last row in the results and then try again."
I've had an idea brewing in the back of my mind for a response to the eXtreme Programming philosophy of "no manual tests" for some time. I disagree with the lack of manual testing for a few key reasons.
In terms of testing accessibility, simulating real-user use of the system, and detecting some types of events (ie: sounds), automated tests can be time-consuming and difficult to write - especially if one is working from a black-box or purely functional level. I believe that a test is worth automating if it is going to be run more than twice. This law of return does not hold for some UI tests. You can often spend many hours writing test code to verify something that can be ascertained visually in a matter of seconds. Automation is only worthwhile if it saves overall human effort.
In XP, the problem of vague requirements does not exist, as the customer is always on-site for consultation. Writing automated scripts exercises the application carefully and ensures that each piece works as intended along specific paths. What it does not do, however, is act like a real user. When real users finally begin to access the system, they may find that the on-site customer did not understand their requirements, or that the system will be used in novel and unintended ways once its power has been realised. A manual tester, combining real-world exploratory testing with expert knowledge of user interface design, can help to detect some of these issues before they become a reality.
The most compelling reason to have manual tests is that automated tests cannot detect the presence of bugs; they can only prove the absence of specific defects. When an automated test case reports a pass, we know that the application has no bugs in the fields examined along the path specified. This is a highly valuable activity, but it does not find new bugs. If an automated case fails, it is up to a human tester to characterize if the failure represents a bug, or a script problem, or a misunderstanding of the person writing the test. A human tester, on the other hand, can immediately detect bugs along novel paths. He or she can see an unexpected change and follow up by constructing new tests on the fly to force counterintuitive bugs to the surface. A human tester can explore the system. An automated tester can only prove that it saw what it expected.
There is a place in the development cycle for both automated and manual tests. Automation, particularly in the unit test phase, can provide excellent feedback by proving that certain bugs do not exist. Manual testers can bring their intuition, experience and expertise to the application to find what is truly unknown. Where automation gives us reliability and repeatability, the human tester gives us creativity and intelligence. All four of these attributes are necessary if a software project is to succeed.
The Locksmith drama that I mentioned in The Importance of Professional is finally over. If anyone is looking for a locksmith in Toronto, I'd recommend AAA Emergency Lock services (call 416-536-4079) and notAvailable Locksmiths (who are so available because they don't keep their appointments).
My little sister sent me the link to this video (mirror). I had to post it... too funny. It's the facial expressions that do it for me!
The song, of course, is Dragostea din Tei by O-Zone, a surprisingly well-known europop band out of Romania (although they're Moldovan). The title is loosely translated as "Love Under the Lime Tree." And yes, this is better than the original video (in which they dance on the wing of an airplane while the jet engines turn into giant speakers).
I'm usually a big fan of the CBC. They provide accurate, unbiased and generally dispassionate news coverage that makes my scientific mind and liberal heart (note the small "L") very happy. Today, though, I am disappointed.
Up to 470 Vancouver heroin addicts will take part in a North American first – a study that will give free heroin to junkies.
Why are drug addicts "junkies?" If drug dependency is, as all the evidence seems to suggest, a biological condition requiring clinical treatment, then why is it OK, in our PC society, to call someone a "junkie?" Imagine what would happen if the CBC ran a line like "giving retards a place in society" or "providing a home for senile citizens" or even "finally giving a real option to lardasses everywhere?" There would be outrage! Each of these examples is demeaning to people who have biological differences from the accepted norm.
The current HTML specification contains, in my opinion, a perfect example of an inconsistent interface. Consider how one places radio buttons and dropdowns on to a web form. Conceptually, dropdowns and radio buttons serve exactly the same purpose; they allow the user to pick one (and only one) item from a list of choices.
To create a dropdown, you write something like this:
This block of code generates a dropdown that looks like this:
You can then talk to this control from your web application by referencing the value of the "mycontrol" field. Details of how this happens vary from implementation to implementation.
Having seen this, I would immediately assume that to create a set of radio buttons, I would do something like this:
From the point of view of the application receiving the data, there is no difference between radio buttons and dropdowns. Either way, the webserver will tell the application "the user picked value X for field Y." So why are there two interfaces to do exactly the same thing?
The answer, of course, is that dropdowns and radio buttons are layed out differently on the screen. A dropdown is always a nice, tight, predictable package that fits into its little rectangle. Radio buttons, on the other hand, can be spread out all over the place on a page. Sometimes they're in a tight group horizontally, vertically, or in a box. Sometimes they're spread almost randomly across the page.
This annoys me because I'm writing an HTML Parser for my Random Walker (more on this later) that needs to understand the controls and doesn't care about the layout. This effectively doubles the amount of work I need to do to handle these (conceptually) identical cases. If I were to remake HTML, this would not be an issue - there would be a separation between what the controls do and how they are presented to the user. I think every application should strive for this separation. User interfaces are much more varied than just a screen, mouse and keyboard. What about test or automation scripts? What about screen readers for the blind? An application should be able to speak to a wide variety of interfaces.
How do screen readers handle HTML radio buttons? Dropdowns are easy. I'm sure they say something like "Please choose one of the following options: [...]". Radio buttons, on the other hand, could be totally chaotic. "You have this option... there might be more later."
