Best Practices For The Formal Software Testing Process - Pearsoncmg

1y ago
13 Views
1 Downloads
2.79 MB
57 Pages
Last View : 24d ago
Last Download : 6m ago
Upload by : Vicente Bone
Transcription

BEST PRACTICES FOR THEFORMAL SOFTWARETESTING PROCESS

Also Available from Dorset House PublishingThe Deadline: A Novel About Project Managementby Tom DeMarcoISBN: 0-932633-39-0 Copyright 1997 320 pages, softcoverDr. Peeling's Principles of Management:Practical Advice for the Front-Line Managerby Nie PeelingISBN: 0-932633-54-4 Copyright 2003 288 pages, softcoverFive Core Metrics: The Intelligence Behind Successful Software Managementby Lawrence H. Putnam and Ware MyersISBN: 0-932633-55-2 Copyright 2003 328 pages, softcoverMeasuring and Managing Performance in Organizationsby Robert D. Austin foreword by Tom DeMarco and Timothy ListerISBN: 0-932633-36-6 Copyright 1996 240 pages, softcoverPeopleware: Productive Projects and Teams, 2nd ed.by Tom DeMarco and Timothy ListerISBN: 0-932633-43-9 Copyright 1999 264 pages, softcoverProject Retrospectives: A Handbook for Team Reviewsby Norman L. Kerth foreword by Gerald M. WeinbergISBN: 0-932633-44-7 Copyright 2001 288 pages, softcoverSurviving the Top Ten Challenges of Software Testing:A People-Oriented Approachby William E. Perry and Randall W. RiceISBN: 0-932633-38-2 Copyright 1997 216 pages, softcoverWaltzing with Bears: Managing Risk on Software Projectsby Tom DeMarco and Timothy ListerISBN: 0-932633-60-9 Copyright 2003 208 pages, softcoverFor More Information Contact us for prices, shipping options, availability, and more. Sign up for DHQ: The Dorset House Quarterly in print or PDF. Send e-mail to subscribe to e-DHQ, our e-mail newsletter. Visit Dorsethouse.com for excerpts, reviews, downloads, and more.DORSET HOUSE PUBLISHINGAn Independent Publisher of Books onSystems and Software Development and Management. Since 1984.353 West 12th Street New York, NY 10014 USA1-800-DH-BOOKS 1-800-342-6657212-620-4053 fax: 212-727-1044info@dorsethouse.com www.dorsethouse.com

BEST PRACTICES FOR THEFORMAL SOFTWARETESTING PROCESSA MENUOFTESTINGTASKSRodger D. Drabicks\DHDorset House Publishing353 West 12th StreetNew York, NY 10014

Library of Congress Cataloging-in-Publication DataDrabick, Rodger.Best practices for the formal software testing process : a menu of testingtasks / Rodger Drabick.p. cm.Includes bibliographical references and index.ISBN 0-932633-58-7 (softcover)1. Computer software-Testing. I. Title.QA76.76.T48D73 2003005.1'4-dc222003062472All product and service names appearing herein are trademarks or registeredtrademarks or service marks or registered service marks of their respective owners and should be treated as such.Cover Design: Nuno AndradeCover Graphic: Detail from Figure 1-5Cover Author Photograph: Courtesy of Lockheed MartinCopyright 2004 by Rodger D. Drabick. Published by Dorset House PublishingCo., Inc., 353 West 12th Street, New York, NY 10014.All rights reserved. No part of this publication may be reproduced, stored in aretrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of thepublisher.Distributed in the English language in Singapore, the Philippines, and Southeast Asia by Alkem Company (S) Pte. Ltd., Singapore; in the English languagein India, Bangladesh, Sri Lanka, Nepal, and Mauritius by Prism Books Pvt.,Ltd., Bangalore, India; and in the English language in Japan by Toppan Co.,Ltd., Tokyo, Japan.Printed in the United States of AmericaLibrary of Congress Catalog Number: 2003062472ISBN: 0-932633-58-7121110 987Digital release by Pearson Education, Inc., June, 2013654321

DedicationTo my wife, Karen, without whose love and support this book and theother things I do would not be possible; and to my daughters, Alysonand Liz—I love you all.

This page intentionally left blank

AcknowledgmentsMany people—including coworkers, managers, SQA and testing associates, family, and friends—have earned a special Thank You for helpingme bring my ideas from a concept to a published book.I'd like first to express my thanks—in memoriam—to Peter Natale,formerly of Eastman Kodak Company, who provided me with my firstopportunity in software testing. Without Pete's support and mentorship, this book would not have been possible. Thanks also to FrankMondziel, who provided guidance in our first efforts in software QA andtesting at Kodak, and to Ed Cattron, a long-time friend, coworker, andmanager at Kodak, who supported my initial efforts to develop and formalize this process model on a large and complex Internal RevenueService program in the early 1990's.I also owe a great debt of gratitude to Bill Perry of the QualityAssurance Institute and Dr. Edward Miller of Software Research, Inc.,both of whom gave me the opportunity to present portions of thismodel at their testing conferences. I made my first presentation on thetopic as a keynote address at a Software Quality Week, hosted by Edand his company. Independent consultant Denis Meredith gave methe opportunity to present the model end-to-end at one of the TestingComputer Software Conferences he coordinated. Denis remains my"go to guy" for questions about requirements and risk management.vii

viii ACKNOWLEDGMENTSThank you very much, gentlemen! It's been a pleasure knowing you,and learning from you.To so many at Software Quality Engineering who have been helpfulto me along the way, I give special thanks: Bill Hetzel, former presidentof SQE, and Dave Gelperin and Rick Craig, associates at SQE—all ofyou have provided invaluable technical and moral support throughoutmy testing career.Lisa Crispin, coauthor of Testing Extreme Programming, introducedme to special techniques for approaching testing of that agile method.For that knowledge and for reviewing a number of draft chapters, Lisa,I am deeply grateful.It's difficult to adequately express the gratitude I owe to several editors. First, my friend of many years, Debbie Lafferty, formerly Acquisitions Editor at Addison-Wesley, started me working on this book. Debbie introduced me on-line to Wendy Eakin at Dorset House Publishing,and that introduction has resulted in the final product you hold inyour hands. To Wendy and the rest of the Dorset House staff, including Nuno Andrade, Vincent Au, and David McClintock, many thanksfor helping me turn a concept into a real book that I hope will providevaluable information to the testing community! Thanks also to DorsetHouse author and software systems consultant Tim Lister, for his recommendation that this book be published.And finally, a lifetime of gratitude and thanks to Karen, my wifeand friend of many years. Without your help and encouragement, thisbook would never have been started, much less completed.

ContentsForewordPrefacexiiixvChapter 1 Introduction31.1: OVERVIEW31.2: THE SOFTWARE DEVELOPMENT LIFE CYCLE41.3: THE FORMAL TESTING LIFE CYCLE61.4: ORGANIZATIONAL CONSIDERATIONS 111.5: THE NEED FOR THE PROCESS MODEL161.6: How то USE THE FORMAL TESTING PROCESS MODEL1.7: INPUT-PROCESS-OUTPUT MODELS211.8: LEVEL 0 IPO MODEL FOR FORMAL TESTING241.9: LEVEL 1 IPO MODEL FOR FORMAL TESTING251.10: LIMITATIONS INHERENT IN THIS BOOK'S SCOPE261.11: WHAT'S NEXT?2717Chapter 2 The Formal Testing Process Model: Level 1 IPODiagrams282.1: OVERVIEW282.2: EXTRACT TEST INFORMATION FROM PROGRAM PLANS—LEVEL 1 IPODIAGRAM28ix

x CONTENTS2.3: CREATE TEST PLAN 342.4: CREATE TEST DESIGN, TEST CASES, TEST SOFTWARE, AND TESTPROCEDURES392.5: PERFORM FORMAL TEST432.6: UPDATE TEST DOCUMENTATION472.7: WHAT'S NEXT?50Chapter 3 Extract Test Information from Program Plans: Levels 2and 3 IPO Diagrams513.1: OVERVIEW 513.2: EXTRACT TEST INFORMATION FROM PROGRAM PLANS—LEVEL 2 IPODIAGRAM523.3: REVIEW PROGRAM MANAGEMENT PLAN—LEVEL 3 IPO DIAGRAM 563.4: REVIEW QUALITY ASSURANCE PLAN—LEVEL 3 IPO DIAGRAM 603.5: REVIEW SOFTWARE DEVELOPMENT PLAN—LEVEL 3 IPO DIAGRAM643.6: REVIEW CONFIGURATION MANAGEMENT PLAN—LEVEL 3 IPODIAGRAM693.7: WHAT'S NEXT?72Chapter 4 Create Test Plan: Levels 2 and 3 IPO Diagrams4.1: OVERVIEW73734.2: CREATE TEST PLAN—LEVEL 2 IPO DIAGRAM 744.3: ANALYZE REQUIREMENTS—LEVEL 3 IPO DIAGRAM4.4: WRITE TEST PLAN—LEVEL 3 IPO DIAGRAM 834.5: REVIEW TEST PLAN—LEVEL 3 IPO DIAGRAM 894.6: WHAT'S NEXT?9378Chapter 5 Create Test Design, Test Cases, Test Software, and TestProcedures: Levels 2 and 3 IPO Diagrams945.1: OVERVIEW 945.2: CREATE TEST DESIGN, TEST CASES, TEST SOFTWARE, AND TEST PROCEDURES—LEVEL 2 IPO DIAGRAM955.3: REVIEW TEST PLAN—LEVEL 3 IPO DIAGRAM 1025.4: CREATE TEST DESIGN—LEVEL 3 IPO DIAGRAM 1055.5: REVIEW TEST DESIGN—LEVEL 3 IPO DIAGRAM 1095.6: CREATE TEST CASES—LEVEL 3 IPO DIAGRAM 1135.7: ACQUIRE TEST SOFTWARE-BUILD—LEVEL 3 IPO DIAGRAM 119

CONTENTSxi5.8: ACQUIRE TEST SOFTWARE-BUY—LEVEL 3 IPO DIAGRAM1235.9: CREATE TEST PROCEDURES—LEVEL 3 IPO DIAGRAM1265.10: WHAT'S NEXT?131Chapter 6 Perform Formal Test: Levels 2 and 3 IPO Diagrams 1326.1:6.2:6.3:6.4:6.5:OVERVIEW132PERFORM FORMAL TEST—LEVEL 2 IPO DIAGRAM133HOLD PRETEST MEETING—LEVEL 3 IPO DIAGRAM137EXECUTE TEST—LEVEL 3 IPO DIAGRAM141DETERMINE DISPOSITION OF INCIDENTS—LEVEL 3 IPODIAGRAM1466.6: HOLD POSTTEST MEETING—LEVEL 3 IPO DIAGRAM1516.7: WRITE TEST REPORT—LEVEL 3 IPO DIAGRAM1556.8: WHAT'S NEXT?159Chapter 7 Update Test Documentation: Levels 2 and 3 IPO Diagrams1607.1: OVERVIEW1607.2: UPDATE TEST DOCUMENTATION—LEVEL 2 IPO DIAGRAM1617.3: ANALYZE TEST DOCUMENTATION PROBLEMS—LEVEL 3 IPODIAGRAM1647.4: UPDATE TEST DOCUMENTS—LEVEL 3 IPO DIAGRAM1677.5: REVIEW AND APPROVE SOFTWARE TEST DOCUMENTS—LEVEL 3 IPODIAGRAM1707.6: WHAT'S NEXT?173Chapter 8 Tailoring the Model1748.1: OVERVIEW1748.2: USING THE TESTING PROCESS MODEL FOR LARGE, SAFETY-CRITICAL,OR PROFIT-CRITICAL PROGRAMS1758.3: USING THE TESTING PROCESS MODEL FOR MEDIUM-SIZEPROGRAMS1788.4: USING THE TESTING PROCESS MODEL ON SMALL PROJECTS1798.5: USING THE PROCESS MODEL WITH EXTREME PROGRAMMING1818.6: STARTING FROM SCRATCH183Chapter 9 Summing Up1889.1: REPRISE: How то USE THE TESTING PROCESS MODEL9.2: SUMMARY THOUGHTS1939.3: CONCLUSION196188

xü CONTENTSAppendices197Appendix A: The Software Engineering Institute, the CapabilityMaturity Model-Software, and the Capability Maturity ModelIntegration199A. 1: THE CAPABILITY MATURITY MODEL FROM THE SOFTWARE ENGINEERINGINSTITUTE AT CARNEGIE MELLON UNIVERSITY199A. 2: CAPABILITY MATURITY MODEL INTEGRATION202Appendix B: Preferred Practices204B.I: PROGRAM MANAGEMENT PLAN AND TEMPLATE204B.2: SOFTWARE DEVELOPMENT PLAN AND TEMPLATE213B.3: SOFTWARE QUALITY ASSURANCE PLAN AND TEMPLATE221B.4: CONFIGURATION MANAGEMENT PLAN AND TEMPLATE229Appendix C: Questionnaire for Evaluating Local TestingProcesses 249C.I: EXTRACT TEST INFORMATION FROM PROGRAM PLANS249C.2: CREATE TEST PLAN252C.3: CREATE TEST DESIGN, TEST CASES, TEST SOFTWARE, AND TEST PROCEDURES254C.4: PERFORM FORMAL TEST257C.5: UPDATE TEST DOCUMENTATION259Appendix D: A Primer for Test ExecutionGlossary267BibliographyIndex281275260

ForewordRodger and I first met in 1985 at the Testing Computer Software Conference, which I coordinated. This was Rodger's first software testingconference, and like many folks new to software testing, he was determined to learn as much as he could about the fascinating field of software testing in the limited time available. At the time, Rodger hadbeen working as a team lead for system testing on a large software program for a government customer.Over the years, I watched Rodger's career develop, and witnessedas his focus changed from learning and using testing techniques, totesting management, and finally to concentration on the software testing process. In the mid-1990's, Rodger presented aspects of hisprocess model at the Quality Assurance Institute's International Conference on Software Testing, the same process model that this bookdescribes in detail.Best Practices for the Formal Software Testing Process: A Menu ofTesting Tasks is the product of the knowledge that Rodger has gainedthrough personal experience as well as from seminars and conferencesput on by the QAI and other well-respected testing organizations.Primarily intended to help new test engineers and test engineeringmanagers understand the steps involved in testing software systemsand hardware-software systems, this book will be useful to any testingorganization interested in documenting and improving its testingxiii

xiv FOREWORDprocess. It begins by showing you how to develop a test plan based onthe software and system requirements, which identifies exactly whatwill be tested, and goes on to detail the tasks and processes involved inexecuting the test and documenting the results of the testing.While this book focuses primarily on testing associated with largedevelopment programs—using either a spiral life cycle or the UnifiedSoftware Development Process, with its iterative phases—the information Rodger offers can be put to the most effective use through tailoring the process to fit your specific environment.Readers familiar with the testing documentation and testing lifecycle contained in IEEE-Standard-829, the Standard for Software TestDocumentation, will readily see the links to the process model detailedin this book. Nevertheless, those working with other life cycles willfind guidance in tailoring this testing process to fit those life cycles.Best Practices for the Formal Software Testing Process serves as afine example of What to Do to Test. As Rodger writes, this is the bookhe wished he'd had when he started his software testing career. Thisbook should be in the hands of every member of every software testingorganization. If you buy this book, plan to use it; don't just set it onyour bookshelf.September 2003Orlando, FloridaWilliam E. Perry

PrefaceWhat is "the formal software testing process"?One of the definitions the Institute of Electrical and ElectronicsEngineers (IEEE) Software Standards collection provides for process is"a course of action to be taken to perform a given task" or "a writtendescription of a course of actions, for example, a documented test procedure." Various editions of Webster's Dictionary offer a series of definitions for process, including "a particular method of doing something,generally involving a number of steps or operations."A simpler definition of a process is "the way we do things."Thus, we could say that the "testing process" is "a course of actionto be taken to perform formal testing," or "the way we do testing here."But, how does "the way we do testing here" stack up against industry standards for best testing practices, and why did I go to all theeffort to define a Formal Testing Process Model? Let me share a shortpersonal retrospective.I have spent twenty-eight years of a mostly exciting technicalcareer testing and managing testing programs. These programsstarted out as hardware programs, and evolved into hardware andsoftware systems programs in the mid-1970's. I was lucky in somerespects to work for a large company in the Department of Defense(DoD) area; thus, we were always in an environment that forced us tobe rigorous and methodical, both in test execution and in test docuxv

xvi PREFACEmentation. Note that being methodical didn't always lead to deliveringsuccessful systems.When I first began working in programs that were primarily software, I was looking for sources of material on "best practices" relative tothe software testing process. Being in the DoD environment, our customers supplied Contract Deliverable Requirements Lists (CDRLs) thatidentified the documents we had to write. Thus, we had a frameworkfor our programs. Later, I discovered a number of military standards(for example, DoD-Standards 2167A and 2168), and the IEEE SoftwareEngineering Standards, which I continue to use to this day. Followingthe series of documentation contained in IEEE-Standard-829, the Standard for Software Test Documentation, suggested a standard process toutilize for software and systems test documentation.In 1992, while working in the Commercial and Government Systems Division of the Eastman Kodak Company, my job was to developa testing estimate for a program we were bidding for the Internal Revenue Service. Having built estimates previously for large, complex,testing programs, I knew that I needed a logical, structured list oftasks to form the basis of my estimate. I could then convert this tasklist into a work breakdown structure (WBS), and estimate the time toperform each task.About this same time, I was reading Watts Humphrey's fascinatingbook Managing the Software Process (Humphrey, 1989). Watts showedhow to use Input-Process-Output (IPO) diagrams to document aprocess; I applied that technique to the testing process. That was thefirst formal documentation of the top levels of the model you will seedescribed in this book. I published an article describing how aspectsof this model could be used in estimating, in 1993 in the June issue ofEd Yourdon's American Programmer newsletter (Yourdon, 1993).!That's one use of such a model. Over the years, I continued to refinethe model until it became the fairly detailed model presented in thisbook.Incidentally, our prime contractor accepted my estimate, and bothit and the Internal Revenue Service accepted the overall estimate.The first light bulb that lit as I began to learn about software testing is that testing has a life cycle that is closely linked to the softwaredevelopment life cycle. What seems like a logical truth in 2003 was areal revelation to many in the mid-1970's. I still think that the "V-diagram" is a thing of beauty. The V-diagram is a means of illustratingthe relationship between the concurrent software development andtesting life cycles (see Figure 1-2 for one example of the V-diagram).Unfortunately, there are still a large number of people and corpora1 Rodger D. Drabick, "A Process Model Tool for Estimating Software Costs," American Programmer, Vol. 6, No. 6 (1993), pp. 20-27.

PREFACExviitions developing software who haven't recognized this basic truth. Wewrite a test plan while requirements are being developed. We then dotest design and write test cases as the software design is being developed, and write test procedures during the coding phase.2 Executionof formal testing occurs following unit testing and integration testing.The second light bulb that lit pertained to the critical importance oftest planning, and the consequent need for "testable requirements."Many good books have been written on these subjects (Cause andWeinberg, 1989; Wiegers, 1999), so I will not belabor the point here.The third light bulb that was turned on was realizing that to properly estimate testing programs, we need a structured, internally consistent list of tasks that test engineers will perform on a specific program. Once such a list of tasks is in hand, we can then estimate eachtask individually to get a bottoms-up estimate for a testing program.And if we perform the same set of tasks (or a very similar set) on eachprogram, we can begin to establish accurate metrics for how much ourtesting costs, and how long it can be expected to take.In brief, what I am providing in this book is a soup-to-nuts list oftasks and processes for a program of formal software or system testing.If you are just starting to implement a testing process, you will not wantto try to implement all parts of this model in one fell swoop; it would betoo overwhelming and too costly. In later chapters, I suggest ways toimplement this process in a prioritized, piecewise fashion.ObjectivesThere is no "one true way" to test software, so the goal of this book isto provide you with information that you can use to develop a formaltesting process that fits the needs of you, your customers, and yourorganization.Glenford Myers woke up the testing community in 1979 with hisbook The Art of Software Testing; he stated that the purpose of testingis to find errors, rather than to prove that a system works. Regardlessof what your opinion of his thesis is, we test to see if we can find anyproblems with developed systems. A best-practices test process is performed throughout the duration of the development process. The testprocess puts appropriate emphasis on requirements testability, documentation prior to test execution, review of the documentation, systematic interface with the development community, and test executionaccording to the approved documentation. A series of tasks to accomplish this testing process is presented in this book. See the Glossary at the end of this book for a definition of "test case" as there is muchconfusion in the industry regarding this term.

xviii PREFACEIn addition to defining the sequence of tasks in the testing process,I address interfaces between the formal testing group and the otherorganizations involved in the software development life cycle, includingdevelopment engineers, managers, software quality engineers, andsoftware configuration management personnel. All of these peoplehave significant roles that must be performed in a quality manner tomake the software development process and the software testingprocess work. One of the primary purposes of test documentation iscommunication with the other groups on the program, so we as testengineers must be sure to make these intergroup interfaces work. Allof us should be aware that there's a Level 3 key process area (KPA) inthe Software Engineering Institute's Capability Maturity Model(SEI-CMM) for Intergroup Coordination. Early in the development lifecycle, test engineers and managers review program-level plans, including the Program Management Plan (PMP), the Configuration Management Plan (CMP), the Software Quality Assurance Plan (SQAP), and theSoftware Development Plan (SDP), or whatever you call these documents in your environment. During the requirements phase of thesoftware development life cycle, test engineers review the requirements. Later in the life cycle, the groups that authored these plansand the requirements get to return the favor by reviewing the test plan.Test engineers review software design (and sometimes code) for inputto their test designs, test cases, and test procedures. Once again,development engineers, QA staff members, and CM personnel shouldreview the test designs, test cases, and test procedures. As has beenshown in other reference materials (Wiegers, 2002), peer reviews minimize defects and cost-of-quality by finding defects as early as possiblein the life cycle.Intended AudienceI have written this book for four specific audiences, who have much incommon: new test engineers, who want to learn more about theframework of tasks performed as part of a good testingprocessnewly assigned test managers and team leaders, whoare not experienced testers (but may have come from adevelopment, quality assurance, or systems engineeringbackground) and who need to learn more about testingquickly

PREFACE xixmore experienced test engineers, who are looking forways to improve their testing processprocess improvement leaders, such as members of software engineering process groups and quality assurancestaffAll of these folks realize that testing is necessary to verify the quality ofthe delivered product(s). They should also be aware that a coordinatedprogram of peer reviews and testing can support a good software development process, but if the developers fall short of building a qualityproduct, it's not possible to "test quality in."Organizations that are pursuing Level 3 of the Capability MaturityModel for Software (for additional detail on the Capability MaturityModel from the Software Engineering Institute at Carnegie Mellon University, see Appendix A and Website www.sei.cmu.edu) will also findthis book valuable, since testing is a significant component of theSoftware Product Engineering key process area for CMM Level 3. Thenewer Capability Maturity Model Integration (CMMI), with componentsof Systems Engineering, Software Engineering, Integrated Product andProcess Development, and Supplier Sourcing, has process areas forVerification and for Validation, both of which involve aspects of testing.This book will assist them in documenting their testing process, whichwill support them in the Level 3 key process area Organization ProcessDefinition.There's actually a fifth audience as well, those software development team leads, supervisors, and managers who are interested inlearning more about what test engineers and the testing group aredoing, and why.PrerequisitesWhat should you know to read this book? You should be aware thattesting is not a "phase," where software developers "throw the softwareover the wall" to test engineers when the developers have finishedcoding. To be cost effective, testing needs a life cycle that runs concurrently with the software development life cycle. The testing life cyclebegins during the requirements elucidation phase of the softwaredevelopment life cycle, and concludes when the product is deemedready to install or ship following a successful system test (or whateveryou call the final test in your culture).Ideally, you should be aware of the importance of test documentation, especially a formal test plan, in your life cycle. You should be

xx PREFACEaware that there are good standards for this documentation in thesoftware industry; I strongly recommend the IEEE Software Engineering Standards collection in general, and IEEE-Standard-829, the Standard for Software Test Documentation, in particular.Finally, you should have the desire to improve your knowledge ofthe testing process, and a commitment to make improvements.How to Read This BookThis book is laid out in the following order:1. Chapter 1 provides a general overview of the softwaredevelopment life cycle, and an overview of the concurrent testing life cycle. It also shows the need for a testing process model, and illustrates the Level 0 and Level1 IPO diagrams for this model.2. Chapters 2 through 7 show decomposition of the Level1 IPO diagram into a series of Level 2 and Level 3 diagrams, to show the tasks involved in the review of program plans, the creation of a test plan, the creation oftest design (and other test documentation), the performance of formal test, and finally, the updating of testdocumentation. This set of tasks can be used as thebasis for an estimate of a formal testing program on aparticular development program.3. Chapter 8 provides some thoughts on how to use andcustomize this process model, which is a soup-to-nutsmodel. You may not be in a position to use such amodel initially, but on a large program, putting thisprocess in place should be your goal. Customizing themodel should be your goal on a medium- or small-sizeproject. Thus, this model provides a template for a testing process improvement program. To end the textitself, Chapter 9 provides a brief summary of the modelin its entirety.4. To conclude the book, I've added four practical Appendices, a Glossary, a Bibliography, and, of course, anIndex. Although most of these final sections are standard fare, the Appendices bear describing. Appendix Aprovides a brief description of the Capability MaturityModel for Software (CMM-SW) from the Software Engineering Institute at Carnegie Mellon University, as well

PREFACExxias a brief description of the SEI's more recent CapabilityMaturity Model Integration (CMMI). Appendix В provides templates for five preferred practices that are significant to a software development program, including aProgram Management Plan (PMP), a Software Development Plan (SDP), a Software Quality Assurance Plan(SQAP), a Configuration Management Plan (CMP), and aTest Plan (TP). Appendix С provides a questionnaireyou can use to evaluate the state of your testingprocess. Let this guide your use of the Formal TestingProcess Model as a mechanism to help you improveyour testing process. Appendix D contains guidelinesfor test execution.To gain a detailed understanding of the tasks, inputs, and outputsinvolved in formal testing, you can simply read the book from front toback. For readers desiring to explore specific aspects of the testingprocess (for example, test execution), I would recommend skimmingChapter 1 (Introduction), reviewing Chapter 2 (The Formal TestingProcess Model: Level 1 IPO Diagrams) to identify which process youwant to explore in more detail, and then proceeding directly to thatchapter (for one example, test execution, see Chapter 6, "Perform Formal Test," and Appendix D). Though there are sections for each subprocess of the major processes (for example, subprocess Execute Test,major process Perform Formal Test), I would suggest there are enoughinterfaces between the various subprocesses that the entire sectionshould at least be skimmed.I don't spend much time discussing the topic of testing tools andtest automation, because these are really software development programs, not test processes. However, there are two subprocessesdefined for Acquire Test Software in Chapter 5, which should bereviewed. One subprocess deals with building your own test softwaretools; the second subprocess addresses the activities involved in buying the tools you need.I hope that this book will start you thinking about the followingquestions: Does our current testing process have all the tasks weneed to identify defects in the products under test? Ifnot, which tasks should we add first to improve ourtesting process? Have we identified the next step in our continuousprocess improvement plan?

xxü PREFACE Do we have the necessary reviews in our testing process(for example, Test Plan inspection)?Are we writing all the test documentation we need toprovide high-quality repeatable tests?Is testing and test coverage adequate for our program(for example, enough time, enough test points)?If you can answer yes to all these questions, then you probably don'tneed to read this book in its entirety. But are you sure that your testprocess is as good as it can be?There is one additional caveat to keep in mind as you read thisbook: You will not find the term "bugs" used. I once heard a testingguru state at a conference that he didn't

3.3: review program management plan—level 3 ipo diagram 56 3.4: review quality assurance plan—level 3 ipo diagram 60 3.5: review software development plan—level 3 ipo diagram 64 3.6: review configuration management plan—level 3 ipo diagram 69 3.7: what's next? 72 chapter 4 create test plan: levels 2 and 3 ipo diagrams 73 4.1: overview 73

Related Documents:

May 02, 2018 · D. Program Evaluation ͟The organization has provided a description of the framework for how each program will be evaluated. The framework should include all the elements below: ͟The evaluation methods are cost-effective for the organization ͟Quantitative and qualitative data is being collected (at Basics tier, data collection must have begun)

Silat is a combative art of self-defense and survival rooted from Matay archipelago. It was traced at thé early of Langkasuka Kingdom (2nd century CE) till thé reign of Melaka (Malaysia) Sultanate era (13th century). Silat has now evolved to become part of social culture and tradition with thé appearance of a fine physical and spiritual .

On an exceptional basis, Member States may request UNESCO to provide thé candidates with access to thé platform so they can complète thé form by themselves. Thèse requests must be addressed to esd rize unesco. or by 15 A ril 2021 UNESCO will provide thé nomineewith accessto thé platform via their émail address.

̶The leading indicator of employee engagement is based on the quality of the relationship between employee and supervisor Empower your managers! ̶Help them understand the impact on the organization ̶Share important changes, plan options, tasks, and deadlines ̶Provide key messages and talking points ̶Prepare them to answer employee questions

Dr. Sunita Bharatwal** Dr. Pawan Garga*** Abstract Customer satisfaction is derived from thè functionalities and values, a product or Service can provide. The current study aims to segregate thè dimensions of ordine Service quality and gather insights on its impact on web shopping. The trends of purchases have

Bruksanvisning för bilstereo . Bruksanvisning for bilstereo . Instrukcja obsługi samochodowego odtwarzacza stereo . Operating Instructions for Car Stereo . 610-104 . SV . Bruksanvisning i original

Chính Văn.- Còn đức Thế tôn thì tuệ giác cực kỳ trong sạch 8: hiện hành bất nhị 9, đạt đến vô tướng 10, đứng vào chỗ đứng của các đức Thế tôn 11, thể hiện tính bình đẳng của các Ngài, đến chỗ không còn chướng ngại 12, giáo pháp không thể khuynh đảo, tâm thức không bị cản trở, cái được

10 tips och tricks för att lyckas med ert sap-projekt 20 SAPSANYTT 2/2015 De flesta projektledare känner säkert till Cobb’s paradox. Martin Cobb verkade som CIO för sekretariatet för Treasury Board of Canada 1995 då han ställde frågan