Just Enough Software Test Automation (Paperback)

~ (Author), Bruce A. Posey (Author)

Editorial Reviews

Product Description

A practical hands-on guide to software test automation from the perspective of test developers and users. Includes a complete sample automation project plan, covering documentation, implementation, the automation environment, roles, responsibilities, and more. Softcover.

From the Back Cover

• Techniques that improve software quality and reduce time to market
• Pragmatic approaches to plan and manage every facet of automated software testing
• Includes a complete sample automation project plan

Practical automated testing techniques that enhance software quality and reduce time to market!

Just Enough Test Automation is a practical, hands-on guide to software test automation from the perspective of test developers and users. Two leading software testing consultants offer real-world dos and don'ts for designing and implementing test automation infrastructure—along with pragmatic advice on what today's most popular approaches to automated testing can and can't accomplish. Coverage includes:

• Setting realistic expectations: knowing when and what to automate
• Planning for automated testing
• Implementing the Control Synchronized Data Driven Testing (CSDDT) Framework, a proven approach to simplify and accelerate testing
• Simplify maintenance of test scripts and promote reuse using structured test script writing.
• Automating unit testing, integration testing, and system/regression testing
• Managing the automated testing process for optimal efficiency

The book also includes a complete sample automation project plan, covering documentation, implementation, the automation environment, roles, responsibilities, and much more.

See all Editorial Reviews

Product Details

• Paperback: 288 pages
• Publisher: Prentice Hall PTR (July 25, 2002)
• Language: English
• ISBN-10: 0130084689
• ISBN-13: 978-0130084682
• Product Dimensions: 9.2 x 7 x 0.7 inches
• Shipping Weight: 1 pounds (View shipping rates and policies)
• Average Customer Review: 4.6 out of 5 stars  See all reviews (9 customer reviews)
• Amazon.com Sales Rank: #321,747 in Books (See Bestsellers in Books)

  Popular in this category: (What's this?)

  #91 in

  Books > Computers & Internet > Programming > Software Design, Testing & Engineering > Testing

Customer Reviews

Most Helpful Customer Reviews

31 of 33 people found the following review helpful:

5.0 out of 5 stars For practitioners, not managers ... gore some sacred cows, August 12, 2002

By	Mike Tarrani "www.tarrani.com" (Deltona, FL USA) - See all my reviews (TOP 500 REVIEWER)    (REAL NAME)    (COMMUNITY FORUM 04)

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.

13 of 13 people found the following review helpful:

5.0 out of 5 stars Practical hands-on guide to successful test automation, August 19, 2002

By A Customer

As a software tester, I have been witness to several well-meaning attempts at software test automation end up in failure.

Usually the unsuccessful attempts end up at some point with a declaration similar to the following: We just do not have time to automate testing right now!

The automation tool becoming unused Shelfware usually follows this scenario. Meanwhile, the project moves forward without the many benefits of automated software testing.

The reasons for these failures have been many. I believe that every one of these reasons has been addressed in this practical hands-on guide.

This book stresses the importance of front-end test planning and test design activities.

It is especially effective at explaining why the traditional capture/playback model that testing tool vendors have championed for years just does not work most of the time in the real world of testing applications.

The case for data-driven automated testing is logically and thoughtfully presented. Not only is the data-driven approach presented, the book explains how to actually implement sound data-driven test scripts. The fundamental concept of separating data from function in the development of test scripts is clearly explained.

A very important section of the book offers practical advice on whether or not to automate, as well as when and what to automate.

Because the authors are actual practitioners they offer useful advice on test automation from the test automation developers/users perspective. It includes very pragmatic advice obviously gleaned through actual hands-on experience on what to do and what not to do when designing and implementing a test automation infrastructure.

I found the book to be really worth the read. I would advise anyone interested in the successful implementation of automated software testing to read this book.

10 of 11 people found the following review helpful:

5.0 out of 5 stars Invaluable for all Test Automators, June 23, 2003

By	Aidy Rutter (Gtr. Manchester United Kingdom) - See all my reviews

"Purchasing a software testing tool suite does not constitute implementing a software process". Wise words from Dan Mosley and Bruce Posey in "Just Enough Software Test Automation"; maybe some development managers need to take heed.

Too many times have automated test tools become shelfware, or the cost of maintaining the scripts prohibitvely expensive. The authors of this book offer a simple and easy to use data-driven framework that can minimise scripts and human effort. They place their framework within the Rational Unified Process (RUP).

The book offers actual and detailed advice that goes all the way down to code and script templates. Based mostly on Rational tools, the book gives lip service to Winrunner and anything said can be translated to any automated tool.

Their open-source framework is the Control Synchronized Data Driven Testing(CSDDT). Data to be input, keywords to navigate through the application and actions to be performed are held in the spreadsheet. There are four main scripts: A Main script that reads and processes the records; a window selection script, a tab selection script, an action script and error handling script. Data input is held in an array and there is a comment field that documents the test record. Your application code is held in a switch statement, and it is highly conceivable that your project can have single figure script numbers. There is also a script that converts the spreadsheet data in a .csv file that is read by the Main script. There is detailed
information given on how to implement the CSDDT. It is a framework I use and am pleased with.

There are two interesting chapters on Unit and Integration testing. Like eXtreme Programmers they believe in automating unit tests that pass at 100% before submitting for build. They correctly argue that unit tests should be constructed before development code is written and they also point to the xUnit group of tools.

They make insightful points about the necessity of integration testing: Could you not help but identify with the following statements: "... We have seen two chronic problems: First, the build fequently does not install on system test machines. Second, the fact that unit and integration testing has not been done previously forces the system test team to do tests that development should have already executed." Again they also argue for automated integration testing else "it will not get done."

I feel however that Mosley and Posey's ideas need to be infused with agile values and practices. For example do we really need improved software requirements documentation, verbose Test Plans and meticulous test design when requirements change so much? Do we really need all these Rational tools and the time it takes to use and update them? Can we not make automated functional tests an integral part of requirements? What about Pair Test Programming? How are we going to increase oral communication? Is devolopment and test a false dichotomy? These kind of issues also need to be addressed as we begin to construct software in a radically different way.