 |
Home > Detail: Start a Revolution
Viewing 2-11 of 1769 Collapse Descriptions
Sort by: Date Posted | Title | Content Type
 ARTICLE: Writing Plugins for RDesktop
Author(s): Sergey Yakimenko
Summary: This article is written mostly for Linux developers in which the author gives a method for writing out-of-process plugins so that its code may stay closed to open source software.
Date Posted: Feb 5, 2010 |
COLUMN: Negative Positive
Author(s): Fiona Charles
Summary: Testers who point out project risks are often perceived as "negative" thinkers. In this week's column, software test consultant Fiona Charles (an optimist by nature and a pessimist by trade) writes about how a culture of unthinking optimism pervades our organizations and our society, and describes some of its detrimental effects on software projects.
COLUMN: Empowering Self Organization and Energizing Project Planning with the Commander's Intent
Author(s): George Schlitz/Giora Morein
Summary: Things change, and when they do, it's best to be ready to change with them. The best plans are doomed to fail if they aren't malleable. In this column, George Schlitz and Giora Morein take a look at the military concept of "Commander's Intent" and how it can apply to non-military project planning.
Date Posted: Jan 29, 2010 |
ARTICLE: Industry QA/Test Estimation Approaches
Author(s): Ranjit Shewale
Summary: This presentation discusses some estimation approaches for software QA/testing used by practitioners based on the research in software engineering and actual experience.
Date Posted: Jan 29, 2010 |
ARTICLE: How to Forbid Unauthorized Access to Window's Clipboard
Author(s): Vladimir Shamray
Summary: Though Microsoft's Office Clipboard is one of the fundamental parts of the Windows operating system, there is little information about how it works, especially in the low level. In this article, Vladimir explains the Clipboard internals by showing how you can forbid access to it. He simplified the task as much as possible to focus on the most important parts.
Date Posted: Jan 29, 2010 |
COLUMN: Pragmatic Personas
Author(s): Jeff Patton
Summary: Knowing who will use your software is important to the software development process. Having the end user in mind helps you develop features that fit the user's needs. And, figuring out your end user, as Jeff Patton reveals, is indeed easy. In this column, Jeff details stereotypes to avoid, questions to ask, and how to implement this pragmatic persona in your development process.
Date Posted: Jan 22, 2010 |
ARTICLE: White Paper: Requirements Traceability
Author(s): John Simpson
Summary: To some, traceability may sound complicated and like it entails a lot of work. Is it really worth the effort? Good question. The short answer is yes. And, here's why it's so important: Change happens. In this paper, the authors demystify traceability and its related concepts and provides five practical tips to help you take control and keep everyone in sync.
Date Posted: Jan 22, 2010 |
ARTICLE: Crowdsource Testing
Author(s): Yvette Francino
Summary: Through the power of the Internet, people around the world are working together to solve problems in a faster, more cost-effective way than ever before. Crowdsourcing is a term that has been used to describe the process of requesting a crowd to perform a task rather than hiring consultants or contractors. There have been various models used to harness the collective brainpower of the masses, and this article delves into three examples. Thanks to the power of Web 2.0, publicity is easily spread world-wide to recruit participants who will take part in competitions or collaborative events aimed at solving a problem or completing a task.
Date Posted: Jan 22, 2010 |
ARTICLE: Finding Nuggets in the IT Gold Mine
Author(s): Clarke Ching
Summary: Development teams often are unaware of the commercial impacts of the software improvements they deliver. Often, the prioritization of work is done based on technical, rather than commercial, considerations. Based on a real-world example, this story explores the commercial benefits enabled by delivering in short release cycles and prioritizing according to bottom-line benefits.
Date Posted: Jan 13, 2010 |
ARTICLE: The Right Business Analysis Tool
Author(s): Matthew Leach
Summary: The continued rise of the business analysis profession has led to a surge in software tools specifically designed for the business analyst. Find out what types of tools are in the marketplace today and how to select the right business analysis software tool for your organization.
Date Posted: Jan 13, 2010 |
|
Viewing Item 2 of 1769
| A StickyMinds.com Original |
|  | |
Start a Revolution
By Linda Hayes
   
Summary: What is a software tester’s main responsibility? If you think that it’s to find as many bugs as possible, you might be surprised to read Linda Hayes’ column this week. She looks at the question from a different angle. Read on and see if you agree with her. | | |
|
|
 |
I don’t think that it’s a tester’s job to find bugs.
There, I said it. I have been wanting to say it—even shout it—for a long time, but I was finally compelled to do it by Lee Copeland’s column “Institutionalizing Poor Quality” and the many comments it received. Remember the example he gave where a QA person pops up to inspect the pastrami you are about to buy? He offered this example, among others, to point out that we routinely expect a certain level of quality from most professions, so why don’t we expect it from programmers?
Let me take it one step further. Let’s say that you are forced to wait on your pastrami while it is inspected—and you are getting hungrier by the minute—then once it is over, your purchase receipt reflects a 20 percent surcharge for the inspection. It might prompt you to question the value of this service. After all, having it too thick or too thin might not matter that much to you. The reason it is worth it, you are told, is that the inspectors are also looking for E. coli bacteria, which could make you seriously ill or even kill you.
Okay, now quality has your attention. But, as you think about it, you would likely wonder why the E. coli inspection doesn’t happen much earlier—say, when the meat is slaughtered or packaged. Or, maybe the butcher’s premises should be inspected routinely. Wouldn’t that be much more time and cost effective than inspecting every single slice? Of course it would.
All of this leads back to the difference between quality assurance and quality control. I used to think people who emphasized this distinction were being anal retentive, but I have come to see their point. Quality assurance is about building quality into the process, and quality control is about inspecting the end result.
As Lee concluded, “In our world, the process that needs to be improved is the development process.”
But if you are a tester, what does this mean to you?
First, let’s face the facts. Testers did not ask for the product, did not design it, did not build it, will not pay for it, and will not use it. So it’s fair to ask…what does testing bring to the party? If the answer is “to find bugs,” then I think you are doomed to being overworked, underpaid, and under-appreciated, if not downright vilified. Why? Well, for the simple reason that you can’t prove a negative.
Think about it. What you are saying, essentially, is that there are an indeterminate number of bugs in unknown locations of unpredictable severity, and at the end of the project all you can say is which ones you have found but not how many are left. Is it any wonder it’s hard to put a high value on this service?
If I were to play the role of the customer, who is having the software developed at great expense to meet a critical business need, here is what I hear you saying: “I want you to pay me to delay your use and enjoyment of this critical software so I can see how many things I can find wrong with it.” Not very appealing, is it?
Don’t get me wrong—there are most likely bugs out there, and some of them might be bad, but the problem is that we just don’t know, and it’s hard to get someone to pay for something that can’t be measured.
So what’s the alternative?
It’s the requirements, of course. Customers don’t have software developed so that it will be bug-free, they do it so that it will meet a business need. In fact, companies use software every day (and so do you) that has bugs in it that are known and—in some cases—have been for years. As one customer told me recently, “We have a bug that has been in our system for over ten years and everyone knows about it, but every time we prioritize requests for enhancements and fixes, this bug is at the bottom of the list.”
So instead of making it your mission to find bugs, make it your mission to verify the requirements. Now you might say, and rightfully so, that the requirements are either missing, obsolete, or incomplete. But so what? Make it your job to find them out, because that is what the customer is really paying for.
And you might also say, and experience will back you up, that there may be really nasty bugs out there that are on the fringes or even outside the expected pathways, and you will never find them just testing requirements. Again, so what? You can’t guarantee that you’ll find them even if they are there, and if you do find them you can’t be sure that the customer will even care about them so long as they can be worked around or avoided.
Back to role-playing. Now, here is what I hear you saying: “I want you to pay me to assure that this major investment will meet your business needs without jeopardizing critical operations.” Now you’re talking.
About the Author
Linda Hayes is the founder of three software companies including AutoTester in 1986, which delivered the first automated testing program for the IBM PC. Linda has pioneered automated test tools. Her new company, Worksoft, offers Certify, which represents the next generation of enterprise-level test automation. Worksoft also offers a free online newsletter called "Reality Check," which provides links to articles, white papers, and other compelling information on testing. A frequent industry speaker and award winning author, she publishes the monthly Quality Quest column for Datamation, wrote the Automated Testing Handbook, and co-edited Dare to be Excellent with Alka Jarvis on best practices in the software industry. You can contact Linda at Linda@worksoft.com.
Back to Top
StickyMinds.com Weekly Column From 7/22/02
|
</nobr>.gif)
