Inefficiency and Ineffectiveness of Software Testing: A Key Problem in
Software Engineering
First Paragraph:
Most testing techniques in current use were developed
before 1980. Back then, significant programs were less than 10,000
statements. In the commercial environments that much testing theory evolved,
the programs were written in COBOL, a language designed to be understandable
by nonprogrammers. Under these circumstances, a subject matter expert could
serve as a tester, read the program, identify all the variables and their
most interesting interactions, and trace the key paths through the program.
Thoughtfully handcrafted tests, painstakingly documented, were the best
practice of the day.
Comments: Makes recommendations to rely more heavily on high volume
automation techniques;
retrain software testers to help them focus more effectively on risk; and
rework test documentation practices to provide only those details needed to
reasonably support auditing and test maintenance.
Author: Cem Kaner
Publisher:
presented at National Defense Industrial Association Workshop
Issue/Date:August, 2006
Testing in the
Dark
First Paragraph:
A project manager strides purposefully into
your office. "This disk has the latest and greatest release of our software.
Please test it. Today." You say, "Okay, sure...what does it do?" The manager
stops in his tracks and says, "Uh, the usual stuff..." Sound familiar? We've run
into this situation as employees and as consultants. And we've seen testers take
the disk, stick it in the drive, and just start testing away. That's testing in
the dark. We think there are approaches that are more productive. When we test
or manage testers, we plan the testing tasks to know what value we can get from
the testing part of the project.
Comments: Tips on how to test effectively, even when the
application under test is delivered with missing or no
documentation.
Author: Johanna Rothman / Brian Lawrence
Publisher:
stickyminds.com
Issue/Date:1999
Testing Justification
Checklist
First Paragraph:
Testing Justification Checklist This
checklist summarizes the steps for securing an investment in testing. The
process is neither sequential, nor automatic. That's part of the point. This is
essentially a mechanism for securing investment (resources and commitment) to
produce some value for the organization.
Comments: Busy companies trying to get a product out the door will
often require justification for the time and resources required for testing.
Here's a checklist to help you prepare to get that commitment from the
company.
Author: James Bullock
Publisher:
STQE Magazine
Issue/Date:Oct 10, 2000
Selecting Test Cases Based on
User Priorities
First Paragraph:
Your product's release date looms. Though
you're scrambling to cover every testing contingency, a worry still gnaws at
you: will the user base curse your name in three months' time as a poorly coded
module repeatedly causes problems? How do you know you've done every reasonable,
appropriate test?
Comments: This article is useful for testers who are part of the
test case/use case development process. The techniques described in this article
are part of the Rational Unified Process which identifies all external forces
(or "actors") that trigger system functionality. Each use case provides a
description of a use of the system by one or more of the actors.
Author: John D. McGregor, Melissa L. Major
Publisher:
Software Development Online
Issue/Date:March, 2000
On-Track Requirements: How to
evaluate requirements for testability
First Paragraph:
For most applications, a "high-quality" set
of requirements is a critical prerequisite for successful software development.
Identifying and eliminating problems in requirements is the best-known way to
improve quality and shorten the development and testing phases of a
project.
Comments: This article suggests evaluating techniques to look for
testability in requirements before development of a test plan.
Author: Rodger Drabick
Publisher:
STQE Magazine;
www.stickyminds.com
Issue/Date:Aug 31, 2000
