Full description not available
S**R
Hands-on guide for applying test frameworks
If you are developing software test automation, this is a very useful book. Especially helpful are the chapters on using data-driven testing frameworks, which reflect lots of hands-on practical experience. The framework examples are the best hands-on guides I have seen published on this valuable technique. This book fills what has been a big hole in the software test literature.
P**Y
Practical
I purchased this text while researching automated testing for my Master's paper. Mosley and Posey focus on the pragmatic aspects of implementing automated testing. Since the focus of my paper was on justifying software testing automation, I particularly apprectiated their straight forward arithmetic on tool justification. However, they go even further to address where the cost justification actually exists in areas where it may not be as obvious. This book, however, does not put a great deal of emphasis on the administrative methodology surrounding software development. It tells you this up front and addresses key success factors to implementing automated testing (ie don't automate the testing of something that's not completed or working.)The only quirk I found in the book was the diatribe against the benefit of CMM or knowledge of other models. I understand their point, which is that these models don't really add value to the hands on aspect of testing or developing software. However, from personal experience, I have seen a greater tendency in developers to consider many of the points they make if their background includes an appreciation for the types of things that should happen in a mature organization.
S**R
Not practical at all
Every time i see a "practical" book that contains a dozen pages about equivalence classes I want to scream. This book is no different. Don't know what black box testing is? Well, here you find it.The authors explain how to report defects in Excel (is anybody out there still doing that?)! Nowadays one would certainly use Bugzilla, Jira or the like.Test automation is always about tools (even if it is a self created framework) but this book is general.Test scripts should follow standard programming practice (which is even explained!). Well, it is code, so that is no great surprise.The one practical thing is the statement about where to start automation: "where it feels right". Yeah, thanks for that tipp.Conclusion: Don't waste your time. You will probably be better of if you grab a book about JUnit testing, Fitnesse or the like.
M**I
For practitioners, not managers ... gore some sacred cows
This book is written for the in-the-trenches testing practitioner. Before describing the book and its strengths, I need to state that the authors' views of certain aspects of software engineering dramatically differ from kine. Specifically, they express some disdain for applying a life cycle approach to testing in general and test automation in particular, and also don't seem to see the value of maturity frameworks, such as the CMM. On the other hand, they are forthright about their focus on the practitioner, and are strong proponents of process. My views differ from theirs in that I see the value of bounding processes within a life cycle flow, and also see the value in measuring capability. While my perspective may not be meaningful to the practitioner who is actually doing the testing, it does take into account the realities of managing an IT organization.Regardless of my opinions and views, the authors have put together a powerful, sensible approach to test automation. Key strengths include:- Pragmatism, including compelling counter arguments to my own views (especially in the first two chapters titled "What Is Just Enough Test Automation?" and "Knowing When and What to Automate". I particularly liked the distinctions between processes, and life cycles and tools.- Going straight to the critical success factors, such as requirements as the entire basis for test planning, and ensuring traceability throughout the development life cycle. In addition, the frank discussion of limitations of some testing tools, and the associated high maintenance associated with scripts, is illuminating. I also liked the way that the book shows what can be automated, and, more importantly, what cannot (or should not) be. It also reemphasizes the importance of developing a test strategy and test plans, and how automation tools fall short in some areas. An invaluable part of this aspect of the book is the discussion of test scripting languages and their strengths and weaknesses.- Examples based on real tools, with an emphasis on Rational's TestStudio. Mercury Interactive's WinRunner is also used to illustrate key concepts of the Test Plan Driven framework that is discussed later in the book.- Material that hands-on practitioners can use. While I have a high regard for the Automated Test Lifecycle Methodology that is proposed in an excellent book titled "Automated Software Testing" by Elfriede Dustin, Jeff Rashka, John Paul, that book is more for implementing and managing automated testing within the context of a life cycle, and isn't a topic to which the audience of this book will relate. Indeed, the real strength of this book is the fact that no other book on automated testing talks to the practitioners. In addition, the material covers unit, integration, and regression testing from the practitioner's point of view.- Advanced topics including data-driven approaches to testing that ties into automated suites, hybrid approaches that combine manual and automated elements, and how to develop test plans and associated artifacts.Despite my disagreement with some of what the authors views, I have to give this book my highest endorsement because, in my opinion, it's well thought out, provides one of the most thorough discussions of test automation at the practitioner level I've encountered, and is technically flawless.
R**A
Full for advertisement of software and tool from Rational Software
Book was one of the bad purchases I have ever done. Author's main idea is to promote software and tool of his organisation. When you are writing a book you should only refer to tools, software IDE popular and freely available. The tools author has mentioned: LogiCase, Quality Architect, ClearCase, ClearQuest, TestSutdio, Robot - all belong to Rational Software.
Trustpilot
1 day ago
2 months ago