当前位置:首页 >> 工学 >> Agile Testing

Agile Testing


Agile Testing
Elisabeth Hendrickson Quality Tree Software, Inc. www.qualitytree.com

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

1

Poll: How Agile Is Your Testing Now?
How many of you… Would call your test practices “Agile”? Participate in defining the acceptance criteria? Routinely test incomplete software to provide feedback to your stakeholders sooner? Have adopted a lightweight documentation style? Have found that your test artifacts are relatively easy to update even when there are radical changes to the code? Have access to the source code and to the same set of tools as the programmers? Have ensured the programmers have full access to all the artifacts and tools you use? Are co-located with the project team?
Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

2

What’s “Agile?” Agile is more than a buzzword. It is a relentless focus on providing business value, usually by adopting one or more Agile methodologies such as Scrum or XP.
– See the Agile Manifesto: http://www.agilemanifesto.org – And the Agile Alliance: http://www.agilealliance.org

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

3

Examples of Agile Methodologies
Lean Lean manufacturing concepts applied to software development. Crystal Lightweight set of development practices. Scrum Lightweight management framework.

Extreme Programming (XP) Rigorous set of practices designed to keep both the code and team agile.
4

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

Agile Synthesized
? Communication and collaboration ? Visible indicators ? Disciplined development practices ? ? ? ? Feedback Whole team thinking Short iterations Low overhead, high productivity

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

5

Calling It “Agile” Doesn’t Make It So
This is NOT Agile:

1. Compress the schedule 2. Toss out the documentation 3. Code up to the last minute
The organization may gain short term speed but at the cost of long term pain.

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

6

How Traditional Test Practices Evolved With great optimism and the best of intentions, The Project Plan is announced:
Analyze Design Code Test/Bug Fix

Requirements handed off to Dev

Completed Code handed off to Test

Release

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

7

How Traditional Test Practices Evolved

Inevitably, The Project Plan is revised:
Analyze, Design, & Code Test/Bug Fix

Completed Code handed off to Test

Release

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

8

The Result: Practices Intended to Control Chaos
Traditional test practices attempt to manage the chaos (or at least avoid the blame): ? “Last Defender of Quality” stance ? Strict change management ? Detailed preparation and up front planning ? Heavyweight documentation suitable for outsourcing the test effort ? Strict entrance and exit criteria with signoffs ? Heavyweight test automation focused on regression

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

9

Becoming Agile: Shifting Roles
“Fear not! I’ll protect you!”

from last line of defense…
Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

“Hey, would this help?

…to team support
10

Testing Directions: Marick’s Model
Business Facing Support Programming Critique Product

Technology Facing Source: http://www.testing.com/cgi-bin/blog/2003/08/21#agile-testing-project-1
Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

11

Traditional & Agile Testing Contrasted
Traditional Testing Change Planning Documentation Handoffs Automation Manage & control it. Comprehensive up front test design. Verbose. Formal entrance and exit criteria with signoffs. System-level, built by tool specialists, created after the code is “done.” Agile Testing Accept it. Plan as you go. Only as much as absolutely necessary. It’s not a relay race. Collaborate. All levels, built by anyone, an integral part of the project.

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

12

Embrace Change: Plan Tests for Maintainability
Change

When creating test artifacts… ? Minimize duplication. Thought exercise: if a feature were removed from your software, how many test artifacts would have to be updated? ? Use tools designed for change. Hint: if the vendor says “stabilize the interface first,” run away!
Planning Handoffs

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

Automation

Documentation

13

How Not to Plan a Test Effort
Change

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

Automation

Handoffs

Unfortunately, this is common practice: ? Download a generic, standard, formal test plan template from the Internet. ? Fill in every section in the template even if you don’t understand it and have to make stuff up. ? Kill the maximum possible number of trees by distributing copies to every team member. The result is a large and mostly irrelevant plan that must now be maintained. Yuck.

Documentation

Planning

14

Plan as Little as Possible
A little planning is good. More is not better. ? Know who you serve (primarily). Technology-facing or business-facing? ? Plan for the current iteration. Speculative planning means rework. ? Have a strategy that fits on one page. If it is still relevant in 6 months, it’s probably at the right level of detail. ? Keep an up-to-date, prioritized risks list. What kind of information are the testers looking for? The risks list covers it.
Change Documentation Automation

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

Handoffs

Planning

15

Favor Informal, Collaborative Tools
Change

Documentation

Planning

Informal

Whiteboards Sticky Notes Index Cards Wikis Databases Gantt/PERT Charts Polished Documents

Formal
Handoffs

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

Automation

16

Monitor Documentation Costs
Change
How Much Time Are We Spending on Test Documentation?
40 35 30 25 20 15 10 5 0 0 10 20 30 40 50 % Time 60 70 80 90 100

Planning

Documentation

Handoffs

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

Automation

How Much Does Documentation Cost? Informal polling of 162 software testers from 65 companies revealed that most spend more than 33% of their time documenting tests.

# Testers Reporting

17

Keep the Documentation Simple
Change

Planning

? Capture the essence, not the details. Step-by-step instructions cost time without providing value (usually). ? Point to other project documents. If it’s in the user guide, requirements, specs, etc., leave it there. ? Centralize generic tests in a checklist. Try this: count the number of times you find a common condition, like invalid dates or null strings, in the test docs. More than once is too many.
18

Documentation Automation

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

Handoffs

Watch Verbose Wording
Change

Which would you rather maintain? Choose the Import option from the File menu. A dialog titled “Import File” appears. Navigate to \\x\y\z\long.dat and click Open. A dialog titled “Importing…” appears with the current status, a progress bar, and a button labeled “Cancel.” Click on the Cancel button. Choose OK on the confirmation dialog. Verify that the import stops. Or: Start a long import. Cancel it in the middle. Verify it stops.
19

Documentation Automation

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

Handoffs

Planning

A Lightweight Example
Change Documentation Automation

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

Handoffs

Planning

20

Do Away with the Signoff Sheet
Change

Documentation

Hint: when people joke about signing the handoff form in blood, the signoff process is more about blame than about producing good software.

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

Automation

Handoffs

Planning

21

Integrate Testing
Testing is not a phase. It’s a way of life. ? Agile teams are test infected. The question, “How will we test it?” is as important as “How will we build it?” ? Co-locate testers and programmers. But sitting side by side does not ensure communication. ? Track testing status and programming status all together. Show tests run-passed-failed together with features/stories done and left to do.
Change Documentation Automation

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

Handoffs

Planning

22

Leverage Automation Investments
Automate everything you can, but invest wisely. ? Collaborate with programmers on test infrastructure code. The programmers have already automated the unit tests. Why not reuse the investment where possible? ? Use different types of automated tests for different purposes. Automated system tests should cover end-to-end sequences. Unit tests detect unintended change. Don’t substitute one for the other.
Change Documentation Automation

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

Handoffs

Planning

23

Automation & Exploratory Testing
Change

Use test automation to support early exploratory testing.
Planning

Documentation

Traditional test wisdom says we can’t start testing a feature until it’s accessible from an external interface (like a GUI). But we don’t have to wait. Test automation can facilitate manual exploration.

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

Automation

Handoffs

24

Agile Testing Synthesized
? Communication and collaboration ? Whole team thinking ? Low overhead, high productivity ? Early involvement ? Leveraged automation ? Focus on providing rapid feedback to key stakeholders

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

25

Necessary Conditions for Agile Testing
1. The organization is willing to embrace agility as defined by the Agile Manifesto. Saying “Be More Agile” or “Test Faster” isn’t enough. The whole team is responsible for quality, not just the testers or people with “Quality” in their title. Which are you more likely to hear: “How did you miss that bug?!?” or “How did we not catch that?” Everyone tests, not just designated testers. Agile teams are “test infected.” Managers focus on fixing problems, not blame. Agile practices don’t provide CYA paper trails and are unlikely to succeed in a high-blame, high-fear environment.
26

2.

3. 4.

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

Agile Testers Wanted: A Job Description
Responsibilities: ? Perform manual/exploratory tests on early-stage code ? Create automated acceptance tests ? Advise the team about overall risks and trends ? Assist the business stakeholders define acceptance criteria ? Facilitate communication between the technical & business stakeholders Qualifications: ? Experience designing and executing tests ? Scripting skills in at least one of the following languages: Ruby, Perl, Python, or JavaScript. Experience programming in Java, C#, etc. a plus. ? Strong analysis skills ? Ability to work in a team (bullpen) environment
Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

27

Test Teams that Embrace Agility…
? Focus on providing value to our key stakeholders (both business-facing and technology-facing) ? Shift from being the last line of defense to providing an information service. ? Aggressively reduce time and resources spent on anything that does not directly contribute to providing information. ? Collaborate with programmers to improve testability and leverage test automation efforts.

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

28

Further Reading… Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley. Cockburn, A. (2004). Crystal Clear: A HumanPowered Methodology for Small Teams. AddisonWesley. Crispin, L., & House, T. (2002). Testing Extreme Programming. Addison-Wesley. Poppendieck, M. & Poppendieck, T. (2003). Lean Software Development. Addison-Wesley. Schwaber, K. & Beedle, M. (2001). Agile Software Development with SCRUM. Prentice Hall.
Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

29

Acknowledgements Many thanks to early reviewers of the ideas presented here: Brian Marick, William Wake, Jonathan Kohl, Jeffrey Fredrick, Daniel Knierim, Marc Kellogg, Danny Faught, Ron Jeffries, Hubert Smits, Rob Mee, Sherry Erskine, Amy Jo Esser, Gunjan Doshi, Dave Liebreich, Janet Gregory, Chris McMahon

Copyright (c) 2004 - 2005, Quality Tree Software, Inc.

30


赞助商链接
更多相关文档:

基于FPGA的模拟信号源设计(中英文翻译)

In testing frequency-agile radios, finding a signal generator able to keep up with the desired frequency-hopping pattern on instrument with a very fast ...

软件测试英语术语+缩写

(informal review) :非正式评审 Ad hoc testing:随机测试 Adaptability:自适应性 Agile testing:敏捷测试 Algorithm test (branch testing) :分支测试 Alpha testing...

software testing常用术语

software testing常用术语_IT/计算机_专业资料。软件测试术语一(A-C) 软件测试术语一( )前言 此术语表为国际软件测试认证委员会(ISTQB)发布的标准术语表。此表...

Test Jumpers

Test Jumpers - Test Jumpers: One Vision of Agile Testing 空降测试员:敏捷测试的愿景 Posted on January 16, 2014...

软件测试术语表

Ad hoc testing:随机测试 ? Adaptability:自适应性 ? Agile testing:敏捷测试 ? Algorithm test (branch testing) :分支测试 ? Alpha testing:alpha 测试 ? ...

Agile on a Global Scale

joined with a team of academic researchers from the United States, India, and Senegal who put a truly distributed agile development team to the test. ...

SoftwareEngineer

Analysis A) Design B) Coding C) Testing D) both a and b E) Section 3.5.8 14 CORRECT Agile Unified Process uses the classic UP phased activities (...

Modeling the proces and Agile

Modeling the proces and Agile_计算机软件及应用_IT/计算机_专业资料。Chapter...testing activities are related to analysis and design(German Ministry of ...

The Difference between CMMI and Agile

The Difference between CMMI and Agile_其它_高等教育_教育专区。简单分析cmmi和...requirements analysis, design, coding, unit testing, and acceptance testing. ...

敏捷开发中的敏捷测试《敏捷测试全攻略》

25 2 敏捷开发中的软件测试参考: Bret Pettichord 的《Agile Testing - What is it? Can it work?》《Agile Testing Challenges》 和 敏捷宣言: 个体和交互比...

更多相关标签:
网站地图

文档资料共享网 nexoncn.com copyright ©right 2010-2020。
文档资料共享网内容来自网络,如有侵犯请联系客服。email:zhit325@126.com