testcase设计过程对产品质量的前向保障
2015-05-02 00:45
253 查看
我们都知道软件测试的一个基本理论是:bug越早发现,修复成本越少。根据这条基本理论,我们测试需要做的事情就是:尽早介入产品的质量控制过程,尽量早的发现软件的问题。那么问题来了,我们测试工程师通过什么点来尽早切入和影响产品的质量呢?我的经验是:通过需求评审和case设计过程的反馈来做前向的问题发现和沟通。
那为什么标题只提case设计过程,而未涉及需求评审呢?那是因为,我觉得case设计和需求评审是一个整体的过程。一般来讲,虽然需求评审在前,case设计和评审在后。但实际上,对于测试工程师来说,需求评审启动的那一时刻,case设计就已经在做了。我们通过需求文档来对产品的功能有一个基本的理解,当然仅仅是理解是远远不够的。这时候,我们需要切换成真正的用户和开发工程师的角色。由于我们从一开始就在考虑如何设计和实现testcase。场景是否能与用户的实际需要相关,开发工程师可能会如何设计?站在这个角度,能帮助我们更好的关注需求文档中的不合理与不明确之处。
当然,为了保证质量,将项目向前推进,每当我们发现问题的时候,就应当及时与产品和开发同时进行沟通,是整个团队的理解一致。晨会是比较不错的方式,有了这样的形式就不需要单独花时间把大家叫到一起。当然,如果团队成员坐在一起就更理想了,直接面对面的沟通是最有效的。我不建议只是通过邮件或者即时消息的方式将问题抛出,因为这样效率太低,而且很可能达不到我们理解一致的效果。这些问题都是要记录下来的,等到测试用例评审环节再结合具体的case场景简单过一遍,保证在开发过程结束的时候,提交的产品功能是我们想要的。
站在case场景来Review概要设计对产品质量和进度也非常重要。一方面,可以加深我们对内部逻辑的理解,有可能会发现设计的性能缺陷或者对某些异常场景处理不当。比如,测试工程师可以问问开发工程师某些异常场景是如何处理如何表现的,你从开发的脸色就可以看出他是不是在设计的时候就对这些不太显著的地方有过注意。很多时候,我们大部分报的bug都是靠这些极端场景的测试用例发现的。那么,在编码阶段进行预防是不是更好呢?而且,这样的问题你提出一些后,会有利于测试地位在团队中的提升,推进一些其他的时候的时候就会更方便。另外一方面,我们测试也需要考虑功能的可测性。一般来讲,testcase更多的是端到端的测试,有界面的场景我们容易覆盖,而一些内部逻辑是不好简单通过界面来进行测试覆盖的。这时就需要向开发提出是否能有一些测试参数或者日志输出方面的支持,或者请求开发在代码review的时候特别关注,由开发来保证复杂逻辑的质量。
说了这么多过程中的细节,我们可以发现,testcase设计表面上看很简单,但实际真正要做好是需要大量的沟通工作的,特别是对于逻辑复杂的功能。对我来说,一份testcase不是为了发现很多的bug,而是给我们建立产品发布的信心。
本文出自 “明皓的技术博客” 博客,请务必保留此出处http://minghao.blog.51cto.com/1009384/1641253
那为什么标题只提case设计过程,而未涉及需求评审呢?那是因为,我觉得case设计和需求评审是一个整体的过程。一般来讲,虽然需求评审在前,case设计和评审在后。但实际上,对于测试工程师来说,需求评审启动的那一时刻,case设计就已经在做了。我们通过需求文档来对产品的功能有一个基本的理解,当然仅仅是理解是远远不够的。这时候,我们需要切换成真正的用户和开发工程师的角色。由于我们从一开始就在考虑如何设计和实现testcase。场景是否能与用户的实际需要相关,开发工程师可能会如何设计?站在这个角度,能帮助我们更好的关注需求文档中的不合理与不明确之处。
当然,为了保证质量,将项目向前推进,每当我们发现问题的时候,就应当及时与产品和开发同时进行沟通,是整个团队的理解一致。晨会是比较不错的方式,有了这样的形式就不需要单独花时间把大家叫到一起。当然,如果团队成员坐在一起就更理想了,直接面对面的沟通是最有效的。我不建议只是通过邮件或者即时消息的方式将问题抛出,因为这样效率太低,而且很可能达不到我们理解一致的效果。这些问题都是要记录下来的,等到测试用例评审环节再结合具体的case场景简单过一遍,保证在开发过程结束的时候,提交的产品功能是我们想要的。
站在case场景来Review概要设计对产品质量和进度也非常重要。一方面,可以加深我们对内部逻辑的理解,有可能会发现设计的性能缺陷或者对某些异常场景处理不当。比如,测试工程师可以问问开发工程师某些异常场景是如何处理如何表现的,你从开发的脸色就可以看出他是不是在设计的时候就对这些不太显著的地方有过注意。很多时候,我们大部分报的bug都是靠这些极端场景的测试用例发现的。那么,在编码阶段进行预防是不是更好呢?而且,这样的问题你提出一些后,会有利于测试地位在团队中的提升,推进一些其他的时候的时候就会更方便。另外一方面,我们测试也需要考虑功能的可测性。一般来讲,testcase更多的是端到端的测试,有界面的场景我们容易覆盖,而一些内部逻辑是不好简单通过界面来进行测试覆盖的。这时就需要向开发提出是否能有一些测试参数或者日志输出方面的支持,或者请求开发在代码review的时候特别关注,由开发来保证复杂逻辑的质量。
说了这么多过程中的细节,我们可以发现,testcase设计表面上看很简单,但实际真正要做好是需要大量的沟通工作的,特别是对于逻辑复杂的功能。对我来说,一份testcase不是为了发现很多的bug,而是给我们建立产品发布的信心。
本文出自 “明皓的技术博客” 博客,请务必保留此出处http://minghao.blog.51cto.com/1009384/1641253
相关文章推荐
- 专注过程改进和产品质量
- 2.7 CMMI2级——过程与产品质量保证(Process and Product Quality Assurance)
- 产品设计过程中如何处理好各种矛盾?
- 定义范围中的备选方案生成、横向思维、创建WBS、工作包定义、WBS、确认范围过程和实施质量过程的关系、联合应用设计和质量功能展开QFD
- 《绩效致死:通用汽车的破产启示》:通用汽车产品设计副总裁对通用破产过程的复盘 五星推荐
- 产品研发过程管理专题——软件测试是提高软件产品质量的必要条件
- 定义范围中的备选方案生成、横向思维、创建WBS、工作包定义、WBS、确认范围过程和实施质量过程的关系、联合应用设计和质量功能展开QFD
- 过程与产品质量保证(PPQA)-软件测试
- 应对质量属性的架构设计过程
- 产品设计过程中,异常流程设计的那些事儿
- 产品设计过程中的沉没成本和禀赋效应
- 产品体验分析:国内APP实战!揭秘京东Apple Watch V1.0设计全过程
- 产品设计流程:从需求分析到产品上线全过程
- 要能真正提升产品开发团队的效率与质量, 你必需要懂得如何 ”设计” 开发团队所需要的实践或框架
- 交互设计师和产品经理必读,推荐《QQ阅读 设计之路》讲述了QQ阅读的前世、今生、来世。面对这么多业界的阅读器,QQ阅读如何脱颖而出,占据市场,一起看看QQ阅读的发展过程。
- PLUTO平台是由美林数据技术股份有限公司下属西安交大美林数据挖掘研究中心自主研发的一款基于云计算技术架构的数据挖掘产品,产品设计严格遵循国际数据挖掘标准CRISP-DM(跨行业数据挖掘过程标准),具备完备的数据准备、模型构建、模型评估、模型管理、海量数据处理和高纬数据可视化分析能力。
- 移动产品设计过程中容易犯的3个错误
- CMMI4过程域之“过程和产品质量保证”
- PLUTO平台是由美林数据技术股份有限公司下属西安交大美林数据挖掘研究中心自主研发的一款基于云计算技术架构的数据挖掘产品,产品设计严格遵循国际数据挖掘标准CRISP-DM(跨行业数据挖掘过程标准),具备完备的数据准备、模型构建、模型评估、模型管理、海量数据处理和高纬数据可视化分析能力。
- 产品研发过程管理专题——软件测试的设计与组织