Realtor.com’s tech team does regarding this issue:
Given that they’ve updated the application since I wrote that post last month, no doubt someone was free to mark the defect RESOLVED – OBSOLETE.
Yeah, it works now, but is that because it was fixed or because Monkey #9897876222 of Infinity hit the right key?
One of the basic things you need to do in QA is do things your Web application wants you to do wrong. For example, take a list of controls and enter data in them in the wrong order. If the application is Spocklogical, that is, only half logic, it will behave like the Autoconnectionz make and model selector when you select the model before selecting the make:
If you select a model, such as a Malibu, and then select the make of Mazda, it craps out because the two don’t match and the application cannot handle it.
Because nobody but QA or Isarian would try that. But I understand he’s testing a lot of software these days.
Maybe it’s an add for a detrigonometry position.
What kind of company wants desiners?
The kind of company that has a desgin process and works on brand indetity:
And that lacks a standard for presenting Web site as one word or two:
That is to say, ultimately, a company like all the rest.
Too many cups of coffee may increase the likelihood of hallucinations, such as hearing voices, researchers here found in a study of university students.
Having the equivalent of eight or more cups of instant coffee a day tripled the chance of having heard a person’s voice when no one was there compared with less than a cup a day.
That probably explains why they thought the code worked when they checked it in at 4am the day of the demo, doesn’t it?
This could also explain some project managers’ beliefs that the project is on schedule.
It does not explain anything about QA, however. Those voices we hear aren’t hallucinations. They’re actual demons, man.
Most recruiters don’t have to deal with a job listing crashing under load. This one should have.
The chance to be the caretaker of a tiny tropical island in Australia has sparked so much interest around the world that a rush of applications crashed the website advertising the post.
The job, which offers a salary of $105,000 to spend six months on the Great Barrier Reef island of Hamilton, has been inundated with hundreds of thousands of prospective candidates.
A simple little site, probably not worth load testing at all.
I suspect that the salary is in AUD, not USD, so imagine I’m making my obligatory foreign currency joke here.
The venerable Adobe Acrobat Reader PDF file interpreter plugin and application. You never even gave it a second thought, did you? Well, eWeek identifies some of the other plugins that have risen once Adobe turned the standard loose on the world:
Just about everyone uses PDF files to some degree: You have to be able to read them on just about any device, and the ability to write PDFs is common in most organizations. Yet security problems with Adobe’s Acrobat and Reader programs have been fairly common and are actively exploited in the wild.
One thing you can do to protect yourself is to switch away from Adobe products. Since Adobe published the PDF spec many years ago, numerous companies have developed their own software to read and produce PDF files.
Because many more desktops will run the free Adobe Reader program than the for-pay Acrobat program, eWEEK Labs decided to put Reader up against some of its rival free “viewer” programs: Foxit Software’s Foxit Reader, Tracker Software Products’ PDF-XCHANGE VIEWER, CoolPDF Software’s CoolPDF, CAD-KAS’ CAD-KAS PDF Reader 2.4 and soft Xpansion’s Perfect PDF Reader 5.
During tests, I didn’t see any meaningful misrendering of documents using any of these products, although it’s entirely possible that subtle differences eluded me. (Automation of testing of rendering fidelity is difficult at best.) I focused tests on a selection of 10 PDF documents found on the Web that used a variety of PDF features, including scripting and advanced form capabilities.
After testing was completed, I’m not so anxious to dump Adobe, as all of the programs tested provided reason for concern. Perhaps responsibly managing the vulnerabilities in Adobe products is the best solution.
That is, they’re most buggy when you do anything complicated with them like forms and whatnot, and they don’t protect document changes even if you’ve specified the PDF file should.
I don’t imagine that this will make it to the top of your testing checklists, but you probably ought to know about it and bring it up in your comprehensive risk conversations.
What happens when you put a form on a ColdFusion page and don’t check to make sure someone entered a valid e-mail address? This:
Seriously, checking validation on Web forms should be the first thing you do, hey?
“Cyber Millennials” Are Drinking, and Working Out, More Than You Are:
The curious fact is that members of the Cyber Millennials demo are otherwise healthy-habits role models. They have lower smoking rates, they exercise, they eat organic foods, they clearly don’t think downing tequila will turn their drink into diamonds, and yet, many of them are drinking decidedly unhealthy amounts of alcohol. Authors of the study suggest that the high drinking rates are carrying over from the late teen and college years, where drinking rates are known to be out of control, especially at “party schools”. They add that because Cyber Millenials have good incomes, they have the cash to buy round after round at the bar, or case after case at the liquor store.
These kids are also your software developers and graphic designers, which explains a lot.
A couple of years ago, some programmer wrote a thoughtful piece called Why a Career in Computer Programming Sucks. Although I would obviously have characterized it somehow to include the insinuation that computer programmers themselves either suck or are stupid to get into an industry that sucks, I think he’s quite well explaining some of the foolishness and flaws within the discipline.
I would, however, like to dispute this:
In order to escape a job where the future is bleak for older programmers due to the rapid depreciation of computer programming knowledge capital, computer programmers face the need to move up to management or likely wind up as underemployed fifty-year-olds, only suitable for lower paying IT jobs like “QA” because they no longer know how to use the latest and supposedly greatest programming tools.
Brother, some of us in QA are not programmer retreads or wannabes. We’re in QA because we’re just plumb weasel-mean.
Otiose. Ineffective or futile, superfluous or useless.
Bonus QA style points if you actually use it as a defect status in your bug tracking system.
So, suppose you’re on Toshiba’s accessories store, looking to replace a lamp for your big screen television. Using the indexing system they provide which lists lamps by the lamp part number and not the television model number, say you eventually click the one that fits your television. You add it to the cart. And the helpful suggested sell feature from the off-the-shelf shopping software asks you:
Have I considered adding to my order a lamp part that does not fit my television? Why, actually, thanks to your poor organizational skills, I probably have already.
Thanks for less than nothing.
It’s a simple Flash widget, with simple actions. When the user mouses over a word or the line beside the word, the panel to the right displays the associated word and its poll values and the word itself displays in bold font. Simple, right? Apparently not simple enough to get it right.
Here’s what the Flash widget looks like:
Notice that if you mouseover the line beside Confident or the corresponding percentage, it displays the panel to the right correctly. However, the word Confident in the table flickers between bold and normal font.
How many test cases would you need to make sure this worked right? I mean, mouse over each, check the data, check the altered display state. It takes a couple of minutes to do it, a couple more minutes if you’re wise enough to check it in other versions of Flash and without Flash installed (to check the page layout).
However, the people behind this page did not test it adequately or at all. And they bollixed something simple.
Remember, not all typos have monetary value you can trace to it, but each one in your application or Web site is a drip that accumulates in the mind of your users, and eventually one small typo will make that user stop trusting your software even if it works otherwise.
In the meantime, note that the dollar figure mentioned above is Canadian dollars. Someone clue me in to current exchange rates so I know which way to direct my punchline to the required joke.
Here’s one of those floating layer things on a magazine Web page, and it drove me nuts:
If you cannot spot the problem right away, maybe you ought to be in another line of work. Training in meeting notes gathering and in planning compare little to the power of keen observation in this business.
I’m sure I mentioned before that I was an actual ink on paper printer before I got into the tech business. As such, I am used to lining registration marks dead on and to adjusting perforating wheels 1/8th of an inch by eye. So let me brag of my unique abilities, again.
Might have been a browser compatibility issue, might have been a window sizing issue, but there it was, the first thing I saw.
In a recent column, Larry O’Brien displays a healthy skepticism of rich Internet applications:
Personally, I like native clients on the one hand and hyperlinked text on the other. I understand that this is as philistine as insisting there is no finer food than pizza, but I like process lists and taskbar icons that map directly to specific applications. I like hypermedia as the engine of application state (the fundamental philosophy of REST) and feel confident that if an application is built with such an architecture, it can be tarted up with whatever effects are in vogue.
Part of the reason I don’t like DHTML-based applications is, undoubtedly, too much knowledge of what goes into the sausage. With Internet Explorer’s loss of total market dominance, every release of a browser application has a constant pitter-patter of browser incompatibility flaws: the popups don’t work with Firefox, the text wraps in Chrome, the sliced images don’t look right in IE. I find those defects demoralizing; when I see a burndown chart flattened out because we can’t make rounded corners look right when the page scrolls or somesuch, I feel like we’ve barely progressed since the days of making windows on 80×25 screens with ASCII “line drawing” characters.
A bigger part of why I don’t like browser-based applications, though, is that for all the surprising capability of DHTML and CSS, as well as the recent arms-race in JavaScript performance, there are still huge performance benefits to be had from a local application running at full speed on the Common Language Runtime and with reasonable access to local resources. And, darn it, there are some times when you just need to draw an actual graph.
Just so.
It’s the knowledge of those gaping flaws that makes testing the damn things so frustrating. It’s the ignorance, often willful, of those gaping flaws that causes organizations to produce so many of them, many of which are crap because they don’t work whether tested or not.
You are currently browsing the QA Hates You weblog archives for May, 2009.
