让软件的测试人员也是业务分析师有效吗？

Question

我是一名业务分析师，负责一个中等规模的内部软件项目。我的工作是创建需求、设计UI、编写功能规范、与开发人员一起实现它，并在一定程度上为某些报告编写查询(或者至少向开发人员展示某些报告需要实现的方式)。

尽管如此，我还必须承担起一个主要的测试角色，编写所有的测试用例，并且自己完成大部分的测试(还有其他人介入做一些测试工作，但是测试用例必须来自我)。我发现，大部分时间，这是很好的工作；我捕获了许多错误，他们得到了修复，等等。

然而，有时我觉得，因为我非常接近细节(我是唯一了解应用程序每个方面的人)，所以我很难在测试中做到真正客观，这似乎是必要的。我们曾多次部署到产品中，有些事情我只是没有考虑过测试，也许是因为潜意识中我更倾向于测试“愉快路径”(而且我也是我们要替换的软件的遗留版本的超级用户，所以我已经开发了一些偏见，如果这有区别的话)。

说业务分析师应该与编写测试用例的人分开是正确的吗?还是我只需要学习在创建测试用例和计算所有可能的场景时做更彻底的工作？没有帮助的是，我更倾向于把自己看作一个开发人员，而不是一个测试人员(不是说我做了任何实际的编程，而是帮助开发人员想出了解决方案，并且经常深入研究某些技术细节)。

还有一个细节，如果有什么不同的话:我基本上也是项目经理(虽然我没有正式拥有经理的头衔)。我的责任是确保新特性得到优先排序，在开发人员之间协调工作，并确保我们的发布目标得以实现。

Answer 1

成为BA+QA是没有问题的，但看起来您也是项目的架构师。

我认为将架构师和QA角色组合在一起有一个直接的坏处。

你已经注意到了每一个问题:架构师的自然角色是站出来支持“程序正在工作”的想法。QA的自然作用与之截然相反:证明“程序不起作用”。如果同一个人扮演两个相反的角色，这可能导致与你自己的妥协。

是的，有很多人可以很快“穿不同的鞋”，但这需要团队的经验和信任。

我看到了几种减轻这种情况的方法：

1. 你可以对自己进行一些改进，并指派别人来扮演QA角色。
2. 你可能会在你的公司里找到另一个遭受同样问题的团队。你成为他们团队中的QA，其中一些成为你的QA。这将有一个额外的好处，分享知识之间的团队。

Answer 2

如果我站在你的立场上，除了你自己，我还会增加另一个人来测试。听起来你已经很好地接受了这个故事/特性，但是有一点“作者盲目性”，这导致了你忽略了一些小问题。增加另一组眼睛将有益于质量，同时又不会失去你的专业知识。

Answer 3

敏捷世界中的测试人员并不是唯一进行实际测试的人。他们应该被视为整个团队的测试教练，以各种方式改进测试，比如提出良好的测试实践，使验收标准更易于测试，等等。

由于“此软件工作”的偏见使您很难成为一个有效的测试人员，所以您可以尝试鼓励其他团队成员测试自己。您可以尝试每隔一段时间组织一次bug查找器，每个人都会戴上测试帽子，并尝试从新的角度测试产品。