Most Helpful Customer Reviews
30 of 32 people found the following review helpful:
5.0 out of 5 stars
Excellent reference guide for testers., January 13, 2003
This review is from: Effective Software Testing: 50 Specific Ways to Improve Your Testing (Paperback)
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.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
15 of 15 people found the following review helpful:
4.0 out of 5 stars
Use in conjunction with books on unit testing, May 15, 2003
This review is from: Effective Software Testing: 50 Specific Ways to Improve Your Testing (Paperback)
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.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
9 of 10 people found the following review helpful:
5.0 out of 5 stars
Excellent advice with a wider audience than QA, February 29, 2004
This review is from: Effective Software Testing: 50 Specific Ways to Improve Your Testing (Paperback)
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.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
|
