File this one under the “how-the-hell-have-we-not-blogged-about-this-yet” category. A few weeks ago, BATS Global Markets Inc. had just made its IPO debut. Seconds after trading began, a software bug “disrupted trading” of the stock (i.e. it went from $16 to under a penny in seconds), prompting the company to cancel its offering. You can read more about it here.

Anyway, the incident spurred Forbes writer Ken Goldstein to re-examine the meaning of quality assurance. There’s a lot of gold in this article, but here are a few of my favorite nuggets (emphasis added):

There is no argument that we live in a world of staggering speed, where competitors race to meet customer needs and time to market matters. Innovation is always factored by the ticking clock, who gets the jump and the competitive advantage, when a cost center becomes a profit center. Information compounds on our desktops, the team with analysis paralysis most often loses to the nimble risk takers–but all this means is that in product development, the role of Quality Assurance (QA) has never been more critical.

Notice that he does not say the QA department has never been more critical. He says the role of QA. This is an important distinction which he goes on to clarify:

Here is the way I like to think about quality in product development: Quality Assurance is a Process, not a Department….

…Of course every great development company will have a final step in the process called Quality Control or Quality Assurance, but it is my sense that the QA formal group is there to be the standard-bearer for Quality and rally the company around it, putting a final go or no-go procedure in place before the world gets its hands on a product, but not accepting proxy status for an otherwise poor process. A QA department is not a dumping ground, not a remote server where code is parked as a step function or convenient checkpoint in a perfunctory release approval, not a cynical target of blame. QA is the proxy for the customer, not management, and as such must have a voice that is shared throughout a company. If a Decision Maker chooses not to listen to either the process or a warning from fully objective and independent QA stewards, you get what you get.

Read more…

While our usual maniacal focus is on quality over quantity, it’s not unreasonable to recognize a major milestone that occurred today, January 18, 2012: surpassing 50,000 testers in the uTest community! Just to be clear, that’s over 50,000 testers from 185 countries around the world – from experts in automation to gurus in usability testing. Here are several other facts about our community:

• Every month, there are approximately 1,000 new tester registrations
• Over 99.9% of these registrations are organic – word of mouth, tradeshows and conferences, tester referrals
• The majority of testers span rather evenly across North America, Europe, and Asia. The rest fill out in South America, Africa, and Australia
• Over 80% of uTesters have a Bachelor’s degree or higher
• uTesters bring a wealth of knowledge and diverse set of skills to the table: creating test cases, usability surveys, load and performance scripts, automation scripts, security coverage reports, usability audits and expert reviews; executing test plans, usability surveys, live load test cases, security scans, exploratory tests, and translation tasks and proofs

And…back to our maniacal attention to quality. Although there is certainly strength in numbers and meaning to this milestone, the real excitement stems from the various “homegrown” programs that shape our crowdsourcing model. Less than a year ago, we announced several new initiatives that have transformed the uTest community from an unruly crowd to one that is self-sufficient, self-teaching and self-policing. From paid leadership roles for our top testers to unpaid auditions for newbie testers, there is a role for nearly everyone and a path for the most ambitious. And now that most of us have embraced the New Year, it’s only fitting that there are new programs just around the corner – ones that leverage the foundation built in the past year and continue to benefit our community at large. More details to come shortly!

For now, please join me in raising your glass to celebrate this major milestone with us!

Okay, call this a bait and switch if you will, but the bottom line is you cannot test quality into an application. So if you can’t test quality into an app, do you then build it into an app? Or perhaps the more pertinent question is, ‘who contributes more to app quality – software developers or software testers?’ Playing with dynamite here, I know…

Let’s begin with a simple fact – developers are the ones who “create” software defects in the first place. To be fair, they don’t knowingly create buggy software, but that’s the widely accepted norm – we’re human after all. However, when bugs are discovered after the product launches, testers are typically singled out and blamed. Why?

Part of the reason is due to the misnomer that QA should stand for “quality assurance.” Do QA professionals truly assure the quality of a product, or do they assist in delivering high quality products (as Jon Bach has suggested)? So if you’re a tester by trade, I sympathize with you. On the one hand, buggy software leads to job security. On the other hand, you are constantly on the hot seat and looking over your shoulder, wondering when and where the next bug will surface. But instead of despairing over these details, testers should rise to the challenge.

Here are a few examples of how testers can lead the quality initiative:

Read more…

Next up in our Testing the Limits series is Lanette Creamer. Known to many in the QA blogosphere as “Testy Redhead”, Lanette has over ten years of experience in the software industry, including her current role as Quality Lead with Adobe. Like many of our guests, she writes a popular testing blog, publishes technical papers and has been known to speak at a conference or two. And yes, she’s on Twitter.

In part I of our interview, we get her thoughts on testers vs. hardware; the idea of “quality advocacy”; why unemployed testers should study The Price is Right;  life as a shift manager at a charity bingo parlor; and much more. When you’re done with one, be sure to check out part II.

uTest: What’s the biggest trend/challenge in testing that no one’s talking about yet?
LC: Testers are breaking out of the office like William Wallace, but with laptops, not swords. How much more affordable is it for a company to buy a great laptop every few years than all sorts of different hardware? Let someone else manage the machines so we can focus on the testing. Of course, this isn’t appropriate for every context, but I’m interested in going beyond multi-boot systems, local images, and to truly getting out of the business of managing hardware. I’m interested in cloud-based imaging. Part of my personal strategy of investing in one laptop that can run multiple operating systems is the temping ability to verify the scope of a bug on one machine. To do that without even rebooting with more built-in logging and debugging tools is really the next step to freedom from hardware and location-reliant testing.

uTest: In the last year, we’ve noticed you blog about the prospect of unemployment. What advice do you have for other testers who find themselves in this situation? Should they just wake up at noon, watch The Price is Right and eat nachos until a hiring manager comes knocking on the door? Or should they try to keep their skills sharp? If it’s the latter, then please elaborate on how to go about this.
LC: The Price is Right can teach you something amazing about interviewing. Have you ever noticed who they pick? It is the most enthusiastic people with the best stories. Come on down, job candidate! You’re the next contestant on The Job is Right. Can you imagine what The Price is Right would be like if they picked a contestant who was just above it all? Laughed at the fabulous prizes? Ignored the host? Win or lose, play the job interview game with style and be memorable. Also, I do like nachos. Layer the cheese and make them in the oven.

Well, rather than bouts of unemployment, I’ve been facing one very long pending layoff. I’ve not yet experienced the unemployment part, so maybe your readers can help me out with their advice when that happens. As a part of the CS5 team, my layoff isn’t effective until June, and it impacted every tester on my current team. The day I first became aware of my pending layoff, I felt a bit powerless. I realized that it was really up to me to decide what to do next. I decided that I wanted to end well and finish the project, and I really wanted to complete my 10 years at Adobe. I am proud of my work for my entire career at Adobe, and that hasn’t changed with my layoff notice.

Here’s what I recommend for those of you working in a job that you know is ending:

Read more…

In part II of our interview with Scott Barber, we tackle the so-called “consensus” among the Context-Driven School; his start as a software tester; why software problems are mostly people problems; reporting out-scope-bugs and much more.

We will post the final installment tomorrow. By the way, did you miss Part I?

uTest: There’s a lot of consensus among the Context-Driven School of Software Testing, but are there any fundamental differences? You can’t agree with guys like Michael Bolton and James Bach on everything, can you? Speak freely, your secrets are safe with us!

SB: I don’t know that there *is* a lot of consensus. I know that I am very much Context-Driven. In fact, my license plate says “CONTEXT”. That said, the buzz and counter-buzz surrounding the Context-Driven School of Software Testing is still causing as much harm as good.

I think the underlying problem is that the creation of software is widely treated as a software development activity, which may or may not benefit from related activities like testing. I find this thought process just plain silly. Software development, in my experience, is done for one of four reasons; altruism (minimal), education (some), research and development (slightly more than some), and/or financial/business advantage reasons (most). I think the fact that software is created for different reasons and purposes makes software development at least context-dependent by definition. The difference between being context-dependent and being context-driven is fundamentally the difference between being reactive vs. being proactive.

I think there never would have been a need to call out or name the Context-Driven School of Software Testing if testing hadn’t been so undervalued, misunderstood, and too often ignored entirely for so long that some entrepreneurial folks decided to step up and start talking about “the right way” to test software. While I’ll be one of the first to admit that many of these folks published “right ways” that were far superior to the state of the practice of the time, none of these “right ways” were right for everyone or every situation.

Read more…

After Twitter-stalking him, making some harassing phone calls and sending threatening letters, Jon Bach (@jbtestpilot) cheerily agreed to take part in our Testing the Limits series. Much like his brother, Jon has a remarkable understanding of software testing – both in theory and in practice. Having worked for companies like Quardev, LexisNexis, HP and Microsoft, Jon is also a blogger, author and software testing consultant. An expert, in the truest sense of the term.

In the first installment of our two-part interview, we get Jon’s thoughts on sibling rivalry; the blame spiral of software development; the emergence of “agile-fall”;  testing at a startup vs. testing in the enterprise; John Schneider as Jon Bach and more.

uTest: A few months back, we asked your buddy Andy Muns who’d win a fight between you and your brother (this was a big debate in the uTest office). He said you would win hands down. Would he be right? And since you and your brother seem to share the same testing philosophy, what would do you think the fight would be about?

JB: It’s hard to fight with someone who stayed in their room for most of our childhood.  He was either reading or doing science experiments with a microscope or the chemistry set.  It got worse when we got the TRS-80 in 1980.  In fact, that’s probably the last time we fought — over who got computer time next.  My memory may be fuzzy, but just when it came to blows, he programmed a user name and password dialog? Something clever like that. Now it’s better just to learn from him and do my best to keep up — but that’s true for all younger brothers, I think.

As for modern-day fighting, sponsor me for a testing certification and let’s see what he’d do.

uTest: Say you’re named grand poobah of the QA universe… what’s your first decree?

JB: Effective today, “Quality Assurance” is now “Quality Assistance”.

(Try it.  Watch what happens when you start using it.)

Read more…