敏捷测试，没有可参考的验收标准或文档

Question

我被要求测试一个新的软件应用程序。这个项目是运行敏捷的。在某些情况下，我没有验收标准，也没有任何文档可供参考，而且我被要求为用户故事编写测试用例。这有可能吗？以前有人这样做过吗?你有什么建议吗？谢谢！！

Answer 1

遗憾的是，这种情况并不少见，尤其是在较新的敏捷团队中。我会采取积极主动的方法，并编写验收标准，然后让产品负责人(或编写用户故事的人)和开发人员对其进行审查。我建议以Gherkin给-什么时候格式编写它。敏捷联盟网站给出的例子如下：

考虑到我的银行账户是贷方的，而且我最近没有提款，当我试图提取低于我信用卡限额的金额时，取款应该在没有错误或警告的情况下完成

一个用户故事可以有多个ACs。这些ACs可以很容易地用作测试用例。

至少，你应该在斯普林特回顾中提出这个问题--团队需要就什么是可接受的用户故事达成一致，不管是更多的描述和/或接受标准。在下一次的积压整理和Sprint计划会议上，一定要发出任何还没有准备好的用户故事。

Answer 2

用户故事可以很好地洞察产品的行为。虽然它们很少包含明确的测试标准，但通常有很多暗示可以从用户故事中提取出来，测试可以发展成更加形式化的测试。

我喜欢把每个用户的故事分解成三种不同的方式：

1. 首先，识别功能和特性。
2. 第二步，确定由给定环境、操作条件等施加的任何限制。这可以是性能/吞吐量、持续时间、安全性等。
3. 第三关，识别：
   • 接口(其他软件、文件、数据库、外围设备等)
   • 输入和输出(记录、消息、文件、报告、对象等)
   • 配置(系统级、应用层、硬件、网络等)
   • 使用方案(正常的“愉快路径”、错误处理/恢复、备份、安装等)

这可能不是每个人或每个项目的完美方法，但这是一种方法，有助于将一个有点模糊的概念发展成一种更具体的形式。

Answer 3

与开发人员、产品所有者和涉众交谈。找出什么是构建和什么需要测试。

如果你被分配到一个新的产品，我会尝试一些旅游启发：

• 特性浏览:浏览应用程序，熟悉您遇到的所有控件和特性。
• 复杂性之旅:找到关于应用程序最复杂的五件事。
• 理赔之旅:在产品中找到所有的信息，告诉你产品的功能。核实每一项索赔
• 配置浏览:尝试找到您可以以应用程序保留这些设置的方式更改产品中设置的所有方法。
• 人物角色巡演:想象一下该产品的五个用户以及他们希望从产品中获得的信息或他们感兴趣的主要功能。

研究探索性测试并找出新的测试思路。