<< 1 >>
Rating: 
Summary: Excellent reference guide for testers.
Review: A rarity in the testing world, here is a book I can wholeheartedly recommend for your average test practitioner or the QA Manager or QA Lead who feels they might be in over their head or who is not sure if they are missing something in their overall test effort. Having worked in the field of quality assurance and testing for more than ten years, I can say that the author hits on many elements that I often see not practiced in various organizations and that should be. The "Item"-focused nature of the chapters (providing the fifty steps) are a great way to present this material and bring in mind, to this reader, Steve McConnell's "Rapid Development", which did the same thing for development-related concerns. I had always wondered why the testing field did not have a book like that and now it does.If I had to pick one nitpick (and in the grand scheme of things it is probably a relatively small one), one thing I could probably do without was the use of the word "nonfunctional testing". That is, unfortunately, a term all too often used in the discipline of testing and it should not be. For example, performance testing in the book is placed under the "nonfunctional" category and yet it is all about functionality: how quickly the functionality performs! The same thing with security: this is about how secure the application/site functions! (In other words, how secure the functionality is.) So this term is, I feel, incorrectly applied and as such will be used by more and more testers and this is often the stumbling block because usage of the term "non-functional" really often covers up what are, in effect, quality requirements and cost constraints. With that said, however, the material under the section on non-functional testing is well laid-out and is accurate in every respect, as far as I was concerned. The breakdown of the book in terms of chapters and then items within the chapters is right on the money. And some of the items are wonderful kernels of knowledge that all testers should keep in mind. For example, Item 17 is "Verify that the System Supports Testability". This is a key concept that way too many testers seem to forget about early on and then have to deal with the ramifications of explaining why they cannot adequately test something later on. Yet another excellent element is Item 22, "Derive Effective Test Cases from Requirements". My immediate thought is: okay, but what if there are no requirements? Well, the author covers that very point in an excellent manner. In fact that is what all the items do: they provide a solid reference point for a variety of topics that can be researched by the conscientious tester or analyst. This book is a distillation of a broad array of concepts, from requirements analysis to automated testing tools to evaluating how effective a tester is. This wide scope will, I think, give the book a broad appeal and it serves to make it clear that there is quite a bit going on in the world of testing. Overall, I think this is an excellent reference book for the average test group within an organization and is certainly worth having in your library if you in any way deal with the world of quality assurance or quality testing. It is rare that I give any book five stars (much less a testing book) but this one deserves it. Will you be an effective tester with this book? That all depends on how you apply what it talks about. But I can almost guarantee you will be an ineffective tester if you do not take much of what this book has to say seriously. Highly recommended.
Rating:
Summary: Excellent Testing Guide
Review: As an experienced test manager, I find this book to be an excellent guide that can be used as a checklist while conducting test planning.
The table of contents of this book takes the reader through the entire software test planning effort, allowing me to double-check that I didn't miss anything.
This book discusses such important topics as "automated unit testing," "developing unit tests before implementation, popularized by extreme programming," "how to gain understanding of the system architecture," "the importance of gray box testing and logging techniques," and provides other excellent test planning ideas.
I highly recommend this book to any test professional.
Rating:
Summary: A deft, concentrated treatment.
Review: I proof-read this book and it was so good I felt compelled to read it a second time! I have read several of Elfriede's books and I always find them well organized and consistently readable. Elfriede is a well known authority in this field and in Effective Software Testing she has produced a state of the art handbook for a comprehensive testing effort. The format is very pragmatic. The book is split into different areas in a useful sequence and each area has an overview with seperate following chapters providing more detail. The chapters are concise and the subject area's contents are concentrated and free of jargon. We have implemented many of these precepts in our organization to very good effect. Highly reommended!
Rating:
Summary: A deft, concentrated treatment.
Review: I proof-read this book and it was so good I felt compelled to read it a second time! I have read several of Elfriede's books and I always find them well organized and consistently readable. Elfriede is a well known authority in this field and in Effective Software Testing she has produced a state of the art handbook for a comprehensive testing effort. The format is very pragmatic. The book is split into different areas in a useful sequence and each area has an overview with seperate following chapters providing more detail. The chapters are concise and the subject area's contents are concentrated and free of jargon. We have implemented many of these precepts in our organization to very good effect. Highly reommended!
Rating:
Summary: A nice addition
Review: I wasn't sure what to expect from this author's third book covering the topic of testing, but yet again the author has produced a very useful addition.
In my opinion, this book serves as a complementary guide to the author's other books, which are already part of my testing library.
This book is a highly informative summary of important factors to consider during the testing planning and execution phases.
Reviewing and considering each of the 50 steps described in the book is a must and allows the test manager or lead to design a blueprint for the testing effort. All suggestions described in the book should be considered, when conducting test planning and test execution, to make sure nothing has been missed.
Rating: 
Summary: Use in conjunction with books on unit testing
Review: My review of this book is based on my having recently read several others about software testing. In particular, "Test-Driven Development: By Example" by Kent Beck, where the basic premise is that the tests are written either before or simultaneously with the code. I have long believed that this approach is the best way to create quality code and I am skeptical about any other testing approach. The plans in this book can be considered as a broad overview of the testing strategy rather than down into the specifics of how to write tests for specific blocks of code.
Many of the examples are in the realm of the obvious, but not always clearly implemented. For example, number 17 is "Verify that the system supports testability" and number 31is "Know the different types of testing-support tools." In the case of 17, the word system is being used to describe large projects and the topic deals with verifying that it is possible to test the integrated system by tracking the source of errors and how the components interact with each other. Tracking down errors that arise when systems are integrated is very hard, and in general it is necessary to make the plans on how to track down such errors when the architecture for the system is being designed. Therefore, the point, which seems obvious, is in fact a very critical one.
Determining what software testing tools are available is another very critical step in the effective, efficient testing of software. The enormous number of different pathways through modern software makes it impossible to use even the largest army of testers to check them all. Therefore, the only way to provide reasonable coverage of the options is to let other software examine it. Tools such as memory and other system resource checkers, source code scanners that look for "obvious" bugs, programs that generate test data sets either randomly or clustered about most likely values, and test generators can sometimes provide valuable assistance in cleaning code. When working in C/C++, I found a code scanner to be extremely helpful, and wrote a simple one some time ago. It searched for instances of a single "=" in Boolean expressions, semicolons immediately after if, while and for loops, and places where the delete command was used on pointers that might point to an array. It was simple, but it did find some bugs that quite likely would have taken me hours to find.
The testing principles are organized into ten categories: * Requirements phase.
* Test planning.
* The testing team.
* The system architecture.
* Test design and documentation.
* Unit testing.
* Automated testing tools.
* Automated testing: Selected best practices.
* Nonfunctional testing.
* Managing test execution. As you can see, the concept of testing is included from the very first stages of the project. This is essential, as it is very possible to incorporate something into the design that will make effective testing difficult or even impossible. Experienced software testers should be included in the planning from the first day of construction.
I consider this book to be a companion volume to those that emphasis testing as part of coding. With this book and one of the others, you can raise the level of your software quality quotient, which makes the life of everyone much easier.
Rating:
Summary: Excellent advice with a wider audience than QA
Review: Think of this book as a 300 page checklist that uncovers gaps in the testing process, some glaring and some more subtle. From that perspective you are not getting yet another book on how to test software, but insights into the author's extensive experience and knowledge. Therein lies the value of this book, and why it is applicable to not only software QA professionals at all experience levels, but to project managements, application support professionals, and developers. The book is divided into chapters that address a specific phase in the testing process, starting with requirements through to text execution. I won't dwell on the content that will be of particular interest to QA practitioners because the entire book applies. Instead, I'll cite the information that other stakeholders in application delivery will find useful because I believe this book has a much wider audience than just QA: - Chapter I (Requirements) should be read by project managers and the requirements team. It underscores the importance of integrating the QA team at the earliest stage of a project. - Chapter IV (System Architecture) shows the importance of communications between the architects and design team and the QA team. Specifically, if QA isn't working closely with architecture, designs may not be testable, which will impose significant costs downstream in the applications delivery process. - Chapter VI (Unit Testing) gives advice on how to effectively engage the development team in the overall quality strategy. - Chapter X (Managing Test Execution) has excellent advice on managing defects, which has a plethora of stakeholders and roles, from support, business and development domains. In addition, the guidance on bounding the test execution cycle is not of primary interest to project managers, but also to business stakeholders. It's a sad commentary on the way some organizations manage the test environment when advice for separating the test and development environments need to be included, but this commingling happens too often and I was happy to see it included in this chapter. This is not a 'how to test' book, it is a compilation of pitfalls and how to avoid them. It is a welcome addition to the growing software quality body of knowledge and one that I recommend highly.
Rating:
Summary: Excellent advice with a wider audience than QA
Review: Think of this book as a 300 page checklist that uncovers gaps in the testing process, some glaring and some more subtle. From that perspective you are not getting yet another book on how to test software, but insights into the author's extensive experience and knowledge. Therein lies the value of this book, and why it is applicable to not only software QA professionals at all experience levels, but to project managements, application support professionals, and developers. The book is divided into chapters that address a specific phase in the testing process, starting with requirements through to text execution. I won't dwell on the content that will be of particular interest to QA practitioners because the entire book applies. Instead, I'll cite the information that other stakeholders in application delivery will find useful because I believe this book has a much wider audience than just QA: - Chapter I (Requirements) should be read by project managers and the requirements team. It underscores the importance of integrating the QA team at the earliest stage of a project. - Chapter IV (System Architecture) shows the importance of communications between the architects and design team and the QA team. Specifically, if QA isn't working closely with architecture, designs may not be testable, which will impose significant costs downstream in the applications delivery process. - Chapter VI (Unit Testing) gives advice on how to effectively engage the development team in the overall quality strategy. - Chapter X (Managing Test Execution) has excellent advice on managing defects, which has a plethora of stakeholders and roles, from support, business and development domains. In addition, the guidance on bounding the test execution cycle is not of primary interest to project managers, but also to business stakeholders. It's a sad commentary on the way some organizations manage the test environment when advice for separating the test and development environments need to be included, but this commingling happens too often and I was happy to see it included in this chapter. This is not a 'how to test' book, it is a compilation of pitfalls and how to avoid them. It is a welcome addition to the growing software quality body of knowledge and one that I recommend highly.
Rating:
Summary: Outstanding testing techniques.
Review: This book contains a cornucopia of excellent experience based testing practices. This book is very informative for neophyte testers, mid-level testers, qa managers, and organizations struggling with preliminary testing tasks, specifically the most important areas of initial testing to focus on such as test planning, creating test cases, unit testing, etc. The author excels in providing techniques to the readers that will help the readers "build an application with quality as opposed to testing for quality". The author addresses all important techniques and topics related to the testing effort that parallels all conventional phases of software development.I particularly enjoyed the author's pellucid writing style, organization of materials and experience based insights into the world of testing. I found that even as an experienced tester with several years of experience leading software testing efforts at several fortune 500 companies I was able to learn a great deal from this book. Happy readings!
Rating: 
Summary: Read This Book Only in Addition to Others
Review: This book should not be read in isolation, especially by a new/newly ordained test engineer or test manager. It suggests approaches to testing that are in conflict with the Testing Life Cycle as contained in IEEE Standard 829, the Standard for Software Test Documentation. A reader would do well to first read "Systematic Software Testing" by Rick Craig and Stefan Jaskiel. Ms. Dustin seems to concentrate on developing Test Procedures and plays down the critical subject of Test Design. Also, though not labeled as such, much of this book seems aimed at testing in the web environment, as opposed to testing non-web systems (e.g., client-server, mainframe) or safety critical systems. This book offers several excellent points, such as Early Test Planning and discussion of the Test Environment, but tends to use terminology (e.g., test harness) that is used differently elsewhere in the software industry. Since the book doesn't contain a glossary, this can lead to reader confusion. The author's section on Test Automation is well-done, which one would expect from an industry-recognized test automation expert. There seem to be several misleading items in this book, including the author's definition of "Black Box" testing. Elsewhere in the software industry, this means "Requirements-Based" testing, but the author defines it as "Validating correct behavior only by viewing the output of the user interface." This seems to be significantly restrictive in scope. The author also seems to concentrate on the requirements-verification-testing aspect of unit testing, while playing down the structural, white-box aspect of unit testing.
<< 1 >>
| 
