但是，有时我会觉得，因为我是如此接近细节（我是唯一了解应用程序各个方面的人）对我来说，很难真正客观地进行测试，这似乎是必要的。有时候我们会部署到生产环境，有些事情我只是没有想到要进行测试，也许是因为在潜意识里，我倾向于更频繁地测试“快乐之路”（而且我还是传统版本的超级用户）是我们要替换的软件，所以如果有所作为，我会产生一些偏见。）
说业务分析师应该与编写测试用例的人分开是对的，或者创建测试用例并弄清所有可能的场景时，我是否只需要学习做更彻底的工作？无济于事的是，我倾向于将自己视为开发人员而不是测试人员（不是我做过任何实际的编程，而是我确实帮助开发人员提出解决方案，并经常深入研究某些技术细节）。
另外一个细节，如果有什么不同的话：我本质上也是项目经理（尽管我没有正式拥有经理的头衔）。确保对新功能进行优先级排序，在开发人员之间协调工作，确保我们达到发布目标是我的责任。
#1 楼
BA + QA没问题，但是看起来您也是您项目中的一名架构师。我看到将架构师和QA角色组合在一起是直接的祸害。
您已经注意到自己的每一个担忧：建筑师的自然作用是支持“程序正在运行”的想法。质量检查的自然作用是直接相反的：证明“程序不起作用”。如果同一个自然人扮演两个相反的角色，这可能会导致自己的妥协。
是的，有很多人可以迅速“穿上不同的鞋子”，但这需要团队的经验和信任。 br />我看到了减轻这种情况的几种方法：
您可以自己进行一些开发，然后指派其他人来执行质量检查。
您可能会在公司中找到另一个遭受该问题困扰的团队。同样的问题。您成为他们团队中的质量检查人员，其中一些人成为了您的质量检查人员。在团队之间共享知识会带来额外的好处。
评论
是的，我确实发现自己处于频谱的相反两端，既是需要质疑系统状态的人，又是主张其有效性的人。两端无疑是导致我困难的原因。
–瑞安
2012年7月24日在10:33
#2 楼
如果我在您的鞋子里，除了自己之外，我还会增加另一个人进行测试。听起来您已经在接受故事/功能方面做得不错，但是有点“作者失明”，这导致您遗漏了一些小问题。添加另一双眼睛将有益于质量，同时又不会失去专业知识。#3 楼
敏捷世界中的测试人员并不是唯一进行实际测试的人员。应该将他们视为整个团队的测试教练，以各种方式改进测试，例如提出良好的测试规范，使接受标准更具可测试性等。由于您很难成为一名有效的测试员，因此对于“此软件有效”的偏见，您可以尝试鼓励其他团队成员进行自我测试。您可以尝试每隔一段时间组织一次错误查找者，让每个人都戴上测试帽，并尝试从新的角度测试产品。
#4 楼
我认为您有两个以上的角色。如果项目足够小，那可能行得通，但是如果项目规模扩大了，那么规模扩展将非常糟糕。我不认为一个人不能做各种各样的工作，但另一方面，您的能力和时间有限，因此，如果工作量增加，您可能会开始偷偷摸摸地处理它。这就是事情开始下滑的地方。
我打算为最糟糕的情况做计划，但我仍然认为至少有些真实。想象一下，您的项目增长了3倍，您的截止日期提前了，预算削减了，您生病了2周。您现在的超人角色怎么样？整个项目可能最终会遇到一个真正的问题，只是因为您没有想到的就是项目的成功之路。
#5 楼
您在测试中提供了哪些培训和经验？从您对角色的描述中，您可能会问：“一个真正忙于执行多项任务的人也可以很好地测试应用程序吗？”
评论
没有正规的测试培训。公司的政策是业务分析师将编写测试用例并进行大部分测试。该小组的期望是分析师将承担除编程之外的几乎所有任务。我主要关心的是作为应用程序设计师的客观性不足。我同意真正繁忙的部分-测试通常没有被赋予应有的优先权。
–瑞安
2012年7月23日在22:49
优秀的测试人员还希望了解和了解该应用程序的所有详细信息-它的设计，编码，构建方式，用户身份等。听起来您需要打仗来追踪您的报道-为SF DEPOT做一个Google测试一个例子
– Phil Kirkham
2012年7月24日，0：01
评论
是的，它可以工作，但是在您的情况下，听起来好像没有用。如果您认为它可行，我认为您不会问这个问题。也许更好的问题是如何在人手不足的团队中获得更多测试资源。你写的只是我的感觉。