ThoughtWorks---Open House 2012（测试空间）总结

测试空间活动：参加活动的人员分成四个小组，每个小组由一名thoughtworks员工领队，小组成员，每人手中拿到一份“需求”，小组成员进行讨论对“需求”进行明确，不明确的地方向领队确认，最后形成一份文档交付给客户。活动时间共计5分钟，包括小组成员意见达成统一，文档书写到白板上。

本人不擅长领导别人，所以分成小组后，便无公害的跟在小组成员后面，看手中需求文档，记录不明确的问题，听小组成员讨论，向领队提出自己的问题，向小组成员澄清自己已经确认的问题，待小组得到统一的意见后，无公害的干点打杂小活儿，很快活动时间到，各小组将自己的成果展示在白板上，并依据白板向其他人讲解自己的思路和流程。白板展示的形式各有千秋，有流程图、有伪代码、有表格、有文字说明。待各个小组演讲完毕，组织者提出了几个问题：这份文档是要给谁看的？他们有写代码、看流程图的能力吗？你的客户要学习你的语言吗？答案是客户看不懂这份文档。作为服务方，我们应该学习客户的语言，以客户的思维和专业术语与他们交流。所以，几组都是失败的。组织者继续讲到，文档有文字描述，便会存在有歧义和不明确的地方，用文字说不清楚的，尽量用数据来说话，一目了然。

组织者建议大家重新讨论并修改自己的方案，但是很多人没有了刚才的新鲜感，有些人收拾东西去看其他小组活动，有些人坐下来与组织者辩论自己的设计怎样怎样，组织者的方案怎样怎样。见自己的小组没人再继续做下去，只是在和组织者辩论自己的观点（组织者开始误导了我们；这些事情应该是需求分析人员来做的，与测试人员无关；这样做法会增加开发人员的工作量等等）便自己坐下来，按照组织者的思路重新思考重新设计方案，并在纸上画出草图。趁着组织者有空档的时候拿出自己的方案给组织者看，并讲解了自己的思路，组织者指出自己方案中的不足（谢谢组织者美女的耐心解答^_^）。

在组织者与其他人员讨论的过程中，组织者说设计这份文档其实只是一个小小的开始，并不是整个活动的重心，活动的重心是测试用例即是需求，整理的这样一份文档，即可以给客户看，也可以给开发用，同样也是一份测试用例，文档是一份，没有歧义，开发人员可以基于这样的数据进行开发，在开发的过程中可以以这份数据为测试数据来验证自己代码，还可检测代码覆盖问题，测试用例已经可以测试通过，由于某人提交新代码导致测试用例失败，便可很快找到问题产生的原因。测试人员可以拿这份文档编写自动化测试用例进行测试，产品提交后，客户同样以这份文档为依据进行验收。组织者在说的过程中并向我们展示了他们在工作中以这种方式写的测试用例，及测试执行结果。很可惜，活动只进行了一个开始。

活动中“需求”文档大概内容：（在活动上他们已经拿出来让大家参与讨论了，我写出来他们应该不会介意的吧^_^）

年底某公司发放福利，员工可以自己购置商品报销，除了电脑、手机、书籍以外，其他商品都会征收10%的基本税，国外购置商品都要征收5%的附加税

当员工去报销的时候，需要提供一个清单，上面列着所买的所有商品的名称和价钱（含税），在最底下需要列出所购商品的税的总和和总价。
税的进位规则是：如果税率是n%，产品的标价是P，那产品需要交的税是np/100，np/100要向上凑够最近的0.05（up to the nearest 0.05）
目标：
对需求做详细的分析，给出说和总价的计算规则

不明确的问题：

1.国外商品增收5%附加税，是否是指在同类国内商品基本税的基础上增加5%？

答：是的，若国内商品税率10%的，则国外同类商品的税率为（10+5）%=15%；国内商品税率为0，则国外同类商品税率为（0+5）%=5%。

2.设计的表格中总价是否包含税？

答：是的

3.税金向最接近的0.05补齐是什么意思？

答：举例来说，如果计算得出的税金为0.01，则表单中填写的税金为0.05，若计算得出的税金为0.06， 则表单中填写的税金为0.1.

4.若同件商品，同时购买多件，计算规则是什么？

答：先计算一件商品的税金和总价，再乘以n（商品的数量）

5.若同时购买多件不同的商品，商品税率相同，是否可将商品标价加和，以求得的标价和乘以税率来求得税金及总价？

答：不可以，必须计算单件商品的税金和总价，最后求和。

6.可否分别算出各个商品的税金，将税金求和后再进行向最接近的0.05凑近，最后将总税金与总标价加和，求得总价？

答：不可以，必须分别计算单件商品的税金和价钱，最后求和。

设计的文档内容：

一、商品类别及其对应的税率

二、税金进位规则：向最接近的0.05凑齐

三、商品总价及总税金计算规则，分别求得单件商品价格及税金后加和

四、最终表格

最后总结：

多做就等于少做（貌似每次我说这句话的时候，对方都是撇撇嘴，不认同）。在公司里听到太多这样的话”这不关我的事，这应该是XXX来做的，他们就是看不起测试的“。如果认为测试就是等着开发的开发完代码提交后来进行验证，那就把自己定位在”验证“这个角色上，这样的验证，是验证不出有价值的BUG的，这样的BUG只不过是人的失误引进来的，并不是根儿上的BUG，这样的定位就等于是把自己圈死了。只有知道了是什么原因要这样，才会知道为什么要这样而不是那样。