This article is organized into the following topics:
- Agile software development 敏捷软件开发
- Agile requirements strategies 敏捷需求策略
- Agile testing strategies 敏捷测试策略
- Project initiation 项目初始
- Development team testing 开发团队测试
- Parallel independent testing 并行独立测试
- Defect management 缺陷管理
- End-of-lifecycle testing 测试生命周期结束
- Who is doing this? 谁来做
- Implications for test practitioners 测试的影响
- Agile quality strategies 敏捷质量策略
- Refactoring 重构
- Non-solo development （非独立开发-大概是指结对编程吧）
- Static code analysis 静态代码分析
- Reviews and inspections 复查和审查
- Short feedback cycles 短的反馈周期
- Standards and guidelines 标准和指南
- Implications for quality practitioners 质量实践的影响
- Why agile testing and quality techniques work 为什么要做敏捷测试和质量技术
- Challenges adopting agile testing and quality techniques 敏捷测试和质量技术的挑战
This section is a brief introduction to agile software development. It is organized into the following sections:
- Defining agile 敏捷定义
- The agile system development lifecycle 敏捷系统开发生命周期
- The traditional system development lifecycle 传统系统开发生命周期
- How agile approaches are different 敏捷方法的不同
- Comparing agile and traditional approaches 比较敏捷和传统的方法
1.1 Defining Agile
One frustration that many people new to agile have is that there is no official definition of agile software development, although many people will point tothevalues andprinciples of theAgile Manifesto. Having said that, mydefinition of disciplined agile software development is:
An iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner by self-organizing teams within an effective governance framework, with "just enough" ceremony that produces high quality software in a cost effective and timely manner which meets the changing needs of its stakeholders.
The criteria that I look for to determine whether a team is taking a disciplined approach to agile development. First, is the team is doing developer regression testing, or better yet taking a test-driven approach to development? Second, are stakeholders active participants in development? Third, is the team producing high-quality, working software on a regular basis? Fourth, is the team is working in a highly collaborative, self-organizing manner within aneffective governance framework? Fifth, are they improving their approach throughout the project?
To truly understand agile testing and quality strategies you must understand how they fit into the overall agile system development lifecycle (SDLC). Figure 1 depicts a high-level view of theagile development lifecycle, showing that agile projects are organized into a series of time-boxes called iterations (in the Scrum methodology they call them "Sprints" and some people refer to them as cycles). Although many people with tell you that the agile lifecycle is iterative this isn't completely true, as you can see it is really serial in the large and iterative in the small. The serial aspect comes from the fact that there are at least three different iteration flavors -- initiation iterations (light green), construction iterations (light blue), and release iterations (blue) -- where the nature of the work that you do varies. The implication is that your approach to testing/validation also varies depending on where you are in the lifecycle. As a result it is important to understand each of the high-level activities depicted by this lifecycle:
去真正的理解敏捷测试和质量策略，你必须理解他们如何融合到整个敏捷软件开发生命周期， Figure 1 描绘了一个敏捷开发生命周期的高级视图，展示了敏捷项目被划分到一系列的迭代时间盒（在SCRUM方法中他们比较作“Sprints” ，有些人把他们叫做循环）。 尽管很多人告诉你敏捷生命周期就是迭代，这是不完全正确的。正如你看到的他们针对是连续的小的迭代。 这连续的迭代来自至少三个不同的迭代类型（风味），初始迭代（亮绿），构造迭代（亮蓝），和发版迭代（蓝）-这是迭代工作的不同。 很显然你的测试和验证方法根据所在的生命周期位置的不同而不同，作为一个结果，去理解生命周期中的每一个高级活动是非常很总要的。
Iteration 0. The goal of this iteration, or iterations on complex projects, is to initiate the project. You will performinitial requirements envisioning, initial architecture envisioning, begin identifying and organizing the development team, come to some sort of stakeholder concurrence as to the goal(s) of the project, and gain funding and support for the project. Testing/validation activities include beginning to set up your testing environment and tools as well as potentially reviewing the initial models, plans, and vision or stakeholders goals document.
迭代0. 这个迭代或复制项目上的迭代的目的是做初始化项目。你将执行执行初始需求，初始架构， ，开始定义和组织开发团队, 。。。。 并且获得资金和支持项目。测试/验证活动活动包括 搭建你的测试环境和准备测试工具，以及可以审查初始模型，计划，和可视的涉众目标文档。
Construction iterations. During each construction iteration (iterations 1 to N inFigure 1) the goal is to produce more potentially shippable software. Agile teams follow theprioritized requirements practice -- each iteration they take the most important requirements remaining from the work item stack (what Scrum teams call a product backlog) and implement them. Agile teams will take a whole team approach where testers are embedded in the development team, working side by side with them to build the system. The focus of their testing efforts are often on confirmatory testing via developer regression testing or better yetTest-Driven Development (TDD).
构造迭代： 通过构造迭代，目标是去生成更潜在可交付的软件。敏捷团队根据需求度优先级 --每个迭代他们把最重要的需求放入工作堆栈中（SCRUM 团队中交一个产品backlog) 并且实现他们。 敏捷团队要执行测试人员嵌入到开发团队中的整体团队方法，并肩工作构建系统。 测试努力的焦点是经常通过开发回归测试来确认测试或者最好执行测试驱动开发（TDD）
Parallel independent testing. Disciplined agile teams perform continuous independent testing in parallel to construction iterations throughout the lifecycle. The goal of this effort is to find defects that got past the development team, often performing higher forms of testing such as exploratory testing, system integration testing, security testing, usability testing, and so on which require significant testing skills, complex testing tools, and often complex pre-production testing environments. There is often a 10:1 to 15:1 ratio between people on the development team and independent testers supporting them. In larger organizations this independent test team typically supports several development teams (thus enabling more sophisticated system integration testing because they can more easily work with versions of multiple systems under development).
并行独立测试。训练有素的敏捷团队贯穿构造迭代生命周期都在中并行执行持续独立的测试。独立测试的目的是找出开发团队提交的缺陷。 经常执行高形式的测试例如，探索测试、系统集成测试、安全测试、可用性测试等等需要很强的测试技术和复杂的测试工具， 并且经常预生成测试环境。 开发团队和支持他们的测试独立测试人员比例大概在10:1 到 15:1. 在大型的组织里独立的测试团队支持几个开发团队（因为他们能够更容易工作在多个系统版本，因此使得更富在的系统集成测试变得可能）
Release iteration(s). The goal of the release iteration(s), the dark blue "R" iteration in Figure 1, is to successfully deploy your system into production. This can be quite complex in practice, including training of end users, support people, and operations people; communication/marketing of the product release; backup and potential restoration (if things go bad); pilot/staged deployment of the system; final translation of the UI anddocumentation; finalization of system and user documentation; and so on. During the release iteration there is still sometesting at the end of the lifecycle to ensure that the system is ready for production.
发布迭代：发布迭代，在Figure1中 蓝色R迭代， 的目标是成果的部署你的系统到生产环境，在实践中相当复杂，他包括终端用户，支持人员和操作人员的培训，沟通和市场的产品发布；备份和回复（如果发布失败）；试点/分期的系统部署，最后的UI和文档的翻译，最后交付的系统和用户的文档 ，等等 。 在发版迭代仍然有些最后的测试要做，这些测试确认系统已经准备好上线。
Figure 1. High-level agile development lifecycle. 敏捷开发生命周期概览
Figure 2 shows a detailed version of the SDLC, fleshing out the details of Figure 1. Figure 2 also adds new phases so as to depict the full end-to-end lifecycle, including "iteration -1" where you identify potential projects, the production phase where you operate and support the system once it has been released, and the retirement phase where you fully remove an unneeded system from production.
Figure2 展示了一个软件开发生命周期的详细版，充实了figure 1， Figure 2 也加了新的阶段"iteration-1" 去描述完整的端到端的生命周期， “iteration-1" 中你识别潜在的项目，
”production phase“ 一旦产品被发布需的要操作和支持。
”retirement phase" 从生产环境中删除不需要的系统
Figure 2. A detailed agile SDLC.
Figure 3 depicts the V Model for software development, basically a sophisticated form of the traditional waterfall model. With the V model the work on the left-hand side of the diagram is validated later in the lifecycle through corresponding activities later in the lifecycle (for example requirements are validated through acceptance testing, the architecture via integration testing, and so on). Although this approach is better than not testing at all, it proves to be very expensive in practice because of several systemic problems:
Figure 3, 描述了软件开发的V模型，基于传统瀑布模式的复杂形势。 V模型的左边是后期验证活动，在活动的晚些时候执行验证活动（例如，需求在验收测试时被验证，架构被集成测试验证，等等），尽管这个方法比根本不测试要好，他提供了比较昂贵的实践。下面是几个系统的问题描述：
Deliver the wrong functionality. The V model promotes an approach where the requirements are defined in detail early in the project. Although this may be good theory (note the use of the word "may") in practice it proves to be a very poor way to work. These "big requirements up front" BRUF approaches result in significant wastage because at best the project team will build something to specification instead of something that the stakeholders actually need.
uild to a fragile design. Similarly, although in theory it may be a good idea to think through the details of the architecture/design up front the reality is that you end up making, and then committing to, technical decisions are too early when you have the least amount of information available to you (during architecture/design phases you're making decisions based on what you hope will work, as opposed to what you know will work based on actual working software).
Hand-offs inject defects. Every time you have a hand off between two groups of people defects due to misunderstandings will be injected into the product. Although this problem can be partly mitigated via reviews, this proves to be expensive compared to more agile approaches such asnon-solo development.
Fixing defects is expensive. The greater the feedback cycle the greater the average cost of fixing a found defect. The V model approach promotes very long feedback cycles.
修改缺陷成本昂贵。 反馈周期越长，平均修复缺陷的成本就越高。 V模型方法提供了一个非常长的反馈周期。
Increased time to value. The V model lengthens the amount of time, through increased bureaucracy and waiting time, it takes to deliver functionality into production. This in turn lowers the opportunity benefits and net present value (NPV) provided by the release.
Figure 3. Serial SDLC/V Model.
Traditional testing professionals who are making the move to agile development may find the following aspects of agile development to be very different than what they are used to:
Greater collaboration. Agile developers work closely together, favoring direct communication over passing documentations back and forth to each other. They recognize that documentation is the least effective manner of communication between people.
Shorter work cycle. The time between specifying a requirement in detail and validating that requirement is now on the order of minutes, not months or years, due to the adoption of test-driven development (TDD) approaches, greater collaboration, and less of a reliance on temporary documentation.
Agilists embrace change. Agile developers choose to treat requirements like a prioritized stack which is allowed to change throughout the lifecycle. A changed requirement is a competitive advantage if you're able to implement it.
Greater flexibility is required of testers. Gone are the days of the development team handing off a "complete specification" which the testers can test again. The requirements evolve throughout the project. Ideally, acceptance-level "story tests" are written before the production code which fulfills them, implying that the tests become detailed requirement specifications.
Greater discipline is required of IT. It's very easy to say that you're going to work closely with your stakeholders, respect their decisions, produce potentially shippable software on a regular basis, and write a single test before writing just enough production code to fulfill that test (and so on) but a lot harder to actually do them. Agile development requires far greater discipline than does traditional development.
Greater accountability is required of stakeholders. One of the implications of adopting the practices active stakeholder participation, prioritized requirements, and producing working software on a regular basis is that stakeholders are now accountable for the decisions that they make.
Greater range of skills are required. It isn't enough to be just a tester, or just a programmer, or just an analyst, or just a ... anymore. Agilists are moving away from the Tayloristic approaches of traditional development which motivate people to become overly specialized and instead are moving towards a highly iterative and collaborative approach which requires generalizing specialists (NOT generalists!).
需要更广的技术面。 仅仅做一个测试人员，一个分析人员 等是不够的，敏捷者不再是传统开发方法中激励人们成为的专才，而是适应高度迭代和协作方法的通才（不是多面手）-大概意思是样样精通的人才。
The agile approach offers many benefits over the traditional V model:
Greater ability to deliver required functionality. Agile teams work closely with their stakeholders, ideally following the practiceactive stakeholder participation. This practice, in combination with an evolutionary approach, results in greater ability of agile teams to understand and then implement the actual needs of their stakeholders. Figure 4 summarizes results from Dr. Dobb's Journal (DDJ)'s 2008 Project Success Survey, showing that agile teams are more effective at delivering required functionality than traditional teams.
交付需求功能的能力:敏捷团队与涉众紧密合作，理想情况下满足涉众的实践活动。这个实践，结合进化方法，敏捷团队更好的理解需求的能力并且实现了涉众们的实际需求。Figure 4 总结了这个结果。展示敏捷团队在交付被需要的功能的能力上比传统团队更有效果。
Greater quality. Figure 4 also shows that agile approaches result in greater quality than traditional approaches, most likely due to increased collaboration within the team and earlier and very often more testing throughout the lifecycle.
很好的质量。Figure 4 也展示了敏捷方法的结果比传统方法有更好的质量。这最可能因为增加团队内部的协作和较早的经常的测试在整个生命周期中。
Improved designs. Agile architecture and agile design strategies are evolutionary in nature, and this, in combination with the greater levels of collaboration exhibited by agile teams, results in better designs when compared to more traditional approaches. Architecture and design are so important to agile teams that they do these activities throughout the lifecycle, not just during early lifecycle phases.
Improved economics. Figure 4 shows that agile teams are providing greater return on investment (ROI) than traditional teams. This is due in part to the shorter feedback cycle of agile approaches which lowers the average cost of addressing defects. Furthermore, because agile teams are working smarter, not harder, they often get the functionality delivered quicker (whichFigure 4 also depicts) thereby providing quicker time to value and thus greater benefit.
改善经济. Figure 4 展示了敏捷团队提供了比传统团队更高的投资回报率，这是由于部分原因敏捷方法的比较短的反馈周期，这降低了定位bug的平局成本。另外，因为敏捷团队工作灵活，而不敬仰，他们经常成功快速的功能交付，因此提供了更快的获得价值和收益。
Figure 4. Success factors by paradigm (Scale is from -10 to +10).
Finally, I just wanted to point out that the results depicted inFigure 4 aren't an anomaly. DDJ's 2008 Agile Adoption Survey also found that people believed that agile teams were producing greater quality than traditional teams, providing better stakeholder satisfaction, and providing greater levels of productivity.
最后，我只想指出Figure 4 描述的结果是正常的， DDJ‘s 2008年敏捷调查，也发现了人们普遍详细敏捷比传统团队生产出更高质量的产品，提供的产品涉众（需求放）更满意，提供更高的生产率。