Software Testing Books

This book provides meticulous details about QA for integrated software and component-based software .This particular book teaches how to approach testing and QA in a systematic manner .The book gives an organized and detailed description for the Software Quality assurance for the software components. It teaches all the way from very basic step. Beginning with Black Box testing and following White box, Regression testing, Performance, System level testing .The approach includes various different validation methods that needs to be rigorously applied and a detailed QA approach which teaches all the possible Test Cases. Overall this book provides a complete teaching of the Component Based Software. Being Professor Jerry Gao's student, have completed software quality and testing courses under him. This book has increased my knowledge for component-based software testing as it describes different testing methods, phases, issues, challenges etc. I highly recommend this book for college graduates and professionals who want to brighten their career in QA and testing areas.

This is a very unique book on QA and software testing topics because it discusses some of the testing techniques & concepts extended from research world and also covers the modern software component concepts and the applicability of these techniques on them. The book is divided into IV parts. The first part introduces the reader with software components and it's testability. The model based solution to some of the issues and challanges can be applicable to the SOA based softwares as well.
Part II of the book discusses the fundamental black box and white box techniques. A section is devoted on white box techniques for object oriented testing.
Part III of the book focuses on most important challanges of todays software. The UML based approcah to software integration testing discussed in this book uses an unique approach of content and context based relationship of objects. Regression testing for maintaining software is discussed in detail.
Part IV is entirely devoted to QA topics. They fully cover QA measuremnet and validation topics, standards and certification.
This is a must have book for software developer, Test engineer and QA professionals. The references at the end of each chapter reminds you to go deeper and dig into IEEE and ACM papers on the subject. I have already recommended this book to my fellow software developers and managers.

The book has detailed coverage of all software testing terminologies and methodologies such as black-box, white-box, test automation, integration, and performance testing.Over all, this is a very good book for learning Testing techniques for component based software.This book is extremely well organized and should be useful for both novice and experienced software testers.

I learned many new concepts about Software Testing from this book. I learned how to do the manual testing, automation testing of the component software using this book. White Box Testing, which involves Control Flow Graph is documented well in this book anyone who wants to learn about the White Box Testing can easily learn through it. This book is very user friendly in terms of doing Software Manual Testing.
Automation Testing is described well too. I recommend anyone from Software Engineering planning to go into Software Testing should read this book atleast once.

This book helped me gain good knowledge about Software testing, its objectives and various approaches for real time experience. It helped me understand the basic concepts and fundamentals of Software component testability. Through this book, I got a basic idea about the rules and methodologies that are being implemented and followed in current software testing field, as per industry standards.

Black box and White box testing techniques and their relevant issues, challenges and solutions, the various test models, everything is explained very visibly. It serves as a good guide for the beginners as well as the Software professionals of all levels. Information on testing methods like Regression, Integration, Performance and System testing are detailed in a systematic manner.
The information in this text book, taught us to follow the best ways to achieve a well defined test coverage criteria by deriving a definite plan for the project- a plan for managing the schedules, designing and testing the software based components to meet the requirements in the project within a deadline. We, in a team, worked on a Simulated ATM machine, for a practical experience, and the book helped us as a good start. Each chapter has a good introductory part, which gives a clear synopsis about the complete chapter.
The book explains the role of different testing tools, designing and handling the test cases, how to perform component testing quickly and efficiently through automation testing, without manual involvement. Manual testing is time consuming and hence to solve this issue, Automation testing has been introduced lately and this information has been illustrated by the authors very clearly in the book, with suitable examples for the readers understanding.

I personally found this book very helpful and knowledgeable. A Software component's life cycle through the testing phase has been explained well, alongside giving us information about the methodologies to improve the quality of a product, and how to derive a test case to support the functionality; everything is mentioned in this book. My only suggestion is, this book is a complete pack of information on testing of a Software component and its Quality assurance, and hence, from college students to Software professionals, everybody has to experience this book, if they are seriously looking to pick up their career in Testing.

This is a readable, practical, and deep book. It's one of those books which teaches or refreshes Java and OO theory and practice as you read. I am also reading it for pleasure!

This is a great book. It is directed at users of JUnit, the Java unit testing framework. But in my mind the book gives sound advice for solving your programming problems in general, not just for Java or JUnit testing. It stresses the importance of unit testing, programming to interfaces instead of implementations and just simple common sense. The author is clearly passionate about his field and extremely experiences. The combination of enthusiasm and experience comes through on every page.

This review also appears on StickyMinds at http://www.stickyminds.com/s.asp?F=S767_BOOK_4

JUnit Recipes is a comprehensive tome of practical methods and techniques for the opensource JUnit tool to develop automated unit-tests for Java/J2EE applications. The book is split into four parts: Building Blocks, Testing J2EE, Additional JUnit Techniques, and Appendices. The Building Blocks cover the basics of using JUnit to create basic tests, organize and manage test suites and test data, running JUnit tests and reporting the results. It even includes a section on troubleshooting. Testing J2EE covers XML, JDBC, EJB, web components (including JSPs), and J2EE applications. Additional techniques include testing some well known design patterns, using JUnit add-ons and JUnit libraries (like GSBase). The Appendices include complete solutions (including code of course), some short and sweet essays on testing, and a modest recommended reading list.

The organization of the book flows very logically and the writing style is very clear and easy to follow. Along the way many insights into important design principles and testing techniques are revealed: the reader will learn about the "Hollywood principle", the Open-Closed principle, design patterns, POJOs, Mock Objects, Private and Parameterized Test-Cases, Abstract Test-Cases, Self-Shunts, and Spys. The book's coverage is very comprehensive and touches on many other popular Java/Enterprise projects and frameworks such as Struts, JBOSS, Prevayler, XDoclet, Tomcat, XPath, XMLUnit, HTTPUnit, Ant, Jakarta, and others.

Even though JUnit is often associated with "Agile" development and much of the wisdom apparent in the book applies to agile Java development, the book is useful to any Java developer on any Java project (agile or otherwise). The book also goes into considerable detail, with working code examples, to spell out exactly how to perform and apply the techniques it describes.

The book's primary audience is Java developers. Java Tester's will still find some good nuggets of information but it's quite clear that Java programmers and developers are the target audience. This isn't some high-level theoretical book mostly of concepts and ideas. This is an imminently pragmatic guide that not only conveys a great deal of highly practical wisdom but also clearly and comprehensively walks you through the explanations and the code to accomplish and apply the techniques it describes. The book is also not a "How To" for coming up-to-speed on setting up and running JUnit.

Another book from the same publisher, "JUnit in Action" is a great overview on learning more about the basics of running and using JUnit and on using JUnit to tackle a number of basic challenges with unit-testing Java and J2EE code. JUnit Recipes has some overlapping material but pretty much "picks up" where "JUnit in Action" leaves off, and JUnit Recipes goes into much more breadth and depth of coverage of JUnit methods, practices and techniques and use with other Java projects and frameworks.

I would say JUnit Recipes should probably be required reading for anyone attempting to use Java, J2EE and JUnit in the real-world.

This isn't necessarily the best introduction for absolute beginners (I would recommend /Pragmatic Unit Testing/ for that), but it is required reading for server-side Java, as most other reviewers have pointed out. But it's more than that--it's one of those rare computer books that transcends its subject matter. Why? Because it can make you a better programmer. While some of the credit can rightly be given to unit testing and Test-Driven Development in general, Rainsberger's book makes you /see/ better ways to write and refactor your code. The breadth and depth of examples is astonishing--he convincingly shatters "but it's too hard to test that" arguments with well-researched, non-trivial examples. In fact, I'd say that this is almost a better J2EE tutorial than most books about J2EE proper.

I'm withholding a star for one reason: the book doesn't cover GUI testing tools like Jemmy, JFCUnit, or Abbot/Costello. These JUnit extensions are ripe for a book with this depth; it's just too bad that this couldn't be that book. Other than that, I find that I turn to Rainsberger's book far more often than any other testing book or online reference.

Rainsberger does a very good job of detailing the techniques to unit test difficult code; including xml, ejb, servlets, jsps etc.

I had originally bought this book for son who was going to spend the summer working for my development team writing unit test for our database POJOs. I was so impressed way in which concepts were incrementally introduced I read the book cover to cover. It is now the only book I recommend to beginners and I introduce it as a 'must' read for all my new hires.

This is my new favorite-book-to-give-to-anyone-who-is-learning-or-using-Java.

The title is misleading in that this book is about much more than just the Agile Programming stuff. While it does a great job talking about Agile techniques and always starts by creating a unit test, the book really is about all aspects of Java (specifically Java 5) programming. Anyone who takes the time to work through the examples will become a much better Java programmer.

OO patterns, collections, type safety and more are covered and explained in the context of a rich, in-depth example. And because the author has you construct a high-quality test suite around the example, you are free to experiment with different ways to implement each new feature - thus proving to yourself the benefits of Agile design.

Just like it says in one of the quotes on the cover, this book is now required reading for the Java programmers at our company.

I'm not a beginning programmer, or even an absolute Java novice, so maybe this book isn't really aimed at me. My biggest gripe is that the code snippets continue on and on making the book very poor for anything other than cover-to-cover reading.

I've gotten about 6 chapters into this book and I love it. I've been developing Java for almost 7 years and am currently teaching myself Agile principles and this book comes as a great help.

This book is primarily for new programmers who want to learn Java as their first programming language. The book can also be helpful for programmers familiar with test driven development (TDD) but new to Java, or vice versa. I am an experienced Java developer, and I found that going through Agile Java presented me with a new and better way of approaching Java code development. This book covers Java 2 Standard Edition (J2SE) version 5.0, but covers only a few of the additional APIs at an introductory level. Technologies that are used pervasively in the majority of enterprise applications, such as logging, JDBC, and Swing, are presented in Agile Java. Some of the information, such as that on logging, will teach you all you need to know for most purposes. Other lessons, such as those on Swing and JDBC, will give you a basic understanding of the technology and will tell you where to go when seeking further information.

The core of Agile Java is fifteen lessons of about 30 pages each. It starts with baby steps in Java, TDD, and OO. The book finishes with a strong foundation for professional Java development. The core lessons should be read sequentially since each lesson builds upon the previous ones. Once you have completed the core lessons, you should have a solid understanding of how to build robust Java code. If you haven't completed the fifteen core lessons, you should not assume you know how to write good Java code. Each of the fifteen core lessons in Agile Java has you build bits and pieces of a student information system for a university. This single common theme helps demonstrate how you can incrementally build upon and extend existing code. Each lesson also finishes with a series of exercises. Instead of the student information system, the bulk of the exercises have you build bits and pieces of a chess application. Some of the exercises are involved and quite challenging, but they are where learning the methodology really begins.

There are three additional lessons to cover a few more Java topics. Two of the lessons present an introduction to Swing. These two lessons will provide you with enough information to begin building robust user interface applications in Java. But the bigger intent is to give you some ideas for how to build them using TDD. The third additional lesson presents an overview for a number of Java topics that most Java developers will want to know such as JARs, regular expressions, cloning, JDBC, and internationalization.

I really liked how the author integrated the three concepts of Java programming, TDD, and object-oriented design without confusing matters. The book is very clear with good illustrations. I highly recommend it. The following is the table of contents:

Lesson 1. Getting Started
Lesson 2. Java Basics
Lesson 3. Strings and Packages
Lesson 4. Class Methods and Fields
Lesson 5. Interfaces and Polymorphism
Lesson 6. Inheritance
Lesson 7. Legacy Elements
Lesson 8. Exceptions and Logging
Lesson 9. Maps and Equality
Lesson 10. Mathematics
Lesson 11. IO
Lesson 12. Reflection and Other Advanced Topics
Lesson 13. Multithreading
Lesson 14. Generics
Lesson 15. Assertions and Annotations
Additional Lesson - Swing, Part 1
Additional Lesson II. Swing, Part 2
Additional Lesson III. Java Miscellany
Appendix A: An Agile Java Glossary
Appendix B: Java Operator Precedence Rules
Appendix C: Getting Started with IDEA
Agile Java References

This book is about web testing in general, not just performance testing, and is a must have for the professional testing engineer. Chapters 7 and 8, on performance and scalability give a very good introduction to the subject, and include a great sample performance testing plan.

Michael Czeiszperger
Web Performance, Inc. Stress Testing Software
http://www.webperformanceinc.com

When industry leaders such as Cem Kaner and Bret Pettichord extol the virtues of this book you can be assured that it is great - everything they and other reviewers have said is on target. Moreover, you'd be hard-pressed to walk into the testing area in any company and not see a copy of this book on someone's desk.

That said, instead of this book you should get the second edition, which is a major rewrite, and also expanded in scope to include testing mobile systems. This edition is titled, "Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems" ISBN 0471201006, and is everything others have said about this first edition - and more!

Even with a better second edition, this book deserves the five stars I gave it because of the influence it has had on the testing profession. Moreoever, this first edition is not out-of-date, and is still a great book if you don't need information about testing mobile web systems at this time (although it's a safe bet you will in the future).

Grey box testing is based on a general understanding of a system's architecture and components. This understanding drives test strategy and identifies opportunities to test components in isolation.

The shade of grey can vary from white box testing (full review of source code) to black box testing (no review of source code). You choose what level of information to gather depending on your budget, capabilities and judgment.

This book provides the first detailed approach to grey box testing, focussing on web-based application architectures. These architectures are based on a heavy use of components: application servers, web servers, load balancers, databases and the like. This book describes these components, suggests how they can fail and what you can do to anticipate, trigger, or detect such failures.

This approach is supported by the author's extensive experience testing web-based (and other) applications as president of a software testing company. It is augmented by plenty of good advice on how to communicate test results clearly.

I have been in web testing for 3.5 years and this was the first book I found on the subject. My only complaint is that it took so long to come out, but I won't hold that against Nguyen or Wiley. It is a superb introduction to the complexities of web testing, which despite the protests of standalone application testers, is much more difficult and technical than traditional application testing. Not only does the tester need to know the basics of application testing, he or she has to know about the complex technology behind the site or application, and Nguyen's book is unbeatable. I've recommended that everyone on my team read it, since they are all new to the art of web testing. I read it cover to cover and it didn't really cover anything I had not learned in 3.5 years of experience, but had it been published when I started, I would have been able to ramp up so much faster. I also recommend that application developers read it in order to understand the role of a tester and to develop professional respect for a much-maligned profession.

This is good book. If you test web apps, you should buy it.

Hung Nguyen and I are co-authors of another book and good friends. I am not an unbiased reviewer. On the other hand, I wouldn't write this review if I didn't believe every word of it.

Hung's book breaks new ground. It will be useful today, and I believe it will have lasting value and influence.

Once you get beyond the superficial (not unimportant, but much less difficult) issues of usability testing that dominate so many discussions of web testing, you run into the really tough problems of web application testing. Hung Nguyen's book is about those harder problems.

The web-based application runs on a wider range of platforms than any other type of program in history. It doesn't even have control over its presentation layer (the user supplies the browser and the multimedia plugins, and these applications might change any time). What will the application look like on the changed browser? The application probably also relies on third party databases (which can change any time), third party network connections (which can change any time), third party security systems and other access control (which can change any time), etc., etc. Almost anything in this system can change any time. How do you deal with a system that has so many unknowns?

Hung's view is that web application testers must learn more about the technical details of the systems and understand how external variables can interact (and fail) with the application under test.

To help testers learn about the interaction (and testing) of applications with other system components, he wrote the field's first book on grey box testing.

This book has substantial value for what it teaches us about testing on the web. Beyond that, it teaches about thinking clearly and thoroughly when your application interacts in complex ways with other systems. I think his approach will have lasting value and lasting influence long after many of the detailed issues that he describes have been resolved and replaced with new ones.

Along with the original approach, Hung gives a powerful real-world example. He is the president of a company that publishes a web-based bug tracking system. To illustrate the types of tests that you can run and the types of bugs you can find, he opened his records and described real tests, real bugs, and real testing problems. It's a rare treat to see a discussion of testing experience by someone who knows testing, who also intimately knows the software under test, and who isn't constrained in what he can say by a nondisclosure contract.

Professional BizTalk Server 2006 is one of those books which really goes over and above what you can find on online documentation . There are only few BizTalk books and thank god we have one like this . The books has a lot of hidden gems that will make you go 'aha '.

Absolute Must read if you love the Product. A great Chapter on Testing which I have not seen in any other BizTalk book .

Great book for all who want to know HOW BT really works and WHY it works like that. Very valuable purchase.

It took a long time for decent BizTalk Server books to start appearing, and those of us who have been committed to the product for some time know the pain (and fun) of having to work out, for ourselves, how this product works, how best to apply it to real-life scenarios and how to exploit its rich functionality.

I was really impressed with this book. It has two characteristics which I think are particularly noteworthy. The first is that it offers a huge breadth of coverage, but also manages to combine this with reasonable depth. This is hard to achieve when writing about BizTalk Server because it is such a rich an extensive product. The second characteristic is that it reads like a book written by practitioners - people with real-life experience of using the product, and the scars to prove it. Indeed, that it very much the case, and it means that the book provides far more than just rehashed information. It provides guidance, advice and best practice which is rooted in reality.

I like to think I know a thing or two about BizTalk Server (though it still manages to spring surprises on me quite regularly). I am not greatly addicted to computer books, because so many fail to be of any very practical use. However, I can report that this is the first BizTalk book (and one of very few books, generally) that I've carried with me into engagements to use as a reference. Warmly commended and highly recommended, especially for those who have done enough with BizTalk Server to realise the extent of the mountain they must climb.

I've been on a couple of BizTalk projects, all of them for Fortune 50 clients. We did a lot of things wrong, hence a lot of lessons learned. This book is good...REALLY good. How good? Well, let's just say that I never, repeat NEVER write book reviews, even if a book was the greatest thing since the bread slicer. (I guess because I'm too busy building Orchestrations and Custom Pipeline Components.) That alone should convince you that this book is a must-have for anyone wanting to know anything about BizTalk.

DISCLAIMER: Allow me to contradict that last statement... This isn't for everyone, however. It is really in-depth and explains more than the minimum required. The book also targets those of use that continue to ask the question "Why?" and it quenches our curious thirst. If I were to pick this book up when I was first learning BizTalk, I would throw it down and stomp on it. But now that I've been around the block a few times and I know the difference between a best practice and a "you're on your own" practice, I am able to get a lot from reading this material.

With BizTalk, there's so many ways to skin the proverbial cat. This books explains all of them (from what I've read), but then it points out the preferred approaches that one should take when implementing an integration solution via BizTalk Server...lots of Notes & Caveats sections, things that I crave.

This book will give you very objective insights into BizTalk. And you don't need to worry about reading it with your rose-colored glasses, either. It's neither half-empty nor half-full, it just is, you know?

This book has information in it that you simply will not find anywhere else. Its written by people who have worked with the product on some of the largest and most important projects where BizTalk has been the platform of choice, and the knowledge that thay pass on is exceptional.

Rex Black helps you think about how testing can help your projects. In particular, the planning chapters (using the running example project) make many of the planning and risk management issues obvious. This book will help you determine which activities make sense for you to perform, how to analyze quality risks, how to estimate the work, and how to speak the language of the business (return vs. cost). If you only read the first seven chapters, you'll be farther ahead in your thinking about testing and preparing your group to test than you ever were before.

The prepare chapters (8-11) help you determine which people to select for your team, and how to prepare your test infrastructure, considering that test managers always have limited budgets, people, or time.

A particularly valuable piece of the perform chapters (12-13) is the discussion of how to manage the test builds, who owns what -- how to remove confusion from "which build do I test now?" to an organized plan of handoffs.

And in the perfect chapters, if you've been looking for a way to teach how to write test reports, chapter 14 is your answer.

If you're a manager, you'll use this book on every project, even if you only review the checklists to see if you've missed anything. If you'd like to become a test manager, read this book. Rex describes numerous ways of managing the testing and working with your peers across the organization, to become successful.

I highly recommend this book, whether you're starting a project, in the middle of a project, or completing one.

Sometimes a book comes along that just has to become part of your virtual profesional toolbox. Mr. Black has just given us poor testers another such book.
For me this book provides me with all the tips and tricks that I need during a project and that I would have to think of myself instead of just picking up this book and reading about them.
Even better, I now have an excellent source of course materials for our test engineers. Mr. Black explains and justifies every aspect of the testing process just about perfect and his gift for the metaphor makes this book a good evening read.
The checklist approach that he employs is a great planning aid. Our projections are much more precise this method.
I have added this book to our technical library for this project, and I will insist on making it part of every future test project that I will be part of. That is until Mr. Back publishes his next book.

Rex Black's latest book, "Critical Testing Processes" belongs in every test engineering library. Rex's book is logically organized; Part I, Prepare, embraces Chapters 1 through 7. He begins with a discussion of Planning, the first phase in the testing lifecycle, focusing on Quality Risks to assist test planning, He provides one of the best step-by-step examples I've seen to develop a test estimate. Rex sets the stage for us by showing how testing fits into the larger project context, and defining a 15-step testing process. He defines the context of his case study on the Sumatra project. In this chapter, Rex shows one of the nicer examples of the classic "V-Model" relating the development and testing lifecycles.
In Chapter 2, Rex explores the subject of Analyzing Quality Risks as the basis for his test planning, and shows a variety of templates and techniques that will assist the reader in performing this process, and links them to his case study. Note that using Quality Risks may have to be coupled with requirements/feature coverage on contracts with a government customer.
I believe that Chapter 3 (Gaze into the Crystal Ball; Estimate the Work Ahead), is one of the most helpful guides to Test Estimating that I've seen. Rex provides a variety of templates to assist folks unfamiliar with building a testing estimate.
Chapter 4 shows how testing provides "value-add", and gives the reader insight into aligning the initial estimate with the financial constraints of the project. Rex discusses ways to reduce cost by focusing testing based on the Quality Risks, in the context of the Sumatra case study. Templates, spreadsheets, and methods for calculating testing cost and return on investment are supplied.
In Chapter 5 Rex shows how to take the realistic estimate that was created and sell it to the project team. He also has a section titled "Predict with Honesty", which emphasizes the necessity for Ethics in our business.
Chapter 6 discusses the significant efforts in continuous test planning, It uses a variety of excellent figures to illustrate the author's points; however, note that there are 2 Figure 6-5's in this chapter, which results in the remaining figures being mis-numbered.
Chapter 7 goes into detail on how to get stakeholder support for the Test Plan. The Test Plan is the keystone for successful testing. Rex also provides an interesting section on what to do "When Key Players Don't Support the Test Plan" and how to work in a regulated (e.g., export restrictions) environment.
Chapters 8 through 11 are the section titled "Prepare". Chapter 8 on hiring testers is another area of the book not dealt with in many texts, but is extremely critical to successful testing. There are several parallels here to the Perry/Rice book "Surviving the Top Ten Challenges of Software Testing".
In Chapter 9 Rex provides pointers to career growth in a testing team, and assessing skills of the team members. He gives some tips on creating job definitions. He also addresses the challenges posed by having to accept team members other managers don't want, and use of contractors and consultants. Good chapter!
Chapter 10 gets back into the more technical side of test management. Through his Sumatra case study, he provides some insights into stress testing, and use and support of test tools.
In Chapter 11 Rex discusses details of approaches to test coverage, test design, selection and implementation of automated tools. He also takes some time to discuss approaches to "vague requirements", which is a problem most of us face.
Chapters 12 and 13 are Part III, Perform. Rick provides an excellent discussion of management of test releases in Chapter 12. This discussion is nicely illustrated through the case study. Note that you need to have the ability and a mechanism to UNINSTALL any release.
In Chapter 13 Rex defines a test execution process, and then goes on to show how that process works. He defines a set of test tracking worksheets, and illustrates use of the process and the worksheets on "the Big Build".
Chapters 14 through 17 are Part IV. Rex defines the Bug Reporting process. He describes use of this process through application to "the Big Build". He goes on to show how to, and how NOT to, report bugs, and emphasizes the necessity of describing one symptom per bug report. One caution in this chapter; Rex uses shaded boxes to emphasize points. Several of these boxes were misplaced in the book assembly process, so the reader needs to use care in navigation on pages 391 through 394.
The title of Chapter 15 seems a little misleading to me, in that it doesn't deal with writing a Test Summary Report (IEEE definition), but rather with the critical, on-going process of reporting test metrics. Rex focuses on describing the creation of a "test dashboard", and use of that dashboard for providing a succinct delivery of test status. Rex describes what I believe are a useful set of metrics charts. Unfortunately, the book assembly process resulted in Figures 15-2 and 15.3 being reversed, which led to much confusion on my initial read.
In Chapter 16 Rex discusses change management as it applies to bug fixes. The Sumatra case study is used to provide an informative view into the change management process. Rex notes that such a process must balance considerations of features, schedule, budget, and quality by assessing impacts from all project groups.
Rex concludes his book with Chapter 17 with some thoughts as to how testing can provide value.
Rex finishes up with a Glossary that defines his terms.
A suggestion for the interested reader. Read Rex's book in concert with the book from Drabick titled "Best Practices for the Formal Software Testing Process: A Menu of Testing Tasks". Drabick's book shows the reader "What to Do"; Rex Black's book shows "How to implement the What".

This book is written for the test manager and/or project manager who oversees one or more testing efforts. The author has done a great job of taking his own personal experiences (good and bad) gleaned from years of "in the trenches" work, and threading them together into a single fictional story that he uses to illustrate his proven method of managing testing projects.
Part 1 (Chapters 1 to 7) talks about the stuff you need to do to Plan for a testing effort, such as; convincing senior management that spending money on testing is a good Return On Investment (ROI), how to get a realistic ballpark estimate for how long the testing is likely to take, and when & who should get involved in the project.
Part 2 (Chapters 8 to 11) deals with Preparing for test execution; selecting test strategies & techniques, putting a testing team together (and keeping them together), and determining the appropriate measure(s) of test coverage
Parts 3 & 4 (Chapters 12 to 17) first focuses on perhaps the most stressful phase of a testing project - test execution. When the "heat of battle" is most intense; it's useful to have examples, templates, and checklists that a test manager can draw upon to help them manage and report on the test execution in a controlled and credible manner. The book then wraps-up by discussing process improvement; what went well, and what could have been improved (no witch hunts please!).

In summary, I believe Rex has built a very comprehensive and detailed composite documentary on how he has defined and deployed the most critical processes needed to support a software testing effort.

In the vain of "full disclosure", you should know that I've known Rex for many years, and consequently I cannot be considered a completely impartial reviewer.

Critical Testing process is a book for the new test manager as well as a book for the test manager looking to refine what his or her process of testing is all about. What I liked about the book is it takes you through a fictitious company, Sumatra, whose is about to upgrade and introduce a new enhancement to their software. It is a dialog between the test managers, testers, program management, and VPs of the company. It's like reading a story with a narrator in the background commenting on what is going on. But then breaks off from the scenes talks about what was going on, and the reasons why these things had to happen that way.

As the first chapter starts out - getting the big picture. The biggest thing I have found with Test managers who are struggling in their field is not getting their test group involved - involved I mean from start - at the requirements and implementation phase, versus toward the end, where its almost too late.

The next few chapters go through is estimation and planning, as what we (test managers / test leaders) should all do is go through and then analyze the risks, come up with some estimation of time, and cost of the project. Then the ultimate, sell it too management where the project is most likely already over budgeted. Finally the sell tactic - to gain support for the test effort.

Assuming you have made it through all that planning, the next chapters talk about hiring and putting together a good test team and implementing the test cycle for what amounts to what you will be testing.

The next few chapter talk about the testing, everything from the release criteria handoff to executing test cases, reporting on the progress of testing, leveraging the opportunities and hitting some of the pitfalls. Ending with a summary of what the book was about, and putting it all together.

Some of the books I have read, I walk away with, how can I apply this book to what I am doing. This is a book where it is like a reference guide, where I can look up and gain a possible solution quickly as to how address my everyday scenarios in my test department. Or, as I have done already through ww.stickyminds.com web site, is recommend it to those new test managers who are trying to quickly get a department going, but want to do it correctly.

Testing has often been the misbegotten portion of the software development process. Frequently neglected until the semi-chaotic end of the production cycle, the testing phase has traditionally been shortened to accommodate a fixed release date. The relationships between the developer and test groups are to some extent adversarial, but in so many cases it often breaks down into open hostility. Among developers, it is often considered demeaning to have to soil ones hands by actually testing the code. With such a sullied background, it is no wonder that production code is generally riddled with bugs.
As the authors of this book point out, all of the above are dangerous conditions. With the expansion of code reuse and RAD tools, the development of the initial iteration is going to be done at a faster pace than before. Since the number of pathways through the code is operationally infinite, the only way relatively bug-free code will be developed is by allocating more resources to testing and making the choice and tracking of test cases a more scientific endeavor. The most significant point of the ten made in this book is that the testing process should be considered on an equal basis with that of development so that both groups communicate as equals. Without that, all the fancy, efficient tools in the world are reduced to the level of mere toys.
This is a book that can and should be read by developers, managers and yes, even testers, as all will benefit from the simple words of wisdom.

This book gives excellent insight for the beginning QA professional. It not so detailed that developers and managers will not want anything to do with it either. It explains ways to communicate quality assurance without offending anyone. The content is concentrated on the expressing QA in a brighter light without ruffling too many feathers. I recommend it for everyone in a technical environment with the goal of attaining quality. THIS IS A MUST HAVE FOR ANY QA PROFESSIONAL.

Much has changed in software development and testing practices since this text was written in the late 90's. However, many of the identified challenges are still with us. I find myself rereading this book as it is a useful reference for a test manager. The authors identify dual disparate roles for the software tester. In role one, the focus is on the task of testing software, such as test planning, test design, and execution. In role two, the tester or test manager's role is more as a politician and marketer to protect the test staff and promote the value they bring to each project . The text focuses on the second role, which elaborates on what the authors identify as the top ten people oriented challenges for the software test professional.

The first section of the book includes an assessment to help you identify your strengths and weaknesses in meeting people related testing challenges. The bulk of the text contains individual chapters on the top 10 challenges. The challenges are explained along with guidelines to overcome the challenge. Chapters can be read out of order and this format allows you to focus on your weaknesses as identified in the self assessment. The last section of the book describes a six step change process to implement improvements. My favorite two chapters were "Explaining Testing to Managers" and "Getting Trained in Testing." Highly recommended.

This is an excellent review of the biggest recurring problems of the software testing world. As I read the descriptions of each of the 10 challenges, I was astonished at how many of the pitfalls I fall into on a regular basis. Perry & Rice don't just lay out what the challenges are - they also discuss how to meet each one. Each item on the list has its own chapter with sections on the impact on testing, solutions to the challenge, impediments to implementing the solutions, and helpful guidelines to creating a plan of action. This is without a doubt an excellent book for those of us in the trenches of software testing each day. (One bit of advice, though - if you're looking for a book on "how to do software testing", look elsewhere. Perry and Rice have other good books on the subject, but this one is really intended to help you step back from your daily testing work and see where you could improve on your approach to it.)

When this book was written software testing was starting to consolidate into an 'honorable' profession, and the number of good books about testing could be counted on your fingers (and probably a few toes). The discipline has matured into a profession, and there are so many excellent books on the subject now that it boggles my mind.

You'd think that the top ten challenges listed in this book would have been long ago resolved and replaced with a new set. Sadly, that isn't the case. Each challenge listed is as valid today as it was when this book was written, and except for #10 on the list (getting trained in testing), which has dramatically improved, the other nine are still there. Read the book. Take the advice of the two authors, both of whom are seasoned professionals who give the solutions to these challenges, and move the profession forward.

Here are the top five challenges that I see today, drawn from the list in the book:

#1 today, #6 in the book: Communicating with Customers -- And Users
#2 today, #3 in the book: Hitting a Moving Target
#3 today, #1 in the book: Having to Say No
#4 today, #4 in the book: Testing What's Thrown Over the Wall
#5 today, #2 in the book: Fighting a Lose-Lose Situation

Your order may be different, but I am willing to bet that the list will be the same. This book does give realistic solutions to these problems, so if you agree with the list, then you'll find this book valuable.

I purchased this book based on Amazon's information and the reviews. My purposes in doing so are different than most who would / should consider it -- to audit and assist US FDA-regulated companines in compliance, including the requirement for validating software in medical devices, or in manufacturing and data systems used to manufacture FDA-regulated products (devices and drugs). Given that caveat, Rodger's book is an excellent resource. He supplements his narrative with numerous diagrams which he defines as describing a process and a "set of tasks that can be used to implement or improve a formal testing program".

His stated assumptions (a pre-existing formal system in place at a company; specifically defined by the Capability Maturity Model / CMM 3-4+; with a separate reporting structure -- or, as he stated, "the full blown model described in this book details a full-featured formal testing process that is applicable to large programs and that would fully support programs deliverable to state and federal governments, or on programs delivering safety-critical systems or having significant impact on corporate profits" ). What he describes would fit well with the FDA's GMPs(Good Manufacturing Practices), a quality system similar to but more stringent than ISO 9001 / 13485, and various FDA /Agency guidance documents on software validation (a series of structured documentation and testing requirements).

Although presented for / geared to a large corporation w/ greater resources, I would argue that the basic principles he discusses, and the systems approaches recommended, are adaptable, and 'down-scaleable' to any size company. It also provides a model / target to aim for by any software developer / provider, including (especially) the small shop, a requirement trend that will probably only increase, and globally -- and providing such companies a competitive advantage, and enhance the Intellectual Property (IP) value of the resulting product. His strategic level and test level discussions also provide the basis for input to software portions of a company's documentation -- the Quality Manual, SOPs (standard operating procedures), and WIs (work instructions) for both engineering and testing / QA.

Certainly, the recommendations, systems, documentation and efforts outlined in this book, if followed in principle, would greatly reduce the problems experienced in software / hardware implementation projects, including some recent failures / delays receiving nationwide publicity.

As such, it has proven to be a valuable addition to my consulting library, and a useful reference in conducting audits, making recommendations, and developing validation protocols.

Testing large software projects is a very difficult task. Testing can only reveal the presence of bugs, not their absence and it is impossible to cover all possible pathways that the software can traverse. Furthermore, and what is the worst, "simple" changes made in software can cascade across many modules, requiring the re-testing of all affected modules. Therefore, any testing plan must incorporate repeating tests based on feedback. Finally, testing is something that must be done, so there is no choice in the matter.
The practices described in this book are all modeled using Input-Process-Output (IPO) diagrams, which are labeled state diagrams. The states in the diagrams are partitioned into three sections, input, process and output. Inputs are represented as labeled arrows, which can originate from another state, but do not have to. The process section describes what is to be done at that stage and the output section has labeled arrows exiting the state that then go to the next state. Multiple inputs and outputs are possible and the flow can loop back to a previous state.
Each state is described in the text, where the inputs for the state are explained in detail. Applicable feedback from all persons with a stake in the operation is discussed as well as feedback that this state can give to previous states. The process is described and then the outputs that the state will send to later states are explained. Feedback that may be received from states later in the sequence is then described.
What is most impressive about these modeling diagrams is the extensive allowance for feedback. The complexity of the testing process and the consequences of the results means that testing can form a feedback loop that exhibits many of the characteristics of chaos. A loop is chaotic when small changes can cascade into very big changes. The way to prevent this in any process carried out by humans is to incorporate damping mechanisms. These features reduce the impact of any result so that they do not grow beyond the bounds of the system to handle them.
When faced with impossible tasks, something that software testing has now become, the best that you can do is examine a subset composed of the most likely scenarios. By applying the models in this book, it is possible to raise the level of your testing quality to the point where you can be confident in your software

Rodger Drabick has written a comprehensive and practical guide to formal software testing process. Everyone involved in software testing will benefit from his years of experience and his revealing insights. I've been in the testing field for more than 10 years, and I'm learning a lot from this book! This is a great textbook for new testers, a step-by-step cookbook for new managers, and a great reference book for everyone in the testing world. Rodger takes what can be a difficult and elusive process and explains it thoroughly, using graphic models as well as real-life examples. The best part is that he explains how to adapt the testing process in various situations, even Extreme Programming projects. He gives specific advice to testers at every level, most valuably for new testers and new test managers. Just a few of the things you can learn from this book: How to apply IEEE standards to your project, how to break a project into testing tasks, how a process model can be used as a training tool for new test engineers, how to apply the model to achieve a specific CMM level. Rodger's aim is to help the reader improve the testing process, thus improving product quality. He emphasizes that the testing and development organizations must work together throughout the software development life cycle - not a new idea, but not done nearly enough either. Don't be thrown by the technical-looking IPO diagrams and formal terminology - this is a common-sense approach that can be applied just about anywhere. Rodger doesn't expect you to run out and implement this entire model - he just wants to help you improve on what you do. What if your a tester who gets code to test but no requirements? Pretest and posttest meetings wouldn't be hard to implement, and they'd improve your process. This is the type of advice that makes this book golden. The appendices add even more value, with info on CMM, preferred practices, a way to evaluate your current practices, and a primer on test execution. The book's references to other works will let you explore other areas of testing.

Rodger Drabick has written a useful book for those working on test efforts in formal environments. By "formal environment" I mean a CMM level 3 or above, SPICE, or ISO registered program, or one regulated by a government agency like the Federal Aviation Administration or the Food and Drug Administration in the US. There have been plenty of templates and standards floating around for years on what to write down for such tests, but precious little describing how to manage the formal testing process. This book fills that void.

The book has the following strengths:

1. Rodger provides a clear, complete roadmap for those new to testing in a formal environment. You could follow this roadmap, with the tailoring advice he provides, and do a competent job your first time working on such a project.

2. Rodger manages to cover a dry topic like formal processes in an engaging fashion. He includes useful "stories from the trenches" and lessons learned from his experiences, which bring the topic to life.

3. Rodger transcends and complements the IEEE 829 test documentation standard by harnessing a formal process model to the templates. Rick Craig's book, *Systematic Software Testing*, does this, too. However, Rodger's book is a good complement to Rick's in a more formal environment.

4. Finally, Rodger's book is browseable. You can skim sections, get the gist, and return later for a more detailed read.

The book has a few minor weaknesses, which I should mention:

1. The bibliography is a bit thin. The body of useful and interesting test knowledge extends well beyond what's shown there.

2. Rodger is careful to note that the processes he describes are for formal environments. So, the brief section on Extreme Programming struck me as somewhat of a non-sequitor. However, readers will probably simply skip this section if they aren't using XP or other agile approaches. If readers are using XP or some other agile approach, I'd recommend a different book on the testing process first.

In the domain and user community Rodger is addressing with this book, neither concern should dissuade someone from buying the book.

Anyone testing in a formal environment will likely benefit from Rodger's book. If you are testing in a formal environment for the first time, reading Rodger's book might well go from a good idea to a survival requirement. Formal environments are the world Rodger has worked in for decades, and no one else has brought his wealth of experience in that world into writing a book about the testing process.

First, this book is not primarily for software test and QA professionals who are working in 'typical' organizations. As noted by others, the approach this book provides is best suited to organizations that are at least at CMM level 3. Moreover, unless software engineering practices across the organization are mature the approach will probably fail. However, that does not prevent even a Level 1 organization from selecting best practices and tasks set forth in this book and applying them. The net result will be an incremental improvement, and may be the catalyst for larger improvements with a small win.

That said, this book is invaluable to mature organizations that are committed to software engineering at the defined, managed or optimizing levels of maturity. It distills formal test practices drawn from a variety of sources and the author's experience into a succinct, process-oriented guide. The model itself is presented in IPO (Input-Process-Output) diagrams that start at a high level to describe the process itself, and drill down into successive levels of detail in level 2 and 3 IPO diagrams. This process-oriented structure gives a great deal of clarity to a complex set of processes that touch all milestones in any SDLC.

I like the fact that the model proposed is not rigid, but can be tailored to development life cycle approaches ranging from waterfall to agile approaches. Chapter 8 gives advice on how to accomplish the tailoring without breaking the integrity of the process. I also found the appendices useful, especially Appendix B (preferred practices) and the plans and templates provided, and Appendix C (testing processes evaluation questionnaire).

If your organization is pursuing CMM level 3 or above, or are contractually required to have a formal software engineering process or process capability, this book will address the software testing process areas of a larger initiative. However, do not overlook some of the small wins a chaotic organization can achieve by using many of the ideas in this book.

In the last decade, the performance of J2EE applications has become of monumental importance in enterprise industries that use these applications. With the complexity of J2EE applications increasing every year, it is crucial that users of these applications be presented with a level of performance that is acceptable to them, this performance usually codified in the ubiquitous "response time." The authors of this book have given a good introduction of how to deal with performance issues in WebLogic applications and have discussed a freely available tool, called Grinder, which allows load-generating and data collection. The book though can be read with respect to any load-generating tool, such as Mercury LoadRunner, etc. Even though Grinder is free, it may take time for enterprise users to trust it in testing and modeling.

After a brief introduction to what the book is all about, the authors begin in chapter 1 with discussion on a testing methodology for doing performance studies of J2EE applications, which they hope will be generic enough for all readers. Their methodology boils down to first defining the performance metrics for the application, and then setting a target for the metrics. Test scripts that accurately simulate the application usage must then be obtained, and the statistical sampling method and metrics must then be defined. The authors emphasize the need for a realistic `usage profile' for the application, and they recommend strongly a fixed number of users per test run, with subsequent runs changing the number of users. They do not give quantitative reasons for not varying the number of users, but merely say that such an approach is "statistically incorrect."

They also point out the need for including "think times" between the executions of each request in a script, asserting that the think times will have a very dramatic effect on the observed response times and throughput for a given user load. They are correct in this claim, as testing and modeling studies will show, and they give examples of this in chapter 4 of the book. In addition, they remark that the attempt to simulate more users by decreasing the think time, with the assumption that the resulting data can be then extrapolated to obtain the performance at real think times. They point out, correctly, that applications do not scale linearly over different time scales, and that the application and Web servers, the database server, and the operating system do not interact the same way with different user loads. Performance testers and modelers have verified them time and time again, and so it is beneficial for a reader who might be new to the field to see the case studies illustrating this included in the book.

The authors discuss two sampling methods in the book, namely the `cycle' method, and the `snapshot' method. Defining a cycle as a complete execution of a test script by a simulated user, each user will thus execute every request in the script once. Increasing the number of cycles will result in more meaningful statistics, but the time to run a large number of cycles might be too prohibitive. The snapshot method involves capturing the data for a specified period of time.

It is rare to see in books at this level a statement that acknowledges the difficulty in the mathematical or simulation modeling of Internet traffic. The authors though are cognizant of this difficulty, and give some brief suggestions on how to simulate the Internet in a test environment.

The authors also devote a fair amount of time discussing how to assess the accuracy of the test results. The authors report that variability of up to 50% on the performance testing of applications has been observed, and so they propose a measurement of "quality" for the sample data. This is defined as the standard deviation divided by the arithmetic mean, and when close to zero indicates high quality in the sample data. A value above 0.25 for the quality they take as a sign that the tests are not reproducible, and they therefore encourage the running of more cycles of the test in order to pin down the origins of this non-reproducibility. They define a "load factor" to better quantify this, which they define in terms of an "aggregate" average response time. Plotting this quantity versus the number of cycles gives some information on a bad quality indicator.

Frequently, application development using J2EE requires that the impact of design changes or proposals on application performance must be understood. The authors address how performance can be impacted in the context of building servlet applications. The dynamic nature of servlet applications entails that special measures be taken to maximize the performance of the application. The authors discuss how to choose a session mechanism that will preserve the session in user requests, and how to manage the servlet thread pool. Other helpful hints are given on how to increase performance, such as making sure that the auto-reload feature of servlets is disabled in a production environment. In testing the servlet API, the authors choose the snapshot method of data collection, and used zero think times as a baseline, since the real think times are unknown. They use WebLogic Server 6.1 in this discussion however, which makes their presentation somewhat dated, since WebLogic is now in version 8.1. The authors also test the performance when the WebLogic performance pack is activated, for both the average response time and the transactional rate. Also studied is the cost of maintaining HTTP logs, an issue that is very important for those businesses who must keep these logs, either for advertising purposes or other reasons. By running tests, the authors conclude, as expected for those readers who have managed Web servers, that the keeping of log files can have a considerable impact on performance, for a high number of users. The effects of the size of the response generated by the test servlet is also studied, along with the effects of using HTTP 1.0 versus HTTP 1.1.

This is the best book yet about J2EE performance tuning. I hope 'Expert Press' (which looks like a Wrox imprint) continues as they have started.

The authors lay out a practical method for performance tuning of Web Applications and EJB's on BEA Weblogic, but there is no reason why the approach (and the 'Grinder' tool) cannot be used to evaluate different approaches on any other Web and Application server.

Note that this is a specialized book. It will not teach you how to do Java or EJBs. What it will do is help you evaluate how to deploy them in the real world to get the performance you need, and also to help you evaluate different approaches.

I was looking for a book to help me understand how regular performance testing is performed so that I could construct a plan to do Denial of Service security testing. I knew nothing about performance testing at all. The books really well laid out, structured, has great examples and is really methodical. It was perfect !

It was a great book! Had lots of information about Performance Testing. When coupled with the power of Panorama(TM) by Altaworks.com, it is incredible.

Thanks for making such a good book avaliable. I think the chapter on testing EJB design patterns is very well written. I would recommend this book as it is one of the best I've gotten my hands on.

serious system testing has never been part of the culture here. One day the manager decided that it would be a good thing if we did proper, coordinated, effective stress and load testing. I got stuck with coming up with strategy. I started reading this book expecting a how to guide. I expected to be spoon fed all the nittt gritty details on how to do it. This is not what I got.

This book points you in the right direction, show you the tools you could use, explains what you need to think about and the questions you need to ask. The how-to and the answers to the questions are more for you to figure out yourslef.

At the end of it you come away with a better understanding of what you need to do, why you need to do, high level how you are going to do it and the value you and your company are going to gain by doing all of this.

I would strongly recommend it to anyone having to get involved in system analysis and performance. It gives you a great broader picture of the whole issue. You think you know what you have got yourself involved in. this book shows you that you appreciate only the tip of the iceberg.

This is an excellent book which can be used for perfomance tuning and stress testing phase of big projects

Written by an authority on the subject. This book is a treasure trove of information that is detailed and essential for covering all aspects of a properly executed stress test. Written from experience, this book is a definite "MUST" read for anyone assigned the challenging task.

This book features good discussion on performance tuning the mySAP suite that no other books have so far. This is the perfect book for SAP Stress Test Project Managers, SAP Stress Test Project Teams, SAP Basis Administrators, Oracle DBAs, Unix Administrators managing SAP systems, and project implementation teams. Those who stress test their systems well with the help of this book will have significant returns.

The ultimate reference for performance testing (certainly testing, more so than actual tuning, though the latter is covered well in the last few chapters). The author's approach is complete in that it addresses how to test along with what, when, to what degree, and with what kind of staffing resources. I'm already thinking of ways we can improve our own change control processes, and based on tools and methods covered by the author I'm convinced I can do so cheaper and with less impact to my users than I previously thought possible. Case in point, look into the two chapters on tools for testing and monitoring: in this alone, the book will pay for itself in short order.