Software Testing Books

This book is packed with realworld knowledge and experience, written by people who have more than earned their title of expert. It covers many aspects of the software development world and adresses issues that you have most likely run into at some point, or are about to run into. Being able read how the experts deal with these things is very interesting indeed, it can either give you new ideas to better handle the issues, or it can be a confidence boost to see that the experts do things the same way as you.

For me, the part about the Iteration Manager and the performance testing were particularly interesting because I've had quite a few problems with this in the past.

Keep it up Thoughtworks!

This is a terrific book loaded up with 13 short, concise, golden essays from ThoughtWorks leaders like Martin Fowler, Neal Ford, etc. Each topic covers something pretty vital for those of us who care about being somewhere near the top of our chosen craft. Topics include solving the "last mile" problem between development and release, Ruby DSLs, polyglot programming, single-click deployment, and a bunch of other great reads. Each article is extremely well-written and useful, but I found a subset of the book particularly compelling.

Unfortunately, I only heard parts of Neal Ford's "Polyglot Programming" at his keynote at CodeMash 2008. I was thrilled to get to read his article in this book on how to leverage different languages on the same platform to solve different problems.

Jeff Bay's piece "Object Calisthenics" strongly reminded me of the glorious work The Practice of Programming from Kernigan and Pike in its emphasis on clean, simple, clear code. I'm all fired up to refresh my coding practices with Bay's exercise using nine points for pushing yourself into writing better object oriented code.

"Refactoring Ant Build Files" from Julian Simpson, along with Hatcher's Java Development with Ant, should be mandatory reading for anyone dealing with build files -- regardless of what build environment you're using.

Other big winners for me were the testing articles by Kristan Vingrys and James Bull, Dave Farley's work on one-click release, and Stelios Pantazopoulos's article on project vital signs. Of course, the remaining articles are also winners, it's just that these six or so really struck home with me.

Overall it's a fantastic work and I'm really glad I've got it on my bookshelf!

One nice thing about collections of short pieces is that you can work your way through them in any order and only read ones that look interesting without worrying about missing crucial information. That's how I read this book, and I enjoyed most of the selections I read. I thought that the one on OO coding was great as it had good concrete exercises to help folks go down that road.

Recommended.

I feel that every techie should take a step back once in a while and reflect on their profession. The ThoughtWorks Anthology: Essays on Software Technology and Innovation by ThoughtWorks, Inc. is one of those books that helps lead you down that path. While there are some good reads in here, the "level of resonance" will likely depend on your language of choice and development methodology...

Contents:
Solving the Business Software "Last Mile" by Rog Singham and Michael Robinson
One Lair and Twenty Ruby DSLs by Martin Fowler
The Lush Landscape of Languages by Rebecca J. Parsons
Polyglot Programming by Neal Ford
Object Calistentics by Jeff Bay
What Is an Iteration Manager Anyway? by Tiffany Lentz
Project Vital Signs by Stelios Pantazopoulos
Consumer-Driven Contracts: A Service Evolution Pattern by Ian Robinson
Domain Annotations by Erik Doernenburg
Refactoring Ant Build Files by Julian Simpson
Single-Click Software Release by Dave Farley
Agile vs. Waterfall Testing for Enterprise Web Apps by Kristan Vingrys
Pragmatic Performance Testing by James Bull

Based on the type of work that ThoughtWorks does and their development methodology, you'll understand and relate a lot more to the material if you're into things like agile development, Ruby, Ant, and other various open source software offerings. Granted, the argument could be made that *everyone* should be using those things, but the reality is that there are plenty of developers who don't or can't for various reasons. But once you get past that point, there's plenty of material here that should get you to think a bit... Lush Languages does a great job in turning the Java vs Ruby argument into one where you're considering multiple language options based on the problem domain. Polyglot Programming is also very insightful, as it addresses the use of multiple languages within a single project so that you can get the best of all possible worlds. If they are all running under the same JVM, there's few reasons not to take advantage of the various strengths. I also enjoyed the Object Calisthenics entry, as the exercises force you to rethink program design without resorting to techniques that can get out of control very quickly. Many of the other chapters are a bit more focused on topics that might or might not work for you if you're not already using that software/approach. You can always dig out one or two items that are not specific to the tool (as in development tool programming should fall under the same level of control and planning as production code), but you have to work a bit harder to get there.

If you're into the particular tools outlined here, by all means get the book and read it. If you're not at that spot for whatever reason, it's still worth reading. Just be prepared to work a little harder and/or realize that some of the chapters just won't do much for you.

I bought my first copy of this text in 1992 and it has been my constant companion and mentor ever since. From my early Pascal days in college to J2EE development in present times, I have always found the authors' treatment of the discipline of software engineering to be concise, accurate and relevant to the issues at hand. It is one of those books that code shovellers hate...an uncompromising publication that addresses serious process issues such as requirements specification, rigour, interface design and modularity, and robustness. These matters just refuse to go away, and the authors of this book know it. This book is timeless.

Simply the best textbook on software engineering. Concise content and extensive coverage of most conventional SE topics. For students and practicioners who are interested in learning more than drawing simplistic diagrams.

This book is in overall close to very good. Some confusingthings are the unclear differences of USE-relationship, and otherrelationships. I probably include more comments in the future. END

There hasn't been a test I've seen that Mosby's PDA version didn't have information on. I have it on my Window's mobile phone and it works great. Easy, quick reference.

This is a greta product. I would definately recommend it for anyone needing quick access to all sorts of Lab information. I am in nursing school and with the PDA I have access to all of the information that I need. It is a lifesaver. The information is quickly accessed and accurate. It has been great in Clinicals.

Once I figured out how to get it onto my smartphone, the product works like a charm with no glitches. It is quick, easy-to-use, easy to understand, well-organized and extremely reliable. I use it every day for nursing school. Overall, I definitely recommend purchasing the PDA version, rather than getting the book (much less cumbersome).

I purchased this book after reading the reviews. I have not read it cover to cover, since I am using it as a ready reference in my medical device consulting practice. As such, it has proven its worth. Under one cover, it provides an overview of the most prevalent testing techniques and related subjects, including the very important (to me and my industry) issues of quality / risk-based testing (risk assessment, management, et al). It pulls in applicable standards (ISO, IEEE ...), and supplements narrative with appropriate graphics (diagrams, flow charts ...). As with all my reviews, I view a book as useful if it provides just a few immediately useful points for my understanding and my business. Pragmatic Software Testing by Rex Black supplies such points in abundance, and has become one of my top "go-to" references in product / production / test equipment software testing / verification and validation. Incidently, a scan of most of my reviews will show 4-5 stars. This is because I only choose to review what I consider useful publications I have read. I d/n bother "panning" those I d/n find useful -- and there are others I haven't yet read, of course.

There is nothing wrong with this book but on the other hand there is nothing essential here that hasn't been covered thoroughly in several other books. I prefer Patton's "Software Testing" 2nd ed., for example, for principles and McCaffery's ".NET Test Automation" for code techniques. My advice is to compare the table of contents of several software testing books before you pick this book.

If I could only buy one software testing book (or, more realistically, if I only had time to read one), this would be it. This is a practical guide with realistic, useful and immediately applicable techniques that save time, improve test quality and improve testing effectiveness. It's a must read for my department.

Now in a fully updated and significantly expanded second edition, "Software Testing Foundations: A Study Guide For The Certified Tester Exam" is the collaborative work of Andreas Spillner (Professor of Computer Science at the Department of Electrical Engineering and Computer Science at the Bremen University of Applied Sciences), Tilo Linz (President of the German Testing Board and the CEO of Imbus AG - a leading service company for software testing in Germany), Hans Schaefer (President of the Norwegian Testing Board and an independent software consultant), who are among the founders of the International Software Testing Qualifications Board (ISTQB). This instructive manual is specifically designed by acknowledged experts for personal self-study and provides all the necessary information required to pass the Certified Tester Foundations level exam as defined by the ISTQB. This new and thoroughly 'user friendly' edition covers both a test-first approach and risk-based testing., as well as the fundamentals of testing, testing and the software lifecycle, static and dynamic testing techniques, test management, and test tools. "Software Testing Foundations" is a critically important and core addition to professional and academic Computer Science reference collections.

Are you a software tester? If you are, then this book is definitely for you. Authors Andreas Spillner, Tilo Linz and Hans Schaefer, have done an outstanding job of writing a book that offers basic knowledge that helps to achieve structured ad systematic evaluation and testing.

Spillner, Linz and Schaefer, begin by discussing the basics of software testing. Then, the authors discuss which test activities should be done during the software development process, and how they relate to other development tasks. Next, they discuss static methods. The authors also deal with testing in a narrower sense. Finally, the authors show you which aspects should be considered in test management, how systematic incident handling appears, and some basics about establishing sufficient configuration management.

This most excellent book is written in such a way that it does not presume previous knowledge of software quality assurance. Perhaps more importantly, this book is designed as a textbook and is meant for self-study.

There are now three well-known books on the ISTQB syllabus for foundation software testing examinations. This was the first, and the others may have since taken a different emphasis. Originally written in German, the book has been translated into English, and covers basic testing topics.

The difficulty about a testing book is that it will be read by testers, trained to find faults as part of our role in life. This book may to be aimed at the non-English, European market place, following its origins. Some of the translation is `interesting', and is more literal than catching the meaning of the words, so can read in a stilted fashion. Annoyingly, there is reference to `chapters' in the chapter on techniques, when it clearly means `sections' or part-chapters. The discussion of the value of a certified tester in chapter 6 would be better in the introductory chapter 1.

Spillner, Linz and Schaefer are well respected in the testing community, and have written a book that covers the syllabus. However, it is not greatly geared towards the examination; although there are revision questions, these are neither multiple choice, nor are the answers provided. There are also areas where there is significant extension beyond the syllabus content (standards is a case in point - and can probably be correctly attributed to a specific one of the authors).

There is a good glossary of testing terms, and the text clearly identifies items that appear in the glossary. It is useful to not only have web links, but also to specify when the web links were known to be valid. I found the use of a case study that runs throughout the book to be helpful. There are some key thoughts that are well worth remembering; one for me was "Robustness has its costs".

Strangely, I would say that there is both too much code (pseudo-code) present, and too little. It is perfectly possible to pass the ISTQB examination with little or no knowledge of how to read or write code, and references to code in early chapters could have non-coders pressing the panic button. Conversely, any discussion of structural test techniques should have examples of code, as exams routinely have code-based questions concerning techniques. The treatment of statement testing was somewhat shallow, with the cases where there are `empty' branches and non-empty branches barely distinguished. However, the coverage of when to use particular techniques was good and comprehensive.

Discussion in an early chapter postulates determining whether a set is code is ready to exit a particular stage of testing by examining the number of incidents raised per testing hour. It even suggests than when down below 2, it may be time to ship. This is a good notion, but I suspect the numbers are out by some way. To be still finding 2 incidents per testing hour, even on very large, complex systems, would indicate to me that the product is NOT ready for shipping. Additionally, the treatment of cyclomatic complexity is adequate, but this useful measurement is only calculated one way, not using the alternatives that are available (the most straightforward being `the number of decisions + 1').

There is a lot of material covered, and in some places, this appears rather list-like in appearance, unclear when lists are contained in the syllabus, and when not. It is better to say that the book assists candidates in preparation for the ISTQB Foundation, rather than being a direct aid as the sole point of reference. Read it take good things from it and mind the short-comings, but do not use it as your only testing book.

Peter Morgan, Bath, UK (morganp@supanet.com)

It's the ONLY ONE "thick" book at the market about Visual Test 4.0. I am a beginner in the QA area. I bought this book, read it from cover to cover, it tooks only 2 weeks to do it. It was so good and well-written ! If you want to be a PERFECT QA programmer I strongly recommend to read this book. You can use the test scripts on the diskette ( included with book ) as templates and create professional test projects. Good Luck !

If you are new to Visual Test and need to get up to speed in no time flat, this is the tool for you. I had a vicious deadline to design an automation library in VT for our QA team at work. I was able to read the book in two days and start designing industry strength automation script in no time at all.

This book is a must have for Software QA/Test professionals who have been given the task of automation of testing for their projects or company. The author explains things in simple terms, but does not talk down the audience. Mr. Arnold hits on the principles of Automation for testing and relates them to Visual Test quite nicely. Although the book does not go into great detail on the tool and its language it does give a good general feel and direction on how to first look at how to setup/prepare for automation and how to begin to use the tool to start on the automation path. The book starts off with the basics; Why automate testing? What are the expectations and realities of the task of Software Test Automation. The first 40 pages give insight to the experiences and lessons learned by the author in his efforts with the tool and with automation in general. A lot of people can relate to this section. I know I did, and then some! Having worked with other tools and my personal experiences with automation I felt I was reading my own diary. Next, the author moves you into the following sections building up your knowledge of the tool and how to take advantage of it through examples. This process is general in the respect of automation and specific in how to use Visual Test to perform the automated testing. A lot of the examples could be translated to similar tools and spurs the idea process for the intended audience. It takes a "why reinvent the wheel approach", and helps the reader/user get going with automation. The reader/user starts with simple test cases and moves onto test suite drivers with a finish on how to create and run a complete benchmark test of all the test suites & test cases. Finally, the book goes into the more specialized and advanced topics of automation and how to use Visual Test to perform the tasks associated to them. These sections are a boon for the QA/Test professional. They show how to work more closely with the computer and within it. The paradigm of Client/Server testing is incorporated with the Network Distritubuted testing information. This shows how to get more bang for the buck out of test automation and Visual Test. One of the overall best parts of the book is the numerous Notes, Tips, and Personal Stories that the author has included in the text. This makes it more enjoyable to read. The author could easily take a half the book again and just write a general text on Automation of Software Testing itself. If I were to write a book on Software Testing Automation, I would have done it like this. Too bad Tom Arnold beat met to it!

Whether you are looking for a beginner's book, or a specialist's reference document in software testing, this books provides it.
I have known Paul for a number of years and we worked together on the ISTQB Advanced Level syllabus, so I can vouch that this is really a compendium of techniques, methods and thoughts that can be used by all, including as basis for Advanced Level courses.
Even though the previous (2nd) edition was good, this one expands on it, and touches topics such as multiprocessor testing (look up the term "threads"), All Pairs and Exploratory Testing. And always with the cheerful yet thought provoking way, one has come to associate with Paul.
A book to have not only on one's shelf, but as a reference on one's bedside table.
I really enjoyed it Paul, and I hope that all of you who buy it will enjoy it too.

This book has typos throughout the first 5 chapters we have covered
so far in class. I could not find an errata sheet on the publisher's
web site. The instructor of my Software Testing class says the author
has left these errors in the 2nd edition "for the students to discover".
Apparently, a student will know the subject of Software Testing very well
IF they can find the errors throughout the text!

In other words, a student can't trust the text as an authority on the
subject, but has to discover the errors in the text WHILE attempting
to LEARN what the text is teaching?

FollowUp: I have received an errata sheet from the publisher.
I had to request it through their "Contact Us" link.
Unfortunately it also contains errors that were corrected in the 2nd edition.
but at least one "glaring" error (the year 2000, instead of 1900 in the
NextDate program) is not mentioned. I hope they get that fixed with the
3rd edition (due soon).

Books on software testing fall into two basic categories: (1) those that deal with the test process and (2) those that deal with the actual techniques. Most of the more recent books fall into the first category; although there is some degree of crossover in many of the books. This book, however, deals strictly with techniques. The author doesn't dwell on the process or the associated administrative tasks, although he does touch upon them.

Techniques are presented within the context of formal mathematics. This isn't because the material is academic - it's all based on realistic testing scenarios - but, instead, provides you with proven and effective techniques for testing software in a systematic manner. Because many testers have not been exposed to the formal techniques and underlying math, the first section covers the basics: discrete math, set theory and graph theory. Once you've mastered the basics, which are heavily used in the chapters that address the actual techniques, you'll have all the knowledge that you need to go forward.

The remainder of the book is divided into four sections, each of which covers a specific type of testing. These types are: functional, structural, integration and system, and object-oriented testing. For each there are two to three techniques, plus a retrospective on the section that ties everything together. Also, issues and factors associated with each test type, as well as testing in the whole are discussed, giving you a complete picture of the full suite of testing categories.

Overall, this book is well written and illustrated, but requires effort to get through. This isn't a criticism of the author, who did an outstanding job of conveying information and clearly explaining complex concepts and topics, but reflects the depth of the material. In my opinion a copy of this book should be among the top five in any serious software test professional's library.

This book is absolutely targeted to software testers. This isn't an in-depth discussion of why one should use C#'s "as" keyword for safe casting, nor will you find details on asynchronous communication. What you will find is a quick coverage of enough basics to enable testers to start hitting web services, Windows and ASP forms, and even deal with basic COM interoperability

The book is well-written, concise, and in a good voice. The authors carry a common project through much of the book, using the development of a bug reporting system to lay out .NET fundamentals. They use a nice building block approach along the way, starting out sections with the extreme basics and moving on to mid-level topics. (You won't find anything particularly advanced in the book, but again, the focus isn't on pointy-headed developers, it's on pointy-headed testers.)

There are several things I don't care for in the book, mostly from a software engineer's viewpoint. One thing would be the authors' notion of code reuse via copying in code or classes vice simply referencing a different assembly and keeping code in one central spot, but that's from a SE's viewpoint...

This isn't a book for any developer to fool with, but it's an invaluable book for testers looking to learn programming in .NET, specifically tailored for their work as a tester.

This book is well written, with enough demo code to appeal to those testers with programming experience, yet understandable for those less technical. The organization is superb, with appendices to provide more in-depth information and quick reference, allowing the more experienced readers to jump right to the areas of interest. Definitely a valuable tool for anyone involved in testing .NET applications.

I can't say enough nice things about this book. It is wonderfully written, beautifully organized, and chock full of details that everyone involved in software development and testing should know. It is also extremely practical and hands-on. If you are developing .NET software or testing it, you should stop what you are doing until you get your hands on a copy of this book and read every word. I've been a developer for over twenty-five years and learned hundreds of things from reading this text, yet it seems like it would be very easy for a relative beginner to get as much out of as I did because all of the explanations are plain and fairly simple.

This is a great book for anyone who plans on using boundary scan. I have been working in boundary scan for years and found areas of this book very useful.

Since the mid-1970s, the structural testing of the loaded printed circuit boards (PCBs) has relied very heavily on the use of the so-called in-circuit "bed-of-nails" technique. This method of testing makes use of a fixture containing a bed-of-nails to access individual devices on the board through test lands laid into the copper interconnect, or other convenient contact points. Testing then proceeds in two phases: the power-off tests followed by power-on tests. Power-off tests check the integrity of the physical contact between nail and the on-board access point. They then carry out open and shorts tests based on impedance measurements. Power-on tests apply stimulus to a chosen device on a board, with an accompanying measurement of the response from that device. Other devices that are electrically connected to the device-under-test (DUT) are usually placed into a safe state (a process called "guarding"). In this way, the tester is able to check the presence, orientation, and bonding of the DUT in place of the board.

Fundamentally, the in-circuit bed-of-nails technique relies on physical access to all devices on a board. Such was the technique in the mid-1980s when a group of concerned test engineers got together to examine the problem and its solutions. The method of solution was based on the concept of a serial shift register around the boundary of the device - hence the name "boundary scan".

Principles of Boundary Scan
Each primary input signal and primary output signal is supplemented with a multi-purpose memory element called a boundary-scan cell. Cells on device primary inputs are referred to as "input cells"; cells on the primary output are referred to as "output cells". The input and outputs is relative to the core logic of the device. The collection of the boundary cells is configured into a parallel-in, parallel-out shift register. A parallel load operation, called a "capture" operation, causes signal values on device input pins to be loaded into input cells and, signal values passing from the core logic to the device output pins to be loaded into output cells. A parallel unload operation called an "update" operation causes signal values already present in the output scan cells to be passes out through the device output pins. Signal values already present in the input scan cells will be passed into the core logic.

Data can also be shifted around the shift register, in serial mode, starting from a dedicated device input called TDI and terminating at a dedicated device output pin called TDO. The test clock TCK, is fed in via another dedicated device input pin and the mode of operation is controlled by a dedicated TMS serial control signal. At the device level, the boundary scan elements contribute nothing to the functionality of the core logic. In fact, the boundary scan path is independent of the function of the device. On board the four; boundary scan devices are connected from one to the next in a serial format. The TDI input to the board is connected to the TDI input of the first device; the TDO output of the first device is connected to the TDI input of the next device; and so forth; creating a global scan path terminating at the TDO connecter output. TCK is connected in parallel to each device, TMS the control pin works similarly.

In this way, particular tests can be applied to the device interconnects via the global scan path by loading the stimulus into the appropriate device output scan cells via the edge connecter TDI (shift-in operation), applying the stimulus (update operation), capturing the responses at the device input scan cells (capture operation), and shifting the response values out to the edge connector TDO (shift-out operation). Essentially the boundary scan cells can be thought of as the "virtual nail".

There are four modes to be aware of normal, update, capture, and serial shift. During normal mode, data_in is passed straight through to Data_out. During update mode, the content of the output register is passed through the Data_out. During capture mode, the Data_in signal is routed to the shift register and the value is captured by the next ClockDr state. During shift mode, the scan_out of the register flip flop is passed through to the scan_in of the next via a hard wired path.

I found this a super book for both the novice software tester and the expert. It offers descriptions of the different types of testing, table of contents for test plans and all other documentation needed for testing. The only problem with this book (second edition) is that it does not include Windows software testing - a whole different "kettle of fish"! If you want to do a thorough job of testing your FORTRAN or C code this is a must!

This book provides an excellent insight into the topic of software testing. The subject is now of interest to a wide business audience, not just software engineers, and they are well served by this book. The writing is fluent and lucid and allows those new to the topic to gain a thorough understanding.Both the theoretical and practical aspects are covered, and reinforced with examples.