软件开发经理在QA/QC过程中的角色是什么？

Question

我读过关于软件QA/QC和软件测试的文章，在敏捷环境中，软件QA过程“指导”软件过程，也就是说，它在准备好发货之前不会发货，而SQA是软件交付过程的一个关键部分。

我是一家很小的软件公司的软件开发经理。我们目前在SQA实践中非常基础。我认为作为这里的领导者，我的工作是让软件QA过程变得更严格，或者至少更有效。

我想从曾经或正在担任SDM头衔或角色的人那里了解，他们认为自己的工作是什么，在SQA方面，他们的工作是什么？

Answer 1

我从来没有做过SDM，但我对这件事有自己的看法，所以我会回答这个问题:-)。在写完下面的回复后，我觉得这有点像"QA“。除了我概述的内容之外，请继续探索更多的资源，我只是想提供一些简单的想法，可以在一个精益、敏捷的团队中显着地提高质量。

如果您拥有0专用的QA资源(这意味着整个团队负责QA)或所有QA资源报告给您，那么您绝对应该主动采取更严格的QA实践。在较小的团队中，您通常没有专门用于QA的资源就可以逃脱--您无法逃脱的是根本没有QA实践。每个人都需要投入并成为QA过程的一部分。

对于开发人员来说，直接提高质量的一种流行且有些自然的方法是采用TDD (测试驱动开发)或BDD (行为驱动开发)方法。基本思想是在编写代码之前创建自动化测试，并且在实现特性时，它们会导致测试用例开始传递。当所有测试都通过时，您的功能就完成了。这里到处都是关于TDD和BDD的文档，所以我不会在这里详细介绍。

您还可以将开发人员与其他开发人员配对，让他们充当由其他开发人员开发的特性的QA。这将包括为非功能性测试做一些简单的测试规划，如果没有专用的QA资源，就很容易被忽略，例如应该自动化的测试用例、性能/压力测试、安全测试、本地化/全球化测试、可访问性测试等等。

即使没有QA资源，您仍然应该在发布周期结束时计划一个“稳定”阶段，在这个阶段，整个团队的主要关注点是质量，而您的团队主要处于QA思维状态，其次是修复发现的bug。只需确保在此稳定期间修复的bug严重程度很高，您就不希望在发布之前修复错误只会破坏产品其余部分的稳定性。

另一个简单的，有时也是有趣的方式，让每个人投入到质量是一个"bug bash“，每个人停止他们正在做的功能工作，并练习您正在开发的产品。你可以颁发奖品等等..。如果你在这个网站上搜索bug bash，你可以找到更多的信息。这通常发生在您完成功能之后，就在(有足够的时间修复发现的任何主要错误)之前或在稳定阶段的开始。

最后，您应该确保所有开发人员都遵循关于代码评审、静态代码分析、使用代码覆盖率工具来帮助驱动单元测试等方面的开发最佳实践。