To keep spam down and whatnot, I delete a lot of new user registrations if they don’t look like they have QA names or e-mail addresses, if I don’t recognize the name, or if you don’t immediately leave a comment. I apologize if I’ve deleted your user account by mistake. This means you, Petr, for sure and maybe some others.
So if you want a user account on the site, be sure to pipe up.
An error on the Comedy Central embedded media player:
I see an error message and a number. Is that an error enumerator?
Regardless, this is a troubleshooting message. This is not a message for the user. An error message to the user ought to include some sort of instruction to the user as what he can try to recover from the developer’s screw up.
But the lazy development program that allows these bugs is also the lazy development program that doesn’t bother to include good messages.
Newspapers and whatnot seem to love their auto-refreshing pages these days just so they can get additional pageviews in and rotate ads. However, I end up opening a bunch of articles in new tabs, and the auto-refresh feature chokes the machine’s resources. If I or the offending newspaper site loses connectivity, the pages refresh themselves into “Cannot load page” messages.
Or sometimes a helpful message that my Web browser cannot handle it:
I’m running the latest Firefox. The problem lies on your end, St. Louis Post-Dispatch. And if you hadn’t insisted on the refresh, we would not have had it at all.
Check out this alert dialog box I got the other day:
It cannot believe that in 2010, someone is trying to install a Windows 3.11/Windows 95 compatible clip art browsing program that wants to use a 14,400 BPS modem to contact CompuServe on installation. I didn’t even tell it that I was a trained IT professional, which might have caused Windows Sockets to silently faint.
The 16-bit virtualization engine actually fainted dead away, which is why you cannot see its icon on the list of active taskbar items even though it’s there:
I would make some crack about the applications coming to me to die, but I’m the one who’s trying to get it to read punchcards, for crying out loud. It’s not handling the failure elegantly, though.
Remember, those meta things show up a lot of places. People see it in search results, social networking site summaries, RSS, and so on. If you’re misspelling something or dumping a null in it, that’s gonna leave its mark.
Would it hurt you to view source now and then? I think not.
It will be interesting on how this shakes out. Will it finally inspire corporations to move completely from IE 6? Or will it only add a new IE to our testing plan as the new release cannibalizes from IE 7 and 8?
A lot of management types will hope this provides a stake for the old IE 6, but I tend to think it will prove an upgrade for organizations that already upgrade.
Still, something to which you will want to pay attention to and for which you will need to account in your test plans.
A couple weeks back (which means it’s now available on the Web), Larry O’Brien covered user testing to show that development shops could actually, you know, see how users work with a software tool.
Nut grafs:
There’s a part of me that loves user testing; the same part that enjoys visiting ThereIFixedIt.com and watching videos of people destroying their trucks by felling trees on top of them. I take comfort in believing, however briefly, that there are people more foolish than myself. My source code often makes me despair of my own sentience, but I like to tell myself that I wouldn’t need to be prompted to use a button marked “search.”
My major reaction to user testing, though, is often resignation. User testing invariably reveals distasteful work—layouts that need total reworking, dead-end navigation paths, and corner cases that the library API doesn’t cover. The interesting algorithmic stuff that you developed while surrounded by a stack of heavily annotated journal articles and intently pored over on a statement-by-statement basis? That stuff works fine.
Unfortunately, the temptation to skip user testing is often encouraged by clients. While experienced developers know that user testing will lead to a certain amount of dismay, inexperienced clients dismiss user testing because they’re invariably overconfident. I don’t think many are as bad as my above-mentioned client, who was confident that word would spread like wildfire that one could cycle colors by directly clicking on the product. More generally, the problem is the opposite: Clients have seen so many mockups and prototypes and test versions that they cannot see it with fresh eyes.
Keep in mind, QA, in all the situations where your organization is too cheap to provide user testing, you have to be the eyes of the user. Designers love their cutting edge design, but applications should not make only as much sense as a Christo or Serra installation. Applications should behave more or less like all the other applications in the whole world regardless for how much disdain the developers have for the bourgeois sensibilities of users. And so on and so forth.
I just returned from a 2 week trip to Japan. One of the more familiar sights was the ridiculous number of Starbucks coffee shops, especially around Shinjuku and Roppongi. While waiting for my “Hotto Cocoa” I started to think about how Starbucks processes drink orders. Starbucks, like most other businesses is primarily interested in maximizing throughput of orders. More orders equals more revenue. As a result they use asynchronous processing.
That’s all well and good, but we here at QAHY want to extend the metaphor further.
Ways Starbucks is like a development team:
They’re very expensive for what you get.
Anything besides the basic product costs extra.
The customer is the only QA.
Those who participate believe their in a superior class, but the rest of us use the word clique.
Ways Starbucks is not like your development team:
Starbucks produces the same thing over and over again, so they get good at it, unlike your development team who build slightly different things using new technologies they want to learn on the fly. It’s like having every barrista be a trainee every day.
Barristas won’t try to adjust a drink if the order changes in midstream. They rightfully throw it out and start again and sometimes charge you again. A development team will just try to remix the existing espresso, sugar, and flavor shot so that you get hot chocolate at the end instead of a triple Venti cappuccino.
Starbucks gets its money up front and doesn’t have to wheedle and do just one more thing to get its paycheck.
You like to see a Starbucks product or representative first thing in the morning.
And in closing, I’d like to point out that management from your software development team could probably run a Starbucks, but not vice versa.
Feel free to add your own below.
(Link seen on Megan McArdle via Instapundit. That’s enough chain of custody to introduce it as evidence, werd.)
I was reviewing this user interface designed in an old technology, when suddenly I was struck by the infeasibility of the maxlengths assigned to the fields:
That’s a maximum e-mail address of 20 characters. Chop 4 or 5 off for the domain extension, the dot, and the @ sign and suddenly you’re limited to a username and a domain name of 15-16 characters. If you’re not at MSN or AOL and an early adopter at that, you’d better hope that they call you on the phone if you’ve won.
Okay, aside from that, what’s the other problem on the page?
Based on a tweet this morning lamenting the dearth of proper test plan sample documents on the Internet, I put together a sample document in PDF format that you can use when putting together your own test plans.
This does not represent a good practice of synchronizing your application data with the real world:
Twice we had ordered a pizza with extra-large pepperoni. Twice it had arrived without the extra large. See, the order is calibrated to hit everyone’s preferences, and my daughter will only have pepperoni, so: her half has pepperoni and extra-large pepperoni. But twice the pizza has arrived without.
“I’m going to call them,” I said.
“No, Dad, don’t! It’s okay! Don’t make a fuss about it.”
“Honey, a manager would want to know these things.”
So I called, and explained, and the manager asked if I ordered online. I said that I did, modern-type person that I was. That’s the problem. Extra-large has been discontinued, but it’s still on the online menu. Can you tell me what the printout on the bottom of the box said? I noted that it had elided the extra-large issue altogether. So the problem wasn’t on their end. [Emphasis added.]
This isn’t a simple change made on the fly, either. It’s a menu change determined probably by a national pizza chain’s HQ and telegraphed to its franchisees by semaphore or something. Somehow the change managed to dodge the people responsible for the Web storefront.
Forget keeping your application data synched with the other online data. Your application has to keep up with the real world, too. A lot of IT teams and vendors can rationalize not keeping up if the customer doesn’t keep up, but you need to make it easy to change and to grab your client/internal stakeholders by the lapels to ensure they keep you up to date.
James Lileks, from whose blog I took the anecdote, is a patient customer and does not blame his local pizza shop. However, another client will quit a brand for that sort of thing. Especially if that client is in QA.
So the local newspaper, the Springfield News Leader, has a little problem with its site. When you view an article that spans multiple pages, the page numbers or the next page link does not work in Firefox. This is quite the reverse of most software, which typically works in Firefox or Chrome but bombs out in Internet Explorer and the developers sniff about the hoi polloi and their attachment to the dominant Internet browser.
So I go to the send feedback form, fill out a defect report, and….
More information at Wikipedia, including the nugget that this will not replace the existing Unicode character ₨which, as I understand it, will henceforth represent Ru Paul.
So how will your application like that? I can’t wait to find out.
It offers the user the opportunity to enter some sort of contest to go to Nashville. It’s obviously a Web browser in kiosk mode, but this one has a full keyboard with a trackball and two mouse buttons. Uh oh.
So I click the Contest Rules link at the bottom and get the contest rules, which has a naked link at the top that takes you back to the form. But hover over the link and right click and…. Uh oh.
So a user has complete access to the Internet. Go where you want. Get all the malware you want. I didn’t try to see if a regular download and install worked, but I would not doubt it. What happen if I ALT+TAB?
Lookie there! Lookie there! It’s the command line. A little CTRL+C action and I have access to issue commands to the machine and maybe even the network.
So is that Cat-5 cable running out of the back of the box connected to the airport network itself or a dedicated safe portal to the Internet? Given what we’ve seen here, what do you think?
If you’re ever called to check out a kiosk application, not only should you run through the form the kiosk will host, but you should get a kiosk itself and run it through its paces and look outside the confines of the application to look for security pitfalls.
You need to check out the user interface action. This kiosk gives the user all the normal tools that users need for full input opportunity to the Internet. Some kiosks only have touchpads or touchscreens. Here are a couple of things to think about:
Know your keyboard shortcuts. Most people don’t know these keyboard shortcuts, but they do things to your active window (even your kiosked browser). What can you do with that?
Know your internal browser behavior. I remember seeing a kiosk with only a touchscreen that offered the Web sites of a building’s residents. Within a touchscreen environment, you would think you’re limited to navigating through links in the browser window. You would be wrong. mailto: links trigger the helper application associated with e-mail. What can you do when you try that?
What happens when you unplug the machine and plug it back in? It reboots, probably, affording you the ability to go into alternate bootup scenarios and whatnot. Should your user have access to that? Probably not.
To begin vetting kiosks, you need to think outside the terms of your application and think in terms of the technologies that encapsulate it. The better you understand those and can identify the ways users could interact with the whole kiosk, the better you can prevent them from doing so inappropriately.
In a side not, I am working on my screenplay for Bill and Ted’s Gnarly Career wherein our heroes become IT professionals and meet the archetypes we work with every day.