QA Hates You

I don’t normally do job postings here at QAHY, but my wife is looking for a new flunky, so here are the details.

Senior Programmer Analyst

Exits, Inc. is seeking a software developer/architect/requirements analyst to assist with ongoing and expanding business needs with its export compliance software and services sold to major and small customers alike. The work is varied – meetings, coding, design, requirements, and legacy application translation to a new system. Early work will be code centric.

Qualifications
Five to 10 years’ experience coding on systems projects in a combination of .NET and ASP Classic. Experience with large, complex web applications. Business rule/requirements definition experience.

Technical Skillset
C# (preferably 4.0), .NET services, VBScript, XML, IIS, SQL Server, HTML, MVC design pattern, JavaScript, cookies, I/O, various data transport protocols. XML Schema.

Preferred Qualifications
Experience defining business rules with customers and working as a vendor with large project teams. Experience translating customer requirements into system design and identifying and communicating requirements contradictions to the team. Data integration experience. Sharepoint knowledge and/or experience. Regular expressions experience. AS2/sFTP protocol experience. ASP Classic experience. Extensive business writing experience.

Conditions
This position is a six-month contract for a telecommuting worker. A long-term to open-ended extension is likely. Some travel may be necessary, so applicants should have easy access to an airport. Please reply with preferred hourly rate, contact information, and a list of qualifications addressing these requirements to: hln@exitsinc.com. Applicants must be eligible to work in the United States of America.

Why is it the safest developer job in the world? Because I’m not allowed to test my wife’s code any more.

Hey, wait a minute. If I write code for your wife, that won’t be your wife’s code. Could you test my code? You’re right. IT’S A TRAP! But one where you can work from home and make some money for that abuse.

Use this one in conversation:

glich – (n.) A software bug thought to have been killed, but due to some eldritch dark developer magic or incompetence, rises again more powerful and destructive in an attempt to achieve some form of immortality.

Allowing a space in the password was a glich that caused many users to fail at resetting their passwords after the security breach.

The Atlantic is noticing what we QAssandras have been prophesying forever: Software Runs the World: How Scared Should We Be That So Much of It Is So Bad?

What do most people think of when they think of software? A decade ago, probably Microsoft Word and Excel. Today, it’s more likely to be Gmail, Twitter, or Angry Birds. But the software that does the heavy lifting for the global economy isn’t the apps on your smartphone. It’s the huge, creaky applications that run Walmart’s supply chain or United’s reservation system or a Toyota production line.

And perhaps the most mission-critical of all mission-critical applications are the ones that underpin the securities markets where a large share of the world’s wealth is locked up. Those systems have been in the news a lot recently, and not for good reasons. In March, BATS, an electronic exchange, pulled its IPO because of problems with its own trading systems. During the Facebook IPO in May, NASDAQ was unable to confirm orders for hours. The giant Swiss bank UBS lost more than $350 million that day when its systems kept re-sending buy orders, eventually adding up to 40 million shares that it would later sell at a loss. Then last week Knight Capital — which handled 11 percent of all U. S. stock trading this year — lost $440 million when its systems accidentally bought too much stock that it had to unload at a loss.* (Earlier this year, a bad risk management model was also fingered in JP Morgan’s $N billion trading loss, where N = an ever-escalating digit.)

The underlying problem here is that most software is not very good. Writing good software is hard. There are thousands of opportunities to make mistakes. More importantly, it’s difficult if not impossible to anticipate all the situations that a software program will be faced with, especially when–as was the case for both UBS and Knight–it is interacting with other software programs that are not under your control. It’s difficult to test software properly if you don’t know all the use cases that it’s going to have to support.

Yes.

Wikipedia has a rather incomplete list of software bugs that’s amusing. It’s not comprehensive, and it’s not very educational, but it’s a good reminder of what can happen if you aren’t paying attention.

Robert Rogers’ 28 Rules of Ranging.

Surprisingly, there is a lot of overlap in what QA does.

I Won’t Hire People Who Use Poor Grammar. Here’s Why.

Now, jump right into it and look for a grammar error to prove your worth. Or merely snicker at the unfortunate URL. Or both.

SD Times releases a bombshell: The Great Migration: It’s harder than you think (that’s the print title; the Internet title differs).

It’s a SPECIAL REPORT on the difficulties of migrating legacy applications to modern technologies, and it’s explains that it’s harder than you might think.

If you are a twenty-something developer or IT manager thinking that it’ll be a snap to go from a bicycle to a motorcycle or a tricycle to a race car (as one set of adverts puts it) or a joystick to a PS2 controller (as another set puts it). You get into a lot of trouble with that sort of thinking, the, erm, agile mindset of start slapping things together in .NET and you’ll be golden.

Many of my jobs have involved projects of this sort. Going from OS/2 to Windows, going from SPARC to Windows, going from Open VMS to going from mainframe to the Web, and so on.

The basic mistakes are similar in nature:

• Starting with inadequate understanding of the product/industry/domain and writing something that crystallizes and entrenches the misconceptions deep in the code, in the data, and in the process.
   
• Going forward with inadequate input from users who, you know, actually use the software and understand their workflows and needs.
   
• Choosing the wrong new technology to build the modern tech equivalent of a legacy application. And sometimes having to back up and start over after following the wrong path for a while.
   
• Expecting too much too fast. Legacy applications evolve over the course of years. Expecting to rewrite it in toto in six months or a year is asking for heartache.
   
• Giving users too much leeway for change. As the article notes, the migration gives organizations the chance to change processes and software workflow to better suit their modern needs, but these projects run into trouble when the users have the ability to shake the Etch-a-Sketch up with a lot of code, porting, and refactoring already done.

Application migrations harder than you think? Not me, brother; I assume that a legacy migration is plenty hard. It’s harder than starting from scratch.

Andrew Binstock doesn’t ask that question. He asks: What Makes Bad Programmers Different?

You say tomato, QA says tomato paste, tomato sauce, ketchup, catsup, salsa, roast tomatoes, tomato juice…..

But I digress.

Binstock highlights these traits of bad developers:

The bad programmer in action is best described by Daniel K. Lyons, who put forth the following list of traits as a comment on my previous editorial. The traits are:

• Their code is large, messy, and bug laden.
• They have very superficial knowledge of their problem domain and their tools.
• Their code has a lot of copy/paste and they have very little interest in techniques that reduce it.
• The fail to account for edge cases, while inefficiently dealing with the general case.
• They never have time to comment their code or break it into smaller pieces.
• Empirical evidence plays no role in their decisions.

I believe that most bad programmers participate to varying degrees in all these activities. They rarely fail to specialize in just one, alas.

I’d say these are not just traits of bad developers, but that most developers exhibit one or more of these behaviors from time to time.

But, yeah, I’ve seen worse developers. These are the ones that frustrate and upset other developers. Fascinating, the anthropological study one can do on developers and their tribes.

Binstock links to his list of things that make great developers different.

Want to know what makes a great developer? He or she has the same neurosis for quality that I do.

What to Do If There’s a Mountain Lion in Your Office.

Remember, the door is your friend.

A recent court ruling might put banks on the hook for additional losses due to fraud:

In the PATCO appeal, the court rules that Ocean Bank increased PATCO’s risk of fraud by allowing wire transfers to be approved through only the answering of challenge questions for any transaction exceeding $1.

The ruling goes on to say that even when the bank had warnings that fraud events were likely, as in the PATCO case, it “neither monitored that transaction nor provided notice to customers before allowing the transaction to be completed.”

The fraudulent wire transfers that hit PATCO’s account should have raised red flags and triggered extra security measures to validate the transactions, the court says. “The payment orders at issue were entirely uncharacteristic of PATCO’s ordinary transactions,” the ruling states. “These collective failures, taken as a whole, rendered Ocean Bank’s security procedures commercially unreasonable.”

The Second Great Kludging begins. Let thousands of billable hours bloom!

Remember that one time someone brought to your attention a catastrophic or dramatic defect or problem that you might have and probably think you should have caught? Remember how everything got distant and hollow as the blood pounded in your ears?

Yeah, your sinking feeling probably pales in comparison to this guy:

It’s Friday, and as the software testing team heads home for a three-day weekend, they forget to turn off a 250-server cluster they’ve been renting from a public cloud infrastructure vendor. The cluster doesn’t have a job to run, but it still racks up a $23,400 bill, 10 times what was planned. “It went from $2,300 to $23,000 so quickly,” the testing team leader explained when he got back.

It’s a true story recounted by a software company CEO, and it points to a major concern that would-be cloud buyers have: runaway costs.

That, my friends, is a bad start to a week.

When you go on a job interview, common advice reminds, you interview the company as much it interviews you. Remember, just as you might exaggerate that you have ten years’ experience developing .NET on Linux, the company might embellish its resemblance to a happy television family. Whether the company represents the Cosbys or the Bundys, participants in your four-hour interrogation will concur that the company represents the Panglossian best possible workplace. Managers want to fluff the company’s stock price. The proletariat wants more proletariat to share its burden. If the company demands twelve hour days or offers daily browbeatings, no one will tell an outsider. You would only learn true company morale after you started unless you conducted a little reconnaissance during your interview.

To gauge employees’ true attitudes toward a company and its working environment, you can reconnoiter two locations in the building: the kitchen and the bathroom. (more…)

Do you see testing in it?

Of course not.

(Suddenly, it strikes me that you damn kids don’t know what Geek and Poke alludes to.)

This warms my heart almost as much as when someone searches the Internet for a sample test plan.

Apparently, a future IT professional in Indiana knows where to go for boundary analysis info:

It’s already known in St. Louis, Missouri, and pockets of Chicago. Tomorrow, the entire Midwest. Next week, the nation.

One of the advantages of working as a software quality assurance/testing consultant (and before that as a full-time employee with the propensity to job-hop) is that one gets quite a knowledge of a variety of industries.

This became quite clear to me one recent day as I hopped into a shuttle from an auto dealer’s service department for a ride out into the hinterlands and my home office. I struck up a conversation with the ITish looking Chinese man next to me and asked him the ever eternal opener, “So what do you do?”

To my surprise, he was not in IT per se, but he was a chemical engineer. I asked what sort of software he used for modeling, and I could talk about some of the challenges of testing that sort of software because I’d done it, albeit for a more pharmaceutically minded company. I got to learn a little about his challenges, too, and what he does day-to-day as a user.

After he disembarked, I talked a bit with the driver of the shuttle, a retired employee of the local wastewater treatment plant. As I’ve tested a wastewater treatment district’s Web site (remember the classic Make Your Software Development Process More Like A Sewer?), I could understand what he was talking about when he told me about the machinery and equipment he operated and its part in the treatment process.

One of the best parts of this job is that I get to touch so many different projects in so many different industries and to learn so many different things and businesses that the actual testing and application of testing knowledge is always fresh.

And it makes excellent conversation fodder.

A reader sends in a pointer to her own site: F— Yeah QA on Tumblr.

“What The Director?” you ask. “You’re bleeping out naughty words on your blog?”

Well, yes, as a matter of fact, I am. I don’t tend to use naughty words that anyone else understands in the workplace, and I also have to recognize that some readers are at work, works that might not be happy that their QA staffs are reading a subversive little piece of work like this. So I try not to include words like —–, —–, or German words like ————-chtch———g to keep the Internet filters pure and clean.

Buzzfeed has a list of words you cannot use in Twitter.

Because of the censorship? No, because:

A majority of these commands aren’t things you’d otherwise use in a two-word tweet, and most only work through the SMS service — you can tweet “suggest something” just fine from a computer or app, for example. A couple years ago you could even type “accept [username]” and force anyone to follow you, a command that, like “get,” had been lying mostly dormant for years.

That is, old functionality hanging around awaiting someone to accidentally trigger it.

If your application is robust enough, you’ll run into the same sort of danger. If your application is robust enough, and your organization turns its QA staff and other staff over quickly enough that nobody knows what was going on five years ago, woo boy. You’re asking for it.

(Link via…oh, I forget, but thanks!)

An oldie but a goodie:

Court officials have figured out why Hartford residents were excluded from Federal grand jury pools over the past three years: The computer that selected names thought everyone in the city was dead.

Sure, that’s from the New York Times in 1982 1992, but rest assured, I’m not 20 years behind in my newspaper reading. But I am a month behind in my Stupid History 2012 desk calendar, which explains why I’m getting to the April 20th sheet today.

UPDATE: New commenter kbiel pointed out that I had the wrong year attributed to the article. I’ve corrected it immediately.

I’ve said it’s dangerous to base your Web browser compatibility testing matrix on a press release.

But this story might have some use to you:

Google’s Chrome edged past Microsoft’s Internet Explorer (IE) last week to become the world’s most widely used browser, according to data from an Irish metric firm.

Chrome’s average usage share for the week of May 14-20 was 32.8%, said StatCounter, an analytics company that tracks browser and operating system trends. For the same week, IE’s share was 31.9%.

If you read the whole story and not just the headline, you’ll find that this metrics-providing firm used some data modeling to conclude as it did, and that other firms with other ideas about data models continue to come up with different results.

However, you can learn something from this:

• It’s important to continually re-analyze your assumptions.
  If you thought it was important to test a browser last year, you might need to change your Web testing to accommodate the changing realities. I acknowledge this so much that I’m no longer mentioning testing in Netscape or AOL Explorer even though I still have those browsers installed in the lab.
   
• Just because it’s a cool browser doesn’t mean you shouldn’t test in it. Or, more to the point, because it’s an IE and Firefox world in the popular culture consumer mindset world (in the popular culture, the world runs Safari. Inspect every television program, commercial, or print advertisement showing a Web page, and 97% of the time, you’ll see the Safari browser window around it, or I’m not a guy with an English degree just making statistics up). More to the point, it’s important to remember that sometimes you do need to test using the things your designers and developers think is cool. They’re not always wrong, just mostly.

SD Times magazine has it in for testing in the May 2012 issue.

First, in the article on Kanban (“Kanban: Is It In The Cards?“), when it comes time to illustrate a blocked task, we get a likely scapegoat:

Secondly, we get an Industry Watch column “Testing culture undergoes dramatic shift” that describes how testing is becoming more relevant by adapting itself to what the developers want or by turning into tech support people.

This culture shift in testing might help testers shed the image of being impediments to software releases instead of facilitators of quality software releases. “How do we work with the development team in this brave new world?” Sterling asked. “The role of testers in the cloud becomes a huge value-add. Testers triage the feedback data, and turn around to tell developers, ‘Your customers want features 5, 10 and 43.’

“All of a sudden,” he said, “your success in getting your next check is pinned on testers getting you the feedback data to deliver what those customers want.”

I agree with some of the sentiments in the article, but I’d like to say that it’s not that testing is changing to fit the needs of software development. I’d like to think quality assurance professionals are helping to change the whole kit-and-kaboodle to provide better quality.

As long as we’re actually making the developers do what we want and making them think it’s their idea, though, we’re golden.