Most Helpful Customer Reviews
6 of 7 people found the following review helpful:
5.0 out of 5 stars
For mature organizations, June 19, 2004
This review is from: Best Practices for the Formal Software Testing Process: A Menu of Testing Tasks (Paperback)
First, this book is not primarily for software test and QA professionals who are working in 'typical' organizations. As noted by others, the approach this book provides is best suited to organizations that are at least at CMM level 3. Moreover, unless software engineering practices across the organization are mature the approach will probably fail. However, that does not prevent even a Level 1 organization from selecting best practices and tasks set forth in this book and applying them. The net result will be an incremental improvement, and may be the catalyst for larger improvements with a small win. That said, this book is invaluable to mature organizations that are committed to software engineering at the defined, managed or optimizing levels of maturity. It distills formal test practices drawn from a variety of sources and the author's experience into a succinct, process-oriented guide. The model itself is presented in IPO (Input-Process-Output) diagrams that start at a high level to describe the process itself, and drill down into successive levels of detail in level 2 and 3 IPO diagrams. This process-oriented structure gives a great deal of clarity to a complex set of processes that touch all milestones in any SDLC. I like the fact that the model proposed is not rigid, but can be tailored to development life cycle approaches ranging from waterfall to agile approaches. Chapter 8 gives advice on how to accomplish the tailoring without breaking the integrity of the process. I also found the appendices useful, especially Appendix B (preferred practices) and the plans and templates provided, and Appendix C (testing processes evaluation questionnaire). If your organization is pursuing CMM level 3 or above, or are contractually required to have a formal software engineering process or process capability, this book will address the software testing process areas of a larger initiative. However, do not overlook some of the small wins a chaotic organization can achieve by using many of the ideas in this book.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
1 of 1 people found the following review helpful:
5.0 out of 5 stars
Great Reference for Formal S/W Engineering / Testing Systems (Actual or Desired), January 5, 2007
This review is from: Best Practices for the Formal Software Testing Process: A Menu of Testing Tasks (Paperback)
I purchased this book based on Amazon's information and the reviews. My purposes in doing so are different than most who would / should consider it -- to audit and assist US FDA-regulated companines in compliance, including the requirement for validating software in medical devices, or in manufacturing and data systems used to manufacture FDA-regulated products (devices and drugs). Given that caveat, Rodger's book is an excellent resource. He supplements his narrative with numerous diagrams which he defines as describing a process and a "set of tasks that can be used to implement or improve a formal testing program". His stated assumptions (a pre-existing formal system in place at a company; specifically defined by the Capability Maturity Model / CMM 3-4+; with a separate reporting structure -- or, as he stated, "the full blown model described in this book details a full-featured formal testing process that is applicable to large programs and that would fully support programs deliverable to state and federal governments, or on programs delivering safety-critical systems or having significant impact on corporate profits" ). What he describes would fit well with the FDA's GMPs(Good Manufacturing Practices), a quality system similar to but more stringent than ISO 9001 / 13485, and various FDA /Agency guidance documents on software validation (a series of structured documentation and testing requirements). Although presented for / geared to a large corporation w/ greater resources, I would argue that the basic principles he discusses, and the systems approaches recommended, are adaptable, and 'down-scaleable' to any size company. It also provides a model / target to aim for by any software developer / provider, including (especially) the small shop, a requirement trend that will probably only increase, and globally -- and providing such companies a competitive advantage, and enhance the Intellectual Property (IP) value of the resulting product. His strategic level and test level discussions also provide the basis for input to software portions of a company's documentation -- the Quality Manual, SOPs (standard operating procedures), and WIs (work instructions) for both engineering and testing / QA. Certainly, the recommendations, systems, documentation and efforts outlined in this book, if followed in principle, would greatly reduce the problems experienced in software / hardware implementation projects, including some recent failures / delays receiving nationwide publicity. As such, it has proven to be a valuable addition to my consulting library, and a useful reference in conducting audits, making recommendations, and developing validation protocols.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
2 of 3 people found the following review helpful:
5.0 out of 5 stars
Learn how to deal with the hard task of software testing, March 14, 2004
This review is from: Best Practices for the Formal Software Testing Process: A Menu of Testing Tasks (Paperback)
Testing large software projects is a very difficult task. Testing can only reveal the presence of bugs, not their absence and it is impossible to cover all possible pathways that the software can traverse. Furthermore, and what is the worst, "simple" changes made in software can cascade across many modules, requiring the re-testing of all affected modules. Therefore, any testing plan must incorporate repeating tests based on feedback. Finally, testing is something that must be done, so there is no choice in the matter. The practices described in this book are all modeled using Input-Process-Output (IPO) diagrams, which are labeled state diagrams. The states in the diagrams are partitioned into three sections, input, process and output. Inputs are represented as labeled arrows, which can originate from another state, but do not have to. The process section describes what is to be done at that stage and the output section has labeled arrows exiting the state that then go to the next state. Multiple inputs and outputs are possible and the flow can loop back to a previous state. Each state is described in the text, where the inputs for the state are explained in detail. Applicable feedback from all persons with a stake in the operation is discussed as well as feedback that this state can give to previous states. The process is described and then the outputs that the state will send to later states are explained. Feedback that may be received from states later in the sequence is then described. What is most impressive about these modeling diagrams is the extensive allowance for feedback. The complexity of the testing process and the consequences of the results means that testing can form a feedback loop that exhibits many of the characteristics of chaos. A loop is chaotic when small changes can cascade into very big changes. The way to prevent this in any process carried out by humans is to incorporate damping mechanisms. These features reduce the impact of any result so that they do not grow beyond the bounds of the system to handle them. When faced with impossible tasks, something that software testing has now become, the best that you can do is examine a subset composed of the most likely scenarios. By applying the models in this book, it is possible to raise the level of your testing quality to the point where you can be confident in your software
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
|
