Context Driven Testing

2006年07月11日 01:44:00

SpiderMan From：http://blog.csdn.net/testwin

敏捷方法的发展，打破了传统的瀑布开发模型，改变了整个软件开发过程中的角色和定位。由于在敏捷开发运动的初期，主要依靠开发人员来进行推动。很多测试人员不了解敏捷方法，仍然习惯了按照传统的瀑布模式进行软件测试，即按照V模型所指导的步骤进行测试，保证软件与需求、设计的相符合，但这样很容易形成了一种测试思维的定势。当"用户需求不明确"、"需求变化较快"时，沿用传统测试方法的测试人员将变的无所适从。

实际上，在敏捷世界里，测试人员始终一直在关注并推动着敏捷方法的发展。在测试圈内，有好几位人士有相当一段时间一直在质疑这种主流的测试思维。这导致了一个称之为 context driven testing 的群体形成了。 对这个概念的最好的论述是 "Lessons Learned in Software Testing这本书。 这个圈子在Web上也很活跃，可以去看看这几位的网站， Brian Marick， Brett Pettichord， James Bach，和 Cem Kaner 。

The Seven Basic Principles of the Context-Driven School

1. The value of any practice depends on its context.

2. There are good practices in context, but there are no best practices.

3. People, working together, are the most important part of any project's context.

4. Projects unfold over time in ways that are often not predictable.

5. The product is a solution. If the problem isn't solved, the product doesn't work.

6. Good software testing is a challenging intellectual process.

7. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.

Illustrations of the Principles in Action:

	Testing groups exist to provide testing-related services. They do not run the development project; they serve the project.
	Testing is done on behalf of stakeholders in the service of developing, qualifying, debugging, investigating, or selling a product. Entirely different testing strategies could be appropriate for these different objectives.
	It is entirely proper for different test groups to have different missions. A core practice in the service of one mission might be irrelevant or counter-productive in the service of another.
	Metrics that are not valid are dangerous.
	The essential value of any test case lies in its ability to provide information (i.e. to reduce uncertainty).
	All oracles are fallible. Even if the product appears to pass your test, it might well have failed it in ways that you (or the automated test program) were not monitoring.
	Automated testing is not automatic manual testing: it's nonsensical to talk about automated tests as if they were automated human testing.
	Different types of defects will be revealed by different types of tests--tests should become more challenging or should focus on different risks as the program becomes more stable.
	Test artifacts are worthwhile to the degree that they satisfy their stakeholders' relevant requirements.

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=902420