目前的阶段开发、测试都在思考一些准备性的工作。道雨兄一直对于可测性需求关注度比较高，之前和他在一个组里进行培训时，已经多次在不同场合提到这个话题，可以感受到他的疑惑。

　　因此在当下思考测试策略的时候再次浮出水面也就不足为奇了。

　　当客户需求将开发日程表排到溢出的时候，突然冒出来的可测性需求宛如寂静的会场上大笑数声，让大家都有些尴尬。排了也痛，不排也痛，被砍的可能性还挺大。这是现状。

　　出现这样的反应首先要解决一个问题，测试和开发的关系到底应该怎样定位？

　　讨论过程中提到一个模式就是现实版存在构造一个与开发对立的测试部，达到在质量上充分发挥监督审查的效果。开发与测试吃同一个绩效饼，对方吃多了自己就吃少了，所以二者相互较劲。

　　那么在这个问题上，“可测性需求”必然沦为牺牲品，可以说是零和游戏，双输。

　　“就算站在世界顶端，如果没有人陪伴，又怎样？”

　　在敏捷的实践要求上，测试开发要混在同一个Team中，随着产品的生长一起完成每个迭代。

　　当所有迭代完毕，一个瓜熟蒂落的产品就可以交付客户了。(理论上是这样，但是我估计最后应该还是要追加一轮转测试，才会是比较放心些的，算是吃之前洗下苹果吧)。这个流程和我们的传统理念上有质的差异。

　　差异点就是测试是开发工作的一部分，是迭代中若干角色的一种，枚举比较能够表示出这个关系的平等性。

　　typedef enum

　　{

　　Developer,

　　Tester,

　　Analyzer,

　　} RoleOfIteration;

　　Tester这个角色在迭代中完成“开发阶段的测试工作”，是保证我们“制作”的产品符合质量要求的“必须”的工序，是“必须”的。不是可选的。这部分工作目前是测试部在承担。而“洗苹果”是“测试阶段的测试工作”，是用来站在客户的角度来“确认”我们提供的产品确实没有问题。仅仅是确认一下，因为我们的要求高。是可选的。如果我们种苹果没有打农药施化肥，摘下来苹果不洗就应该可以吃。

　　将这两个作用清晰后，Tester的定位就明确了。“必须的”，Must，“我们一个Team的”。

　　在这个前提下，整个迭代Team需要为Tester开展当轮迭代工作分配资源，当轮的可测性需求就是其中之一。在整个Team的范围内可以分配资源去完成“可测性需求”，也可以不完成。这是Team对自己行为的成本收益的判断后做出的决定。是否会因此产生“技术高利贷”也由当事人自己承担。这里需要提及的是没有可以一刀切的必杀技，不同的可测性需求成本的差异非常大。

　　基于这个理念，再次回到测试策略的制定问题上来。由于每轮迭代的Story不同，对应的策略有可能会不同：也许手工就够了，也许需要开发个可测性“后门”才能自动化，或者直接用现成工具就可以制作测试套。这样在迭代0之前就仅仅能够制定一些粗略的测试策略。细化的必须在每轮迭代中才能完成。

　　在ThoughtWorks中，测试的工作大部分用自动化来解决。Tester的工作更象我们这里的解决方案测试，最终洗一下苹果，所以规模上没有那么大。我们的组织结构是否适应模式的变化，需要更多人的体验才能感知。

　　还有很多内容，有点收不住，太晚了，今天先写这些。