Please recommend Good Books

[code...@gmail.com]

Hi,

I am looking for some good Software Testing Books to explore the
following areas.

1. Record and Play Back Testing.
2. Testing Web Applications
3. Writing Automation in C++
4. Code Coverage Testing

Also any other CLASSICALS in Software testing are welcome to be
recommended.

Thanks

[Phlip]

codefixer wrote:

> I am looking for some good Software Testing Books to explore the
> following areas.
>
> 1. Record and Play Back Testing.

Both manual testing and "automated manual testing" waste time. If developers
don't write unit tests as they write code, they will spend long hours using
a debugger to extract bugs. Then they will produce code that is not designed
for testing. This leaves only the GUI as an interface for testing.

If you instead solve the root problem, developers will write tests as they
write the tested code. Then testers can maintain and upgrade these test
suites.

> 2. Testing Web Applications

Use HttpUnit or WebUnit to drive a server thru its HTTP socket.

> 3. Writing Automation in C++

/Unit Test Frameworks/ by Paul Hamill covers CppUnit.

> 4. Code Coverage Testing

/Test-Driven Development: By Example/ by Kent Beck. If you never write any
code without first writing a test that fails because the code is not there,
then your coverage will be very high. And your velocity will be high,
because you don't need to retrofit these tests, or then spend time ensuring
they cover.

--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

[qaseason]

There are several books on all of these subjects at
http://stickyminds.com/books.asp?tt=Books+Guide - just search for your
interest. You can also read or write reviews on each book. Hope this
helps.

[Edward Berard]

In article <1109952229.9...@o13g2000cwo.googlegroups.com>,
<code...@gmail.com> wrote:

A list of software testing classics would include the following
books:

[Beizer, 1990]. B. Beizer, Software Testing Techniques, Second Edition,
Van Nostrand Reinhold, New York, New York, 1990.

[Kaner et al., 2002]. C. Kaner, J. Bach, and B. Pettichord, Lessons
Learned in Software Testing, John Wiley and Sons, New York, New York,
2002.

[Myers, 1979]. G.J. Myers, The Art of Software Testing, John Wiley &
Sons, New York, New York, 1979.

A list of "classic software testing articles" would include:

[Fagan, 1976]. M.E. Fagan, łDesign and Code Inspections To Reduce
Errors in Program Development,˛ IBM Systems Journal, Vol. 15, No. 3,
July 1976, pp. 182 - 211.

[McCabe, 1976]. T. McCabe, łA Complexity Measure˛ IEEE Transactions on
Software Engineering, December 1976, pp. 308 - 320.

Some things to keep in mind:

-> The term "classics" usually implies that the reference has
"withstood the test of time." Hence, references less than
say ten years old may not be considered "classics" by some.

-> People sometimes have a hard time separating a technique
from where, when, and in what context, it is used. For
example, black-box testing techniques can be used in
"test-driven development" (TDD), "test as you go" approaches,
and in "testing-V" situations.

-> "Management" encompasses planning, monitoring, and controlling
efforts. There are also classic software testing management
references you should consider. Poorly-managed testing efforts
are an ever-present threat to any project.

-> Automated software testing techniques and tools have been around
for well over thirty years. Hence, it should come as no surprise
that there are literally thousands of off-the-shelf automated
testing tools. However:

* "A fool with a tool is still a fool."

* Although there are some automated testing techniques that
can automatically generate and execute test cases, even
these tools require intelligence, training, and planning
on the part of their users.

-> Metrics are an important part of any testing effort. Simple
"pass-fail" metrics are only the beginning. For example,
consider the trade-off between "passing all the test cases
in a testing suite," and "adequate testing coverage."

-> Not all test cases are "pass/fail." Some testing cases, for
example, gather information about the item under test.
Consider stress testing and usability testing as two examples.
(Depending on how the customer/user specifies their requirements,
it may be possible to pass/fail at least some stress test cases,
and at least some usability test cases. At other times, the
customer/user may need certain information to help plan for
(anticipate) product enhancements, or to be aware of situations
that may be potentially troublesome.)

I hope this helps.

-- Ed

--
Edward V. Berard | Voice: (901) 309-1912
The Object Agency, L.L.C. | Fax: (901) 755-5622
2965 Cane Creek Drive | E-Mail: e...@toa.com
Germantown, Tennessee 38138 | WWW: http://www.toa.com