Name: Testing computer software
ISBN: 9780471358466

Testing computer software

"This book will teach you how to test computer software under real-world conditions. The authors have all been test managers and software development managers at well-known Silicon Valley software companies. Successful consumer software companies have learned how to produce high-quality products under tight time and budget constraints. The book explains the testing side of that success. Book jacket."--BOOK JACKET.

What Hacker News says

el_benhameenOct 2015

While other commenters are correct that manual QA is a mindset, there are readings that can help develop that mindset.

I have new QA engineers read the first five or six chapters of "Testing Computer Software":

http://www.amazon.com/Testing-Computer-Software-2nd-Edition/...

to get a feel for the mindset and methodologies and to help them understand what testing can and can't accomplish.

"Lessons Learned in Software Testing", mentioned by another commenter, is another good resource. Lots of good anecdotes:

http://www.amazon.com/Lessons-Learned-Software-Testing-Conte...

Both are a bit dated in some ways ("Testing" has a section on filing paper bug reports), but the lessons and thinking are still highly relevant.

thread

totalforgeApr 2011

The book 'Testing computer software' by Cem Kaner is an excellent introduction to the field.

You will make less than a programmer while being expected to possess extensive programming skills. Where developers produce code, therefore product, therefore generating earnings and profits, QA is a cost center and does not put revenue on the books. Thus, QA gets laid off more often and you can expect to work more as a contractor with no benefits.

Be prepared to spend much time explaining how the job provides value to managers and engineers over and over and over again. You need to present good data often, and be a strong salesman for your work. Expect to hear things like 'You mean you just play with the software?'. Have a good answer ready at all times.

At many shops, if a customer finds a single bug and you missed it, even though it won't reproduce on your test configurations, everyone will consider you a failure, in spite the value of your overall contribution. For some reason this never affects the developer who created the bug.

Now, if a legal precedent is ever set that software companies are held liable for their products, QA will become front line in a damn hurry.

thread

13of40Sep 2022

Reminds me of a book I picked up about twenty years ago called "Testing Computer Software". I think it must have been written in the 80s, because instead of having a bug database, it talked about filling out a hardcopy form describing the issue and dropping it off at the programming department. I reckon you'd want to do it in duplicate on carbon paper, just so you can keep it in your own filing cabinet.

thread

xstartupFeb 2018

McConnell, Steve. Code Complete. Redmond, WA: Microsoft Press, 1993.

McConnell, Steve. Software Project Survival Guide. Redmond, WA: Microsoft Press, 1998.

Maguire, Steve. Writing Solid Code. Redmond, WA: Microsoft Press, 1993.

Ranade and Nash. The Elements of C Programming Style. New York: McGraw-Hill, 1992.

Kernighan and Plauger. The Elements of Programming Style. New York: McGraw-Hill, 1982.

Caner, Cem, et al. Testing Computer Software, Second Edition. New York: Wiley Computer Publishing, 1999.

Hunt, Andrew, et al. The Pragmatic Programmer. Reading, MA: Addison-Wesley, 2000.

Holub, Allen. Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ Programming. New York: McGraw-Hill, 1995.

thread

dredmorbiusFeb 2014

It's a known thing. Look up "software defect estimation".

The methods aren't too dissimilar to how population ecologists estimate the population of a wild animal population (you tag individuals and note the rate at which you're repeated re-tagging the same ones), the estimated total falls out via statistics.

It's not a method that's applied frequently even within organizations (I've worked in and with QA numerous times), and my copy of Cem Kaner's Testing Computer Software doesn't seem to address the matter. Boehm's Software Engineering Economics discusses software reliability modelling at page 181 (Chapter 10: Performance Models and Cost-Effectiveness Models).

IEEE has "An efficient defect estimation method for software defect curves" which looks like it should cover the area, membership or purchase required:

http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=124539...

"Applying Software Defect Estimations: Using a Risk Matrix for Tuning Test Effort", James Cusick, Wolters Kluwer

http://arxiv.org/pdf/0711.1669.pdf

BUG COUNT ESTIMATION: http://www.testdesigners.com/bugnets/bugcountestimation.html

References Capers-Jones, leading authority in the field.

Many methods start with an assumption that software coding is essentially a progress of inserting bugs into code at a known rate (and there are studies which have established such rates with fairly high levels of confidence). So debugging and QA are then a bug removal function. Knowing what your bug insertion rate was allows you to estimate how many of those bugs you've removed.

That's the theory.

thread

dmd149Jan 2012

I'm looking to break into the start-up world and learn about software testing and product management. I picked up the book Testing Computer Software by Cem Kaner and started CodeAcademy lessons.

Anyone have any other books/suggestions to learn about coding, software testing, and product management?

thread