如何为大规模应用实施质量检查测试流程？

#1 楼

不幸的是，这比这里的任何人都更普遍。我现在担任现职的位置是：两个主要应用程序，都稳定，但是该公司以前从未有专门的测试专家。

我要做的第一件事是确保每个人都知道那里不会有任何快速的变化。无论一个人多么熟练，他们都需要时间来熟悉他们正在测试的软件，任何大而半文档的内容都将具有很多隐性要求，每个人都“知道”但从未正式化。 />
从那里开始，我采取了多管齐下的方法，其中包括：


通过阅读我可以找到的任何文档来熟悉应用程序和要求，探索应用程序，与开发人员和项目经理联系，并通过任何有据可查的回归工作。
测试错误修复，首先与其他团队成员一起检查我做了什么，以确保我没有错过任何机会任何东西（与我一起使用的软件的组合可能比无法测试的要多，而且在早期，我不知道有多少选择会影响我所测试的东西）。这也使系统更加熟悉。
记录任何我认为需要进一步解释的内容。我是否要记录某些东西的经验法则是问自己，是否以后可能需要记住这一点，或者其他人是否会觉得有用。如果我对上述两个问题的回答为“是”，我会记录在案。如果不确定，我会记录下来。通常，我将使用要点注释并将我创建的文档存放在整个团队可以访问的位置，然后邀请他们进行更新和修改。这些说明可以而且确实可以成为支持文档的核心，尤其是在为系统添加功能的项目上。
建立测试数据存储库。测试数据的确切形式取决于应用程序。对于Windows应用程序，我通常会最终得到数据库和数据目录的集合。对于Web应用程序，它有所不同-我目前所支持的Web应用程序的设计方式是，单独的测试数据存储库不切实际。相反，我有哪些客户使用哪些设置并在测试站点上使用哪些设置的主列表。
随着我对应用程序和出现的问题越来越熟悉，我开始构建回归主列表。我现在拥有的是公司内联网上的Wiki形式，每个模块都有一个页面，其中列出了对该模块进行更改时需要检查的配置，以及哪些模块受该模块的更改影响。至少可以说，这种交联很有趣。 （例如，更改是否为选项A定义了组织会更改新聘用向导的流程，薪资数据输入模块的布局，几个菜单，薪资提交模块发送的数据格式以及报告数量）。
在这一点上-从聘用后的几个月到一年多的时间-我对系统有足够的了解，可以建立一个自动化计划并开始致力于自动化回归。
在执行所有操作时，我首先将自己插入到现有流程中，通常将其作为最后的标记。熟悉它们后，我将提出改进建议，通常以增量方式实施。

从这里开始，很多问题管理都是通过电子表格进行的，没有一致的版本管理，两个子团队使用完全不同的流程和工具。
第一步实现一致流程的目的是将问题报告和管理整合到同一工具中。现在几乎完成了。
第二个是始终使用版本控制。
第三步是构建一套完整的开发，测试和暂存Web环境，以尽可能地镜像生产Web环境。正在进行中。
团队流程在不断发展。最初，驱动力主要来自我和我的经理（我是10人一组的唯一测试专家）。现在整个团队都参与其中，当我们中的任何一个发现流程无法处理的事情时，我们都在寻找一种改进方法。
对于台式机应用程序，我整理了一套虚拟机来解决我需要使用的环境。




很明显，在任何给定情况下您要做的工作都将取决于现有流程和测试中应用程序的性质，但是这些类型的方法足够通用，可以适应大多数环境。

#2 楼

好吧，由于这是一次采访，他们可能会尝试找出您要问的问题类型。

我的回答是：

我首先需要知道您的开发人员正在测试什么，以便能够进行进一步的测试而不仅仅涵盖已经经过全面测试的内容。

我想他们主要专注于单元测试其部分，以便进行质量检查。开始进行端到端测试以确保功能正常工作。

然后我将开始在QA环境中利用开发单元测试，以优化时间来创建能够在特定更改上进行端到端测试。

在测试过程中，我还将开始尽可能多地记录文档，以便在组建新团队时更轻松地培训新的质量检查成员。从长远来看，这虽然可能最初会拖慢流程，但会大大降低部门的总体成本。这主要取决于他们计划聘用的质量检查部门的数量以及在特定时间范围内还需要进行多少测试。

端到端测试完成后经过全面检查之后，我将开始构建工具套件，以优化测试时间并希望使大部分回归测试自动化。同样，引用开发单元测试可能是减少此处时间并能够使过程更快进行的一个很好的来源。另外，根据开发技术的不同，如果系统严重依赖于存储过程和数据库功能，我还将利用它们来构建不同测试场景所需的数据。

所有这些之后，质量检查部门应处于良好状态，开始专注于变更请求，而不是确保发现现有缺陷。到目前为止，质量检查部门已经：


端到端全面测试了整个系统
与开发携手合作并建立了牢固的关系
创建文档
利用自动化技术来使系统自动化并生成用于手动测试的测试数据
深入系统，数据库总体上掌握了系统
能够分解为团队并测试各个功能，同时在整个系统上进行了完全交叉培训，从而降低了被公共汽车撞到的风险

#3 楼

我认为，很多普通读者可以与您所描述的情况相关，并且很难解决。 :-)

如果客户不需要文档，而文档仅用于内部流程（例如，如果您的客户是内部客户，并且IT只是成本中心，或者您正在为以下目的开发网站）初创公司），人们很想开发尽可能少的文档以将它们带到第二天，而不是“浪费”时间（记录可能很快就会改变的东西），而是花时间解决更紧急的问题。像在启动时一样，如果为用户解决问题并使他们满意，即使没有适当的文档，也可以生存一天。如果您不交付产品，那么没有多少文档可以节省您的时间。因此，您会逐层累积技术债务，并且进度会变慢。

诀窍是要意识到不再启动时，您需要开始偿还债务（而不是添加新功能）使新客户更加满意）。您采访的公司很可能意识到这一点。

您从建立流程开始，这很难，因为没有人愿意改变，而且直到现在为止，旧的方式已经足够好了...您如何吃大象？一次咬一口。

不能替代现实生活的经验。这就是为什么他们问你是否有这样做的经验。

这不是答案，但是很多书都写了关于如何做的书，我现在不打算写。 >

#4 楼

我认为所有解决方案都取决于问题。如果我是你，我将按照以下方式回答。


找出计划引入正式质量检查团队和流程的动机，工程团队管理层希望解决的质量问题是什么
长期目标和短期目标

如果这不能接受，我认为问题本身是假设性的，不应被视为一个好的书面测试问题。