More About Software Requirements: Thorny Issues and Practical Advice
by Karl E. Wiegers
Website Optimization
by Andrew B. King
Test Driven Development: By Example
by Kent Beck
Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests
by Jeffrey Rubin; Dana Chisnell; Jared Spool
How We Test Software at Microsoft®
by Alan Page; Ken Johnston; Bj Rollison
A Practical Guide to Testing Object-Oriented Software focuses on the real-world issues that arise in planning and implementing effective testing for object-oriented and component-based software development. It shows how testing object-oriented software differs from testing procedural software and highlights the unique challenges and opportunities inherent in object-oriented software testing.
The authors reveal how object-oriented software development allows testing to be integrated into each stage of the process--from defining requirements to system integration--resulting in a smoother development process and a higher end quality. As they follow this process, they describe what to test at each stage as well as offer experienced-based testing techniques.
You will find information on such important topics as:
Testing analysis and design models, including selecting test cases to guide design inspections
Testing components, frameworks, and product lines
The testing challenges of inheritance and polymorphism
How to devise an effective testing strategy
Testing classes, including constructing a test driver and test suites
Testing object interactions, covering sampling test cases, off-the-shelf components, protocol testing, and test patterns
Testing class hierarchies, featuring subclass test requirements
Testing distributed objects, including threads, life cycle testing, and Web server testing
Testing systems, with information on stress, life cycle, and performance testing
One comprehensive example runs throughout the book to demonstrate testing techniques for each stage of development. In addition, the book highlights important questions that testers should ask when faced with specific testing tasks.
The authors acknowledge that testing is often viewed as a necessary evil, and that resources allocated to testing are often limited. With that in mind, they present a valuable repertoire of testing techniques from which you can choose those that fit your budget, schedule, and needs.
0201325640B04062001
Average Amazon.com® Rating: ![]()
![]()
![]()
![]()
Based on 5 Ratings
Thorough, wide and deep coverage of O-O testing - 2001-04-20
Reviewer Rating: ![]()
![]()
![]()
![]()
![]()
I purchased this book to use as a guide for developing a strategy to validate directory-enabled security infrastructures. It met my requirements and more. I discovered that this is also a great introduction to object-orientation for test professionals new to the paradigm. Also, because this book covers every facet of O-O testing it is also useful to testers who have worked in the O-O environment.
It starts out with a good description of the differences and unique challenges of testing O-O software. It then covers the basics. Starting with test planning it provides a clear approach to performing this important task in the O-O environment. This material can also be used as best practices for testing in any environment. I especially liked the chapter on testing analysis and design models. In particular, this chapter validated my personal theories on the way to approach design validation of directory services, such as LDAP, that are becoming a prevalent component of enterprise security infrastructures. The next three chapters address testing classes, interactions and class hierarchies. These chapters cover the foundation of O-O testing and provide those who are new to O-O testing with a clear view of what's important and how to approach developing a test strategy and cases, and performing the actual testing.
The book moves into advanced topics in the chapter on testing distributed objects. This is a complex subject and developing a test strategy in this area is a daunting task. The authors cover this material in depth, and provide a clear and complete description of all issues and factors. I was impressed with thoroughness and attention paid to the most minute detail. The authors include life cycle testing, which makes this book also important to software quality assurance (SQA) professionals. Note, SQA and testers are two different groups with two different sets of objectives. Where the tester is concerned with trying to break software, SQA collects metrics and devises process improvement with respect to defect prevention. The authors' approach contains something for each of these groups. The next level of testing granularity that is addressed is testing whole systems. This chapter covers the entire range, including stress testing, the wider considerations of system life cycle testing, embedded software, multi-tiered systems and more. Because my interest was testing security infrastructures I was pleased to see that the authors included security testing in this chapter. This is an added bonus, and shows the thoroughness with which the book approaches testing in the whole.
Other topics that make this a valuable book for test professionals are included in the chapter on components, frameworks and product lines. The authors show the differences between testing objects and components, and cover topics such as enterprise java beans, inspecting and testing frameworks, and interface testing.
Overall this is a comprehensive book that covers every conceivable task and topic related to O-O testing. It is well written and contains many pleasant surprises, such as security testing, and well developed test strategies for any environment with which an O-O tester will be confronted. It provided me with the exact answers to some thorny questions about validating and testing directory-enabled security, and taught me a lot more about O-O testing along the way.
Not very practical at all - 2006-01-10
Reviewer Rating: ![]()
![]()
![]()
![]()
![]()
As you might expect from a couple of academic professors this book is full of formal processes that are easy to teach and write exams around but don't scale to the real world.
The book spends 47 pages covering the basics of object oriented design (class, object, inheritance etc) and UML diagrams (class diagrams, state diagrams, sequence diagrams) yet completely ignores basic testing concepts such as white and black box testing. The book also has zero coverage of popular testing tools such as JUnit and NUnit that are making a real difference in test productivity and code quality these days.
I found only two useful ideas in the book, guided inspection and orthogonal array testing. Guided inspection is documented in mind numbing detail but unfortunately the book does such a poor job of explaining orthogonal array testing that I had to go and research it on the web.
Surprisingly for a book that claims to be a practical guide the exercises are largely ambiguous and open-ended essay style questions. The authors provide snippets of a breakout-style game that they use as a running example throughout the book. The exercises could have been so much better if they had included a design and implementation of a simpler application and set practical problems based on that code. If, like me, you learn through doing then you won't get much help from this book.
I doubt I will pick this book up again anytime soon and neither will I be recommending it to any of my friends or coworkers.
the usual not practical book - 2004-11-18
Reviewer Rating: ![]()
![]()
![]()
![]()
![]()
The book describes object orientation. Oh, come on, folks, there are tons of books on that topic and they do it better.
The contents are very object orientation centered. In my experience as a tester, I don't care about the use language, paradigm or what ever (except for reviews of course). To me it seems that OO was new to the authors and they thought it would demand many new testing strategies, which it doesn't (after the JUnit testing of course).
The proposed procedures look very much like something used at a university, but are not practical in the real world.
I am a tester and test manager and I certainly did not found any help in here.
De bons trucs pour tester du code orienté objet - 2002-10-23
Reviewer Rating: ![]()
![]()
![]()
![]()
![]()
MM. McGregor et Sykes ont GÇÜcrit dans ce livre les mGÇÜthodes qu'ils ont dGÇÜveloppGÇÜ pour tester du code orientGÇÜ objet. Les diagrammes en UML abondent et aident beaucoup GǪ illustrer leurs propos.
Les auteurs commencent par expliquer avec beaucoup de dGÇÜtails et code GǪ l'appui comment crGÇÜer des classes de pilotes pour tester les invariants, les interfaces et les mGÇÜthodes de classes simples, qu'elles soient codGÇÜes en C++ ou en Java. Apr+ás ce point, il n'y a plus de code en C++ ou en Java. L'inGÇÜvitable sujet du test des interactions entre objets est traitGÇÜ copieusement et avec suffisamment de diagrammes UML, et il est aisGÇÜ de s'inspirer du code du chapitre prGÇÜcGÇÜdent pour trouver une mani+áre de coder ce genre de tests. Ensuite, il est question de la construction de hiGÇÜrarchies de classes de pilotes pour tester des hiGÇÜrarchies correspondantes de classes. Plus loin, les auteurs dGÇÜcrivent avec bon nombre de dGÇÜtails les enjeux des tests de programmes multiprocessus, que les t¦Æches en question, GÇÜphGÇÜm+áres ou durables, soient rGÇÜparties dans le m-åme procGÇÜdGÇÜ, dans la m-åme machine ou dans un rGÇÜseau. La mani+áre de coder ce genre de test est plus complexe en C++ qu'en Java, et j'aurais aimGÇÜ avoir sous les yeux un exemple en C++.
En rGÇÜsumGÇÜ, je trouve que ce livre est un bon point de dGÇÜpart pour un programmeur qui veut tester son code orientGÇÜ objet plus GǪ fond et d'une mani+áre automatique avant de soumettre une nouvelle version. Ce livre parle tr+ás peu des tests de bo+Æte noire et qui consistent GǪ identifier des entrGÇÜes ou des conditions externes qui causent des probl+ámes avec le logiciel GÇÜtudiGÇÜ.
A wow of testing series. - 2004-04-10
Reviewer Rating: ![]()
![]()
![]()
![]()
![]()
All i can say is that I have read this book at least 4 times. Evertime it enlightened me and allow me to see OO testing in different perfectives. This is not a techie book but a practical one (as the book title claimed). After I read this book, i realized company who claimed to have top of the quality class has many missing components along the quality process.
EQ
Top Level Categories:
Software Engineering
Sub-Categories:
Software Engineering > Testing and Debugging
Some information on this page was provided using data from Amazon.com®. View at Amazon >