如何向高级管理人员传达质量保证和测试的价值

Question

我最近在一家小公司担任QA领导/经理的职位，该公司已经开发软件超过10年了。然而，他们从来没有一个专业的测试人员或任何QA部门。

我发现要让高级管理人员理解测试的重要性和变更管理的重要性是非常困难的(要改变十多年的文化是非常困难的)。

他们希望很快转向敏捷(在上一次大瀑布发布之后的3到4周)，但他们仍然要求开发人员在发布版中添加新特性，而不讨论对开发、测试和发布日期的影响。

我来自一个企业软件背景，那里的QA部门已经成立了。这份新工作总是一项挑战。有什么建议吗？

谢谢,

Answer 1

是的，你有很多教育要为他们做。

从一个高层次的概念开始：

倡导预防过度检测

简单点。说出来然后安静点。让公司管理层和你进行一次对话，并确保他们在没有接受这一想法的情况下就能接受这一概念，你将很难接受下面所述的任何其他内容。

首先，我将识别和交流允许这些错误发生的过程(如果可能的话)，然后更重要的是，在您希望引入的过程中防止将来的错误。

我建议利用敏捷的机会来介绍qa。

请解释一下，与传统的瀑布式设置不同，您需要编写代码，然后进行QA测试。在敏捷中，QA需要成为开发过程本身的一部分。

请解释一下，对于敏捷来说，QA是嵌入到开发团队中的，并且首先要防止bug的发生。他们宁愿让QA修复那些花了钱的错误，或者一开始就阻止它们。明确地指出，当您转移到QA时，防止bug，其工作实际上是不可见的。没有一堆bug报告显示了它们的价值，等待开发人员修复，而是一开始就使用避免bug的软件。

具体来说，您需要确保开发团队(包括QA)使用好的方法，如：

• 多设备，浏览器和版本测试。从服务器日志中获取站点状态，并查看用户使用的内容。确保管理层意识到开发人员不能检查所有设备、浏览器和版本。这是不切实际的，他们不会这么做的。
• 确保公司的质量指标被使用。对一些人来说，这意味着更多的收入，对另一些人意味着更多的新用户，对另一些人来说意味着更大的市场份额。
• TDD/BDD --您不必在实际代码之前编写测试，但是要确保它们是在代码完成并合并到主代码之前编写的。管理层需要知道，这是在使用实践，以便他们可以观察，当它没有遵循。
• 将你的工作QE质量工程置于QA质量保证之上，强调现代质量商店的工程方面，并明确这不仅仅是手工测试
• 使用选择器的页面对象方法。对这样的良好实践充满热情，以获得对代码实践充满热情的开发人员的尊重。
• 识别用于自动化的快乐、悲伤和可选流程，以确保产品具有良好的测试覆盖率。
• 使用分析代码和测试覆盖率的工具，并向您展示需要工作的地方。
• 当引入敏捷方法时，请确保to的定义包括对QE的批准，但是要小心不要为所有门票设置QE路障。要有选择性。

展示管理的各种例子，什么时候质量工程会有所帮助。这需要耐心和机智。在一年的时间里，你应该有几个机会来强调那些花费了公司资金的bug，并且可以用更好的质量工程来保护它。如果你一年多没有例子，就很难说服人们相信量化宽松的实际价值

Answer 2

取决于您公司的规模和您生产的软件产品。

对于一个不需要专门的QA部门的公司来说，这并不罕见。

我的建议是：

• 用事实来说服他们。在敏捷冲刺期间，如果您能够收集信息，说明拥有一个专门的QA团队比没有更好的方法。例如，进入生产的bug的数量等等。