使用Mind Map写Test Case

在之前的项目中，Acceptance Criteria （AC）的描述会存放在Jira Description中；在当前项目中，除了在Jira中描述AC外，我们会使用Mind Map来写AC，以便形成测试用例Test Case，并标注测试结果和注测试代码覆盖，用着效果不错。

具体格式可以参考这里。

Mind Map中的AC虽然没有严格按照标准方式书写Given When Then，但实际上通过每个节点的上下文，我们就能了解到相应的这几方面的内容。

我觉得这种方式写Test Case的优势在于：

1. 有层次，一目了然
2. 也看得出AC的关联
3. 能知道哪些有测试实现
4. 能看得到测试结果
5. 任何角色都能看到MindMap，也都能了解相应的Story的状态。

对于Mind Map的书写和分类，目前我们是按照相对独立的Feature来分文件，Page-Feature-StoryID,方便找到需要的Mind Map。对于以后功能和页面过多的时候怎么分类（页面过多文件过多，功能多了后也必然会有不同页面的Feature的关联），还在思考中，逐步变化吧。

之前是每次修改后就上传到一个地方，要么重命名要么覆盖，后来就建议使用Svn之类的工具来进行版本管理以便于追踪修改。

与之对应，我们目前的工作流程是：

1. BA确定需求后会写出Mind Map的初稿；
2. QA和BA一起Review并得到最后的AC；
3. Kick Off Story时会按照Mind Map来过一遍
4. 在Developer进行开发的时候，会将已实现单元测试的方法名加在对应的AC之后并加上单元测试覆盖的图标；
5. QA能看到哪些AC被测试覆盖了，并着重未覆盖的AC也着重探索性，测试完成后会在对应的AC加上勾或者叉来标注结果。

有欠缺的地方有：

1. 多了一次对Story的描述，最开始是当做Story的补充，因此Mind Map能否及时根据Story更新也成了要关注的问题；
2. Mind Map是文档但不是可执行的文档。