每当我完成分析任何新特性、增强或缺陷修复的功能规范或需求文档的任务时,我都只会看一遍规范中非常明显的内容,而不会真正考虑所有的用例场景。
由于这一点,有时,我错过了一些最初没有被业务分析师包括在内的重要案例。我在周期中发现了这些问题/差异太晚了,这就延误了整个敏捷过程。
有时,会错过复杂/棘手的测试场景,这会在产品中产生许多漏洞。
另外,当我最后指出功能规范中的问题时,开发团队必须向QA交付一个新的构建,并实现所有这些功能。这降低了团队的生产力。
作为测试人员,我如何改进这一过程。
发布于 2018-05-23 11:02:49
在早期阶段检查业务和功能规范。这不需要太多时间。不要害怕问问题,看上去很傻。毕竟,找到but和but是您的工作,不仅在代码中,而且在规范中。
强制您的分析人员保持规范的结构化。
当您查看规范时,请使用思维映射工具。这将帮助你构建你头脑中的信息,即使它没有足够的结构。这也将帮助您强调可能遗漏细节或依赖关系的特定区域。
发布于 2018-05-23 11:31:26
您认为这是一个问题,我认为这是敏捷团队中的正常开发过程。敏捷宣言说
欢迎不断变化的需求,即使是在开发的后期。
就像你在你的问题上表现得很好一样,很难事先知道所有的事情。如果您和您的团队真的采用敏捷,那么您将放弃编写详细的需求,而将重点放在
频繁交付工作软件
旁注-
发布于 2018-05-23 14:12:42
作为QA测试人员,您可以在开始测试之前花一些时间来编写涵盖大多数场景的大量用例。这将帮助你在后期阶段。然而,无论您多么努力地思考所有用例,都会错过一些用例。我们测试者也是人类。
让业务分析人员知道他们在Requirement中漏掉的规范,也让更高的权威知道它。由于BA错过了需求,开发人员无法开发它,测试人员也无法在测试的早期阶段识别它。
因为在req中没有提到规范。医生,测试员怎么知道需求是需要的?测试人员确实需要跳出框框才能做到这一点。如果你在做,你就做得很好。告诉BA改进他们的医生分析过程。
https://sqa.stackexchange.com/questions/33845
复制相似问题