The notes of How We Test Software At Microsoft(2)

Estimating Test Time

正如书中提到，我周围大多team估算项目的时间都是“simply add a few weeks of “buffer” or “stabilization” time at the end of a product cycle”。这是非常不科学的做法。

也提到一种“copy  the development time”的做法，让我想到曾经看过的两篇关于开发和测试人员比例的文章，http://blog.youkuaiyun.com/Lynn_yan/archive/2009/09/15/4554687.aspx和http://blog.youkuaiyun.com/Lynn_yan/archive/2009/09/15/4554687.aspx。

Starting with Testing-Ask Questions

If requirement aren’t available (or if they aren’t good), the best place to start test design is probably by asking questions. Ask how the software is supposed to work. Ask how it handles data. Ask how it handles errors. Asking questions about the software can help testers get a jumpstart on design before any of the code is ever written.

当缺少文档，提出问题并尝试回答问题，一个问题的答案可能又能引出更多的问题，通过问题去熟悉产品，也可以向开发人员，熟悉产品的测试人员以及其他项目相关人员询问你关于产品的疑惑。另外就是做Exploratory testing， exploratory testing强调的是测试设计和测试执行的“同时”性－这个“同时”是相对于传统软件测试过程中严格的“先设计，后执行”来说的，测试人员可以通过测试来不断学习被测试系统，探索性测试的重点就是创造。

Have a Test Strategy

测试策略包括测试类型，过程，测试方法，以及对代测试产品的风险分析，哪里更容易出错，哪里需要做更多的测试。

Thinking About Testability

Testability是定义一个软件是否能被完全有效测试的程度(Testability is the degree to which software can be tested completely and efficiently.) ，简单的说就是测试的难易程度(How easy is it to Test?)。在需求和设计的review会议上，测试人员要提出问题“我们怎么样去测试”，这样能开发团队成员去更多考虑软件的可测试性。

一个增减软件可测试性的模型：SOCK（首字母缩写词）：

1.       Simple:简单的模块和程序更容易测试

2.       Observable：内部结构可见性好

3.       Control：如果一个程序设有临界值，设置或重置这些临界值可以让测试更容易

4.       Knowledge：需求，help文档能给测试人员提供更多信息

Test Design Specifications

Test Design Specifications一般包含以下项目：

·         Overview/goals/purpose

·         Strategy

·         Functionality testing

·         Component testing

·         Integration/system testing

·         Interoperability testing

·         Compliance/conformance testing

·         Internationalization and globalization

·         Performance testing

·         Security testing

·         Setup/deployment testing

·         Dependencies

·         Metrics

Testing the Good and the Bad

Verification tests are necessary to prove that the application works as intended, but the falsification tests are perhaps even more important. Applications need to be robust and handle bad data without error.

The happy path should always pass, 在这个前提下，要尽可能多的考虑一些异常情况