Test Management Resources
Articles
Is Software Quality Job
One?
First Paragraph:
Imagine this: You stand in front of your
software-development group and demand that the next release of your Customer
Magic application be "built to last." Yes, you want it in a timely manner at a
reasonable price, but you're tired of being an unsuspecting beta site. You want
the team to start from scratch with the intent of delivering high-quality
software--stuff that runs as promised without a crash or error for a whole
week!
Comments: Shortening the software development cycle is possible
but will cost an increase in requirements and preplanning. The author argues
that if companies can overcome the cultural propensity to rush into development,
increasing software development process efficiency is both realistic and cost
effective.
Author: Ira Grossman
Publisher:
InformationWeek
Issue/Date:May 26, 2003
Quest For Quality
First Paragraph:
Improving software quality is a high priority
at many companies. Why? Buggy software hurts the bottom line.
Comments: There is a growing trend of increase quality standard
and processes in the technology industry. Companies are hiring more engineers,
relying on automation and adding more review processes to ensure that quality is
enforced earlier in the development process. Read about how several companies
are adjusting their organization to maximize software quality and the
hurdles and cost associated with doing so.
Author: Mary Hayes
Publisher:
InformationWeek
Issue/Date:May 26, 2003
Los Altos Workshop on Software
Testing
First Paragraph:
This is a process developed by Cem Kaner and
Brian Lawrence for technical information-sharing across different groups. It's
not very new. We adapted it from some academic models and models from other
industries. Our goal is to facilitate sharing of information in depth. We don't
see enough of that happening today. Instead, what we see today is
that:
Comments: A document describing the process of setting up a
facilitated workshop.
Author: Cem Kaner and Brian Lawrence
Publisher:
Presented at a Birds of a Feather Session
at the Pacific Northwest Software Quality Conference, Portland, Oregon,
www.kaner.com
Issue/Date:Sunday, November 9, 1997
Software Failure Can Lead to
Financial Catastrophe
First Paragraph:
WE SAT IN A GRAY cafe at 8 a.m., eating gray
eggs and gray home fries. Our watery coffee wasn't even strong enough to be
gray. Since four o'clock the previous afternoon, we had been trying, with little
success, to install a relatively simple custom-built software
program.
Comments: This paper offers the author's view of why software
projects fail often. In addition, he stresses the importance of doing testing as
a means of minimizing failures.
Author: Bruce Abbott
Publisher:
InfoWorld
Issue/Date:October 2, 2000
Better Testing - Worse
Quality?
First Paragraph:
Chuck is a test manager at a software
company. His boss, Susan, wants to know why her large investment in testing
hasn't paid off in improved quality.
Comments: Managers like to be able to trace their team's hard work
to improved software quality. This slide presentation shows how.
Author: Elizabeth Hendrickson
Publisher:
Quality Tree
Issue/Date:February, 2001
Karl Weigers Describes 10
Requirements Traps to Avoid
First Paragraph:
The path to quality software begins with
excellent requirements. Slighting the processes of requirements development and
management is a common cause of software project frustration and failure. This
article describes ten common traps that software projects can encounter if team
members and customers don¹t take requirements seriously. I describe several
symptoms that might indicate when you¹re falling victim to each trap, and I
offer several solutions to control the problem.
Comments: Concise requirements are key to successful product
development and deployment. In this article, the author offers ten common
mistakes in developing product requirements, and suggestions on how to overcome
those problems.
Author: Karl E. Weigers
Publisher:
Process Impact
Issue/Date:May 2000
Perspectives From a Test
Manager
First Paragraph:
Three years ago, I embarked on a career as a
software tester with a company involved in control engineering. After just one
year of testing, I was promoted to leader of the test group. I was reminded of
that experience as I read Pam Hardy¹s article, "Perspectives from a New Software
Tester," in the March/April 2000 issue of STQE‹not only was I new to testing,
but I suddenly found myself responsible for managing other testers.
Comments: An experience-based report on how to effectively
organize your testing, manage, and communicate the testing efforts as a test
manager or lead.
Author: Chris DeNardis
Publisher:
STQE Magazine, Vol. 2, Issue 5
Issue/Date:November, 2000
The Testing
Process
First Paragraph:
This paper discusses the essential testing
stages that are conducted during the implementation of an e-commerce solution
and its maintenance. It also covers specific types of e-commerce testing and
defines their stages.
Comments: Offered by Microsoft, this article discusses the need
for testing and the various types of tests such as security testing, software
and hardware reliability, and compatibility testing that should be applied to
the system under test.
Author: Biraj Rath, Raj Nath,Mukesh Agarwal, Jas Lamba, George
Gianopoulos, Laura Hargrave
Publisher:
Microsoft
Issue/Date:July, 2000
What is a Software Defect?
First Paragraph:
One discussion that plagues development groups is how serious a bug is. Can we call it a feature? Does it have to be fixed now or can it wait until the next release? What are the consequences if we ship it? This article looks at this issue from a different angle: How should the law determine whether a bug is serious enough that the customer should be entitled to cancel the contract, return the software, and demand a refund?
Comments: Cem's memo on the
legal perspective.
Author: Cem Kaner
Publisher:
Memo written for the January 10-12, 1997
meeting of the Article 2B Drafting Committee.
Issue/Date:December 10, 1996
Personal Process Improvement
May 2000
First Paragraph:
You don't need an official sanction to tune
up your own engineering savvy.
Comments: A nice paper offering simple tips and suggestions that a
developer can do to improve one's process practices.
Author: Karl Wiegers
Publisher:
Software Development Magazine
Issue/Date:May 2000
Development and Delivery of a
Successful Commercial Web-based Application
First Paragraph:
Hung Nguyen offers the inside story on
LogiGear's design, development, testing, deployment and support of a commercial
Web-based application. He will discuss the engineering and business challenges
that his organization overcame in delivering and managing quality. In
particular, he will share some of the real-world lessons he learned while
developing and testing Web-based applications. He will also relate his views on
the challenges of managing customer expectations and satisfaction along with the
need for integrating development, software testing and technical support into a
single business unit. At the conclusion, Hung will discuss testing strategies
that may complement your efforts in testing Internet-based applications. He
encourages participants to join in the discussion with questions and
comments.
Comments: A presentation at the SSQA June 1999 meeting, discussing
the development, testing and deployment of a Web-based product.
Author: Hung Q. Nguyen
Publisher:
LogiGear Corporation
Issue/Date:June 1999
Dealing with Difficult
Customers
First Paragraph:
Dealing with Difficult Customers. Software
development contracts often look good at the start but begin to tarnish as the
work progresses and the relationship regresses. What do you do when things go
wrong between you and your customer? Calling Ghost Busters won't help. There is
no cavalry to ride to your rescue. You have to work it out. This month,
consultant Ulla Merz outlines some things to keep in mind when trying to turn
apparent business impasses into win-win situations.
Comments: Outsourcing is like a marriage: You've got to overcome
your differences to succeed.
Author: Ulla Merz
Publisher:
Software Development Magazine
Issue/Date:May 2000
Quality Cost Analysis: Benefits
and Risks
First Paragraph:
Because the main language of [corporate
management] was money, there emerged the concept of studying quality-related
costs as a means of communication between the quality staff departments and the
company managers."
Comments: A discussion on software quality cost
analysis.
Author: Cem Kaner
Publisher:
Software QA, www.kaner.com
Issue/Date:Volume 3, #1, 1996, p. 23
Selecting a Defect Tracking
Tool
First Paragraph:
Congratulations...you've been nominated by
your manager or team to select a defect tracking system for your company. Where
do you begin? Of course, you'll be expected to conduct your research while
carrying out your regular responsibilities -- so you need to come up with a
quick strategy that enables you and all parties involved to objectively evaluate
various options and select a system in a timely manner.
Comments: If you've been nominated by your team to shop around for
a defect management solution, you'll appreciate the helpful management,
security, and technical considerations discussed in this article. Hung Q.
Nguyen's guidelines will assist you in identifying the defect tracking tool that
best serves your organization's needs.
Author: Hung Q. Nguyen
Publisher:
LogiGear Corporation
Issue/Date:N/A
Liability for Defective
Content
First Paragraph:
With all the storage space on CD-ROMs, many
products come with loads of added content, such as books, articles, maps, audio
clips, video clips, and clip art. Much of this material is bought cheaply and
then copied onto the disk without any testing beyond verification that it
installs correctly.
Comments: In this paper, Cem stresses the importance of having
accurate content.
Author: Cem Kaner
Publisher:
Software QA, www.kaner.com
Issue/Date:Volume 3, #3, p. 56, 1996
The Influential Test
Manager
First Paragraph:
Many of us have worked in test groups in
which we felt as if we didn't have enough time, hardware, or staff to do the
work. In those situations, it's hard to escape the feeling that while somebody
might be in control, we are certainly not. As a test manager, you don't have to
work this way. There are other, more effective, ways to develop and use your
influence within your organization to help your test group — and project —
succeed.
Comments: Use your influence as a manager to make your staff and
projects successful. This article offers an innovative approach to working
smarter, rather than harder. It introduces several highly effective
communication techniques for test managers.
Author: Johanna Rothman
Publisher:
stickyminds.com
Issue/Date:archives
Negotiating Testing Resources:
A Collaborative Approach
First Paragraph:
How to Save Time & Money in Testing :
This session is about saving time and money. As in all aspects of product
development, a time-honored way to waste time and money is to work without clear
requirements, in a chaotic rush to meet unrealistic and unachievable deadlines.
As testers, we often see the mess that this creates. But some of us seem unaware
that, even if the overall project is a mess, we can go a long way toward
establishing clear requirements and expectations in the testing sub-project
itself. This paper applies what I think is largely common sense and common
knowledge about project management and consensus-driven engineering. It
describes an approach that I've used a few times — not always successfully —
since 1983. The details will vary according to your company's circumstances and
schedule, but the ideas, I think, have general application and
merit.
Comments: How you can effectively negotiate for testing resources
through a collaborative approach.
Author: Cem Kaner
Publisher:
Software Quality Week,
www.kaner.com
Issue/Date:May 22, 1996
A Manager's Guide to Evaluating
Test Suites
First Paragraph:
Whatever else testers do, they run tests.
They execute programs and judge whether the results produced are correct or not.
Collections of tests — test suites — are expensive to create. It is fair to ask
how good any given suite is. This paper describes ways we would go about
answering that question.
Comments: A guide to utilizing test suites not simply to find
bugs, but also to evaluate process and product quality — making expensive test
suites more valuable tools.
Author: Marick, Bach, Satisfice
Publisher:
testing.com
Issue/Date:N/A
Liability for Defective
Documentation
First Paragraph:
In October, 1985, W.H. Daughtrey bought a
diamond bracelet as a Christmas gift for his wife from Sidney Ashe, a jeweler.
He paid $15,000. After Daughtrey agreed to buy the bracelet, Ashe filled out an
appraisal form and put it in the box with the bracelet. The appraisal said that
the diamonds were of v.v.s. quality (a high grade). Daughtrey didn't see the
appraisal until later, probably not until the box was opened at
Christmas.
Comments: In this paper, Cem stresses the importance of having
accurate documentation.
Author: Cem Kaner
Publisher:
Software QA, www.kaner.com
Issue/Date:Volume 2, #3, 1995, p. 8
Working with Testers?
Reconcilable Differences
First Paragraph:
Testing is a hard problem. It is a task that
is both infinite and indefinite. No matter what testers do, they can not be sure
they will find all the problems, or even all the important ones. Whereas you, as
a developer, perform a thought process that results in something that looks
real, the thought process of a tester does not look like anything.
Comments: This article is filled with great ideas for managing
develop-tester relations. Though written for a developer audience, testers will
enjoy the respect and praise lavished upon them in this article.
Author: James Bach
Publisher:
Software Development Online
Issue/Date:March, 1997
Software Negligence and Testing
Coverage
First Paragraph:
A program fails in the field, and someone
dies. This leads to a trial. When the QA manager takes the stand, the
plaintiff's lawyer brings out three facts: The failure occurred when the program
reached a specific line of code. That line had never been tested, and that's why
the bug had not been found before the product was released. A coverage monitor
was available. This is a tool that allows the tester to determine which lines of
code have not yet been tested. Had the QA manager used the tool, and tested to a
level of complete coverage (all lines tested), this bug would have been found,
and the victim would be alive today.
Comments: The paper explores the testing coverage notion from the
legal perspectives.
Author: Cem Kaner
Publisher:
www.kaner.com
Issue/Date:Sunday, November 9, 1997
Back to Top
|
