实例化需求 团队如何交付正确的软件_英文版

所需积分/C币:10 2019-03-30 18:34:46 17.58MB PDF
18
收藏 收藏
举报

介绍了这些团队如何在很短的周期内说明需求、开发软件,并交付正确的、无缺陷的产品;为团队在实施实例化需求说明时使用的模式、想法和工件创建了一致的语言;展示了案例中的团队用来实现实例化需求说明原则的关键性实践;并在案例分析部分展示了一些团队实施实例化需求说明的历程。
SPECIFICATION BY EXAMPLE How successtul teams deliver the right software Gojko Adzic MANNING Shelter island For online information and ordering of this and other Manning books, please visit www.manning.com.Thepublisheroffersdiscountsonthisbookwhenorderedinquantit For more information, pl please contact: pecial Sales Department Manning Publications Co 20 Baldwin road PO Box 261 Shelter Island NY11964 Emailorders@manning.com o2011 by Manning Publications Co. All rights reserved No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without the use of elemental chlorine Manning Publications Co Development Editor: Jeff Bleiel 20 Baldwin road Copyeditors: June Eding, Linda recktenwald PO Box 261 Illustrator: Martin mustonen Shelter Island, NY11964 Designer: Leslie haimes ISBN9781617290084 Printed in the United States of america 12345678910-MAL-161514131211 Contents Contents v Preface xiii Acknowledgments Xxii About the author About the cover illustration xxiv PART Getting Started Key benefits 3 Implementing changes more efficiently 6 Higher product quality Less rework 12 Better work alignment Remember Key process patterns 17 Deriving scope from goals 19 Specifying collaboratively 19 Illustrating using examples Refining the specification Automating validation without changing specifici Validating frequently Evolving a documentation system A practical example Business goal An example of a good business goal Scope User stories for a basic loyalty syster Key examples Key Examples: Free delivery Specification with examples 26 Free delivery 26 Examples 26 Executable specification 27 Living documentation Remember 28 Living documentation 29 Why we need authoritative documentation Tests can be good documentation Creating documentation from executable specifications Benefits of the documentation- centric model Remember 35 Initiating the changes 36 How to begin changing the process 37 Implement Specification by Example as part of a wider process change When: On greenfield projects Focus on improving quality Start with functional test automation 383 When: Appying to an existing project Introduce a tool for executable specifications When Testers own test automation .41 Use test-driven development as a stepping stone When: Developers have a good understanding of TDD How to begin changing the team culture Avoid"agile"terminology When: Working in an environment thats resistant to change Ensure you have management support Sell Specification by Example as a better way to do acceptance testing 45 Don't make test automation the end goal Don't focus on a tool Keep one person on legacy scripts during migration 47 When Introducing functional automation to legacy systems Track who is running-and not running-automated checks When: Developers are reluctant to participat 49 How teams integrated collaboration into flows and iterations 49 Global talent management team at ultimate software .51 Sierra team at BNP paribas 52 Sky Network services Dealing with sign-off and traceability Keep executable specifications in a version control system Get sign-off on exported living documentation When: Signing off iteration by iteration Get sign-off on scope, not specifications When: Signing off longer milestones .57 Get sign-off on "slimmed down use cases When: Regulatory sign-off requires details Introduce use case realizations When: All details are required for sign-off Warning sigl Watch out for tests that change frequently Watch out for boomeran Watch out for organizational misalignment Watch out for just-in-case code Watch out for shotgun surgery 62 Remember Part 2 Key process patterns Deriving scope from goals 65 Building the right scope 67 Understand the "why"and"who 68 Understand where the value is coming from ...69 Understand what outputs the business users expect 70 Have developers provide the"I want part of user stories When: Business users trust the development team ..71 Collaborating on scope without high-level control 72 Ask how something would be useful 73 Ask for an alternative solution 73 Don't look only at the lowest level 74 Make sure teams deliver complete features When: Large multisite projects 75 Further information 75 Remember 76 Specifying collaboratively 77 Why do we need to collaborate on specifications? The most popular collaborative models 79 Try big, all-team workshops When: Starting out with specification by example 79 Try smaller workshops(“ Three amigos”) When: Domain requires frequent clarification Pair-writing When: Mature products 83 Have developers frequently review tests before an iteration When: Analysts writing tests Try informal conversations When: Business stakeholders are readily available Preparing for collaborati Hold introductory meeting When: Project has many stakeholders Involve stakeholder Undertake detailed preparation and review up front When Remote stakeholders Have team members review stories early When: Analysts/domain experts are a bottleneck Prepare only initial examples When: Stakeholders are readily available Don't hinder discussion by overpreparing Choosing a collaboration model Rememb lustrating using examples 95 Illustrating using examples: an example Examples should be precise Don't have yes/no answers in your examples When: The underlying concept isn't separately defined .99 Avoid using abstract classes of equivalence When: You can specify a concrete example .100 Examples should be complete 100 Experiment with data 101 Ask for an alternative way to check the functionality When: Complex/legacy infrastructures Examples should be realistic 102 Avoid making up your own data When: Data-driven projects 102 Get basic examples directly from customers When: Working with enterprise customers Examples should be easy to understand 105 Avoid the temptation to explore every combinatorial possibility Look for implied concepts 106 Illustrating nonfunctional requirements 107 Get precise performance requirements When: Performance is a key feature 08 Use low-fi prototypes for UI 109 Try the QUPER model When: Sliding scale requirements 110 Use a checklist for discussions When: Cross-cutting concerns 111 Build a reference example When: Requirements are impossible to quantify ..112 Remember 113 Refining the specification 114 An example of a good specification 116 Free delivery 16 EXamples 116 An example of a bad specification 117 What to focus on when refining specifications 119 Examples should be precise and testable 119 Scripts are not specifications 119 Don't create flow-like descriptions 120 Specifications should be about business functionality, not software design 121 Avoid writing specifications that are tightly coupled with code 121 Resist the temptation to work around technical difficulties in specifications When: Working on a legacy system 122 Don't get trapped in user interface details When: Web projects Specifications should be self-explanatory Use a descriptive title and explain the goal using a short paragraph Show and keep quiet When: Someone is working on specifications alone In order to: Check whether a specification is self-explanatory .125 Dont overspecify examples 126 Start with basic examples then expand through exploring When: Describing rules with many parameter combinations .128 Use " Given-When-Then"language in specifications In order to Make the test easier to understand 128 Don't explicitly set up all the dependencies in the specification When: Dealing with complex dependencies/referential integrity Apply defaults in the automation layer Don't always rely on defaults When: Working with objects with many attributes 13 Specifications should be in domain language.......... 132 Refining in practice 132 Remember 135 Automating validation without changing specifications 136 Is automation required at all? 137 Starting with automation To learn about tools, try a simple project first When: Working on a legacy system Plan for automation upfront Don' t postpone or delegate automation 141 Avoid automating existing manual test scripts 142 Gain trust with user interface tests When: Team members are skeptical about executable specifications Managing the automation layer 144 Dont treat automation code as second-grade code Describe validation proo in the automation layer 146 Don' t replicate business logic in the test automation layer 147 Automate along system boundaries When Complex integrations 148 Don't check business logic through the user interface 49 Automate below the skin of the applicati When: Checking session and workflow constraints Automating user interfaces Specify user interface functionality at a higher level of abstraction 153 Check only UI functionality with UI specifications When: User interface contains complex logic Avoid recorded ul tests Set up context in a database 157 Test data management ......157 Avoid using prepopulated data When: Specifying logic that's not data dr 158 Try using prepopulated refer hen: Data-driven systems .158 Pull prototypes from the database When: Legacy data-driven systems Remember 161 1 Validating frequently 162 Reducing unreliability .....164 nd the most annoying thing fix it, and repeat When: Working on a system with bad automated test support dentify unstable tests using Cl test histor When: Retrofitting automated testing into a legacy system Set up a dedicated continuous validation environment 166 Employ fully automated deployme 166 Create simpler test doubles for external systems When: Working with external reference data sources ..167 Selectively isolate external systems When: External systems participate in work 168 Try multistage validation When: Large/multisite groups 168 Execute tests in transactions When: Executable specifications modify reference data 169 Run quick checks for reference data When: Data-driven systems 170 Wait for events, not for elapsed time 170 Make asynchronous processing optional When: Greenfield projects 171 Dont use executable specifications as end-to-end validations When: Brownfield projects 172 Getting feed back faster 173 When: Working with temporal constraints Break long test packs into smaller modules Avoid using in-memory databases for testing When: Data-driven systems 174 Separate quick and slow tests When a small number of tests take most of the time to execute 175 eep overnight packs stable When: Slow tests run only overnight 176 Create a current iteration pack 177 Parallelize test run When: You can get more than one test environment 177 disabling less risky tests When: Test feedback is very sl 178 Managing faili 179 Create a known regression failures pack Automatically check which tests are turned off When: Failing tests are disabled, not moved to a separate pack Remember

...展开详情
试读 127P 实例化需求  团队如何交付正确的软件_英文版
立即下载 低至0.43元/次 身份认证VIP会员低至7折
一个资源只可评论一次,评论内容不能少于5个字
您会向同学/朋友/同事推荐我们的CSDN下载吗?
谢谢参与!您的真实评价是我们改进的动力~
关注 私信
上传资源赚钱or赚积分
最新推荐
实例化需求 团队如何交付正确的软件_英文版 10积分/C币 立即下载
1/127
实例化需求  团队如何交付正确的软件_英文版第1页
实例化需求  团队如何交付正确的软件_英文版第2页
实例化需求  团队如何交付正确的软件_英文版第3页
实例化需求  团队如何交付正确的软件_英文版第4页
实例化需求  团队如何交付正确的软件_英文版第5页
实例化需求  团队如何交付正确的软件_英文版第6页
实例化需求  团队如何交付正确的软件_英文版第7页
实例化需求  团队如何交付正确的软件_英文版第8页
实例化需求  团队如何交付正确的软件_英文版第9页
实例化需求  团队如何交付正确的软件_英文版第10页
实例化需求  团队如何交付正确的软件_英文版第11页
实例化需求  团队如何交付正确的软件_英文版第12页
实例化需求  团队如何交付正确的软件_英文版第13页
实例化需求  团队如何交付正确的软件_英文版第14页
实例化需求  团队如何交付正确的软件_英文版第15页
实例化需求  团队如何交付正确的软件_英文版第16页
实例化需求  团队如何交付正确的软件_英文版第17页
实例化需求  团队如何交付正确的软件_英文版第18页
实例化需求  团队如何交付正确的软件_英文版第19页
实例化需求  团队如何交付正确的软件_英文版第20页

试读结束, 可继续阅读

10积分/C币 立即下载