V＆V并不意味着仇杀

在过去的六年中，我一直在开发和接受测试各种应用程序的复杂性和规模，以进行和维护临床试验。 大数据，大量的可视化和视图，数据仓库，ETL等。 该产品供医生，管理人员和参与研究控制与监控的人员使用。

对于直接影响患者的生命和健康的应用，需要正式的验收测试过程。 验收测试结果以及其他文档包将提交给FDA（美国食品和药物管理局）审核。 FDA授权将该应用程序用作监视和进行临床试验的工具。 总的来说，我的团队已经开发，测试并交付了三十多个应用程序。 在本文中，我将简要讨论一个小组的验收测试和工具开发。

注意：我不假装是最终的真理，并且我了解我写的大部分内容都是船长的独白证据。 但是我希望所描述的内容对入门级人员和在日常工作中遇到这种情况的团队都有用，或者至少使那些流程更简单的人感到满意。

美国食品药品管理局

在药物注册和广泛的医学应用之前，全世界的临床研究是药物开发中不可或缺的一步。 在临床试验中，研究了一种新药以获得其有效性和安全性的数据。 维基百科

换句话说，为了使“从头到头”的药丸到达布莱顿海滩某处的药房，它需要经过3个阶段的人体试验，在此过程中，应确定片剂中应包含多少活性物质，其安全性以及是否能完全治愈头痛

FDA对我们来说是什么？它对开发过程和发布周期有何影响？

食品和药物管理局（FDA，USFDA，字母。食品和药物管理局）是美国卫生与公共服务部的联邦执行部门之一。 该部门负责食品，药品，化妆品，烟草制品和某些其他类别商品的质量控制，并监督该领域对法规和标准的遵守情况。 维基百科

FDA实际上并不在乎开发过程本身，我们采用的是普通的SCRUM（或者说不是完全SCRUM，他们称这种“修改后的SCRUM”现在很流行），并且没有冲刺发布周期。 我们不在冲刺结束时使用产品（甚至在三个冲刺结束时也不使用产品，如果时间轴涉及15个冲刺甚至甚至没有十个产品），也就是说，从交付给最终用户的角度来看，我们有类似瀑布的方法。

在我们的案例中，测试分为两个独立的部分，分别具有不同的时间表，不同的估计和不同的过程。 第一部分是常规的开发中测试，测试人员是开发团队不可或缺的一部分，并在开发过程中完成sprint。 第二部分是实际的验收测试和维护（需要时）。 该过程是根据V＆V方法构建的：输入端有用户和功能要求，输出端有测试和一揽子支持文档。

发布周期取决于工作量，发布通常不会进行迭代。 发布后，该应用程序可以长时间保持不变，即发布之间的中断-从几个月到一年或更长时间。

V＆V

V＆V是什么动物，在接受过程中如何体现出来。

“在软件项目管理，软件测试和软件工程中，验证和确认（V＆V）是检查软件系统是否符合规格以及是否满足预期目的的过程。 它也可以称为软件质量控制。 作为软件开发生命周期的一部分，通常由软件测试人员负责。 简而言之，软件验证是：“假设我们应该构建X，我们的软件是否能够实现其目标而没有任何错误或漏洞？”另一方面，软件验证是：“我们应该构建X吗？ X是否符合高级要求？» Wikipedia

免费翻译：

“在项目管理，测试和软件开发中，验证和确认（V＆V）是验证开发的软件符合规格并实现其预期功能的过程。 一般而言，它也可以归因于质量控制。 通常，测试工程师负责软件开发生命周期的验证。 用简单的话来说，软件验证可以描述为：“假设我们必须开发系统X。是否在没有任何错误和假设的情况下实现了目标？”另一方面，软件验证是“开发的系统X确实是一个东西。我们想得到什么？ 系统X是否符合高级要求？”

换句话说：
验证：我们做的产品对吗？
验证：我们在生产正确的产品吗？

这意味着我们必须以必要和足够的完整性来测试功能和用户规范。 对于我们来说，第一个V变成验收测试（SIT），第二个V变成维护（UAT），其中：

• SIT-系统集成测试
• UAT-用户验收测试

需求覆盖率的可视化在“可跟踪性矩阵”（Excel或Word中的常规表，我将在后面进行介绍）中进行，从而可以从需求到测试进行跟踪，反之亦然。 在使用电子文档管理的情况下，矩阵是自动构建的，测试链接到与测试一起存储的需求（总共= HP ALM，自然不会存储其中的一堆）。 如果未满足要求且将不满足要求，我们将说明原因。

什么时候不需要覆盖要求？

例如，CFR第11部分（ 由FDA建立的有关电子记录和电子签名的规则 ）包含了大量已由Microsoft涵盖的要求，如果我们使用Windows AD进行身份验证，则无需再次涵盖它们。

最终，验收测试的实质在于测试产品是否符合要求以及产品符合性要求。

的角色

参与该过程的角色很多，以一种或另一种形式参与软件开发的每个人都熟悉：开发人员（初级，中级，高级，主管），单元测试员，SIT测试员，技术产品负责人，业务产品负责人，Scrum Master ，项目经理，业务分析师，技术主管，SIT测试主管，UAT测试主管，全球质量控制，支持，部署工程师等。

我们的具体角色是全球质量控制 。 在开发和验收期间，这是客户方负责满足流程要求（软件生命周期和客户方各种标准操作程序（SOP））的人员，并进一步提供了一揽子文档供外部审核。

验收文件

作为产品发行版的一部分，将创建具有大量嵌套级别的文档包，其中包括与如何测试产品，为什么以这种方式进行测试（而不是以其他方式进行测试）以及具体进行了哪些测试以及遗漏的内容相关的文档：

验证计划和团队名册 -PM负责撰写和批准文档。 文档通常包括系统描述，将在开发和测试过程中创建的工件列表，验证策略以及具有职责的角色列表。

测试策略 -不适用于特定应用程序的文档，但是是为单独的产品分支或单独的测试分支创建的。 例如，我们如何以及为什么确定将要自动化和不自动化的内容； 什么技术 我们将如何安排手动测试（检查清单或测试脚本，或两者一起，或完全不同）； 我们如何决定是否要驱动负载？ 依此类推。

测试计划 -UAT和SIT团队共有的测试计划 ，包括对测试对象，可能的限制，环境要求，时间，测试套件等的简短描述。

测试套件 -由功能区域，测试类型或任何其他功能组成的一组测试或清单。

可跟踪性矩阵 -从需求到测试的跟踪矩阵。 跟踪作为覆盖的证据是该过程的重要部分。 使用任何要求的标识符，您可以找到确认满足要求的特定步骤，并为特定版本的应用程序（或正式涵盖此要求的每个版本）向审阅者提供证据（屏幕快照，文件等）。 因此，链接，链接并再次将测试链接到需求（任务），在此基础上您可以获得预期的结果，即使您不需要这样做。 如果由于使用不同的非集成工具而无法实现，则始终可以在任务/测试中留下注释，或者制作矩阵（上面提到的Excel），或者归档包含三个表的原始数据库。

PDS-产品设计规范，由技术顾问或项目架构师开发的文档，实质上是高级和低级应用程序体系结构（HLA和LLA）的组合。

FRS和URS或BRS是功能需求和用户需求，通常以两个单独的文件的形式出现，但有时会结合在业务需求规范中。

缺陷日志 -测试期间检测到的缺陷日志（应用程序缺陷和要求）。

次要问题日志 -测试中的小错误日志（打字错误，遗漏/不必要的要求等，从根本上不会改变测试含义的任何错误）。

测试摘要报告 -报告测试结果。 TSR是测试计划的结束文件，其中包含：

• 有关已测试的程序集的信息（包括内部版本号和部署日期），测试周期数和测试结果。
• 有关公司批准执行的测试计划和测试程序（SOP）的违规描述。
• 未解决缺陷列表，解释了转移到下一版本的原因。
• 链接到缺陷日志或日志本身。
• 指向测试错误日志或日志本身的链接。
• 决定在生产中安装的建议。

部署计划 -负责支持和集成的文档，在SIT环境上的安装过程中进行了编译，随后用于在生产环境中部署该版本。

验证摘要报告 -验证计划的结帐文档。

文件批准

有条件的文档批准过程分为三个阶段：

• 准备文件。
• 复习
• 声明。

考虑测试套件的示例。

为了编写测试脚本并将其组合到测试套件中，我们使用了在客户端认可的标准模板。

测试套件的组件：

• 项目和应用程序的名称。
• 发布版本。
• 集的名称和唯一标识符。
• 描述（我们测试什么，我们使用什么类型的测试）。
• 测试。
• 批准人名单。

反过来，每个测试都包括：

• 集合中的名称和唯一标识符。
• 内容描述
• 前提条件。
• 后置条件。
• 跟踪（测试中涵盖的要求编号）。
• 执行功能（例如，掩盖敏感数据的指令）。
• 步骤（必需的操作，预期的和实际的结果）。
• 测试结果。
• 完成了。
• 复兴。

测试的正常生命周期类似于反馈瀑布，如下所示：

1. 拼写
   需求分析。 测试设计技术的定义和应用，以最充分地覆盖功能。 编写步骤。
2. 测试段落/处女的段落
   在此阶段，将评估应用程序满足需求的程度，并耙平所有可能的错误，包括需求错误。
3. 项目经理审查（SIT团队负责人）
   文体和逻辑的审查。
4. 测试通过/通过SIT环境
   在此阶段，将捕获与安装，环境和环境配置相关的错误（默认情况下，SIT环境完全或几乎完全重复PROD）。 成功完成此阶段意味着所包围的版本是稳定的，可以将其视为候选版本。
5. 客户评论（全球质量控制）
   全球质量控制部门（QC）验证是否满足要求，并且公司已进行书面SOP测试。
6. 批准（全球质量控制，技术订单，业务订单）。
7. 在SIT环境中正式执行测试（发布候选版本）
   在批准通过测试（第6页）并成功完成SIT环境的测试（第4页）之后，将在SIT环境中正式进行测试，并正式确定结果。 如果在测试通过中发现的错误没有像在开发过程中一样被正规化并简单地输入到Jira中，那么将为在正式通过中发现的每个错误创建一个单独的缺陷表，该缺陷表包含在产品的输出文档包中。
8. 审查负责该项目的段落结果（SIT团队负责人）。
   与点3相似，检查填充样式并分析结果。
9. 客户评论（全球质量控制）
   全局质量控制检查填写结果的正确性和完整性，可能的错误以及确认的存在（例如，屏幕截图）。 重要的一点是，Global QC负责向外部审核（由FDA或客户提供）提供一揽子文件。

处理个人数据

鉴于研究是使用双盲*方法进行的，因此我们所遇到的问题较小。 但是必须更改医生，公司名称，研究协议编号等的数据。 从正式的角度来看，如果我们无法清除敏感数据，则必须在屏幕截图上屏蔽它们，但这是一个相当标准且可以理解的情况。

*双盲-双盲方法。 患者被随机分为两组，一组接受研究药物，另一组接受已证实有效的安慰剂或药物。 同时，医生和患者都不知道患者被分配到哪个组。 这消除了医生的偏见和安慰剂作用。 在处理个人数据的情况下，这意味着在大多数情况下，无法根据数据库中存储的数据或用户可访问的数据来识别患者的身份。

但这是我们问题中最少的事实，并不意味着它不会带来麻烦。 这是我们曾经用来进行项目的几件事：

假装：地球仪

在创建哇效果的应用程序之一中，我们不仅真正需要制作一个交互式地球仪，还可以用鼠标旋转，切换日/夜等。 在地球上，地址上有标记，这些标记的颜色取决于这些值的值和范围（例如颜色编码）。 在演示环境上对数据库进行匿名处理后，在演示之前两个小时，由于使用了匿名脚本，我们没有邮递区号，这会带来所有后果。



道德：演示前两个小时不要触摸数据。

故事二：“关于匿名化”

背景：数据是从大量来源中收集的，数据属于不同的域，但通过标识符互连。

历史记录：数据已上传到存储库并进行匿名处理，然后再用于测试目的。 事实证明，并非从所有必要来源下载数据。 然后他们加载了缺少的部分。 无法将数据的第二部分（尚未匿名）与已经匿名的第一部分链接起来。 结果，SIT环境的工作被推迟了两个星期，部署和支持团队对此进行了更正。

道德：匿名化之前，您应该确保数据库包含应包含在其中的所有内容，或者事先考虑匿名化和混淆机制的适用性。

电子与纸本工作流程实践

与HP ALM合作的人并不会对马戏团大笑。

从人工工作的角度来看，电子文档管理在某种程度上简化了沟通以及审查和通过过程，但是实际上在准备测试和执行的时间范围内并没有浪费时间。 下面列出了基于HP ALM的示例的电子工作流程与纸张的优缺点。

优点：

• 保持最新版本很容易。
• 少手工制作。
• 所有团队成员都可以随时访问特定测试的当前状态。
• 更改历史记录。
• 段落历史。
• 您可以跟踪完成测试所需的时间。
• 计划时间以便进一步通行。
• 我们必须尝试对测试使用错误的版本。
• 电子签名。

缺点（专门针对HP ALM）：

• 格式化测试花费了大量时间。
• 工具本身存在周期性问题。
• 缺少普通的拼写检查器。
• 界面不便。
• 编写和复查测试所花费的时间实际上与Word中的测试相同。
• 费用。

与文书工作和手动签名有关的案例研究：“发行前的噩梦”

有一个晚上，我写了450次，“图形上的点的颜色与要求中说明的相对应，姓氏是日期的名称”，并签名-仅因为我们是在黑白打印机上打印的，而图形上的点的颜色很重要。



道德：手段的选择应与目标相一致。

故事二：“重力好，严重性可靠”

纸张工作流程就是纸张（谁会怀疑）。对于接收距离最大应用程序较远的应用程序，它的容量可能在5公斤左右。



以上结论（以及许多未曾讲过的）得出的结论是：尽管电子文档管理存在列出和未列出的弊端-如果可以选择，那么即使HP ALM（不再是HP）也一定要选择电子文档。

自动化技术

大量的可视化无法实现稳定的应用程序自动化，因此，作为初始方法的一部分，我们将自己局限于单元测试（包括基础方面）和API测试，而未尝试进行E2E。

我们如何以及为什么至少要实现部分自动化？

首要任务是向我们自己解释，在某些情况下，我们确实会节省时间。是的，这是可以理解的：不是每个人都相信自动化，而且常常不能证明自动化是合理的-因为以错误的方式使用自动化，不是在那里使用，不是为了自动化，但这是另一份报告的主题，其中的内容比“自动化必须具备！”要少得多。 ”，但仍在数量上。

第二个是向客户解释他将获得时间，并且从正式的角度来看，时间将是足够可靠和可以接受的。行业受到控制是有原因的。

第三，主要：确定算法，通过该算法，我们可以有意识地对测试特定应用程序或应用程序的一部分进行自动化决策，并获得自动化的同意。这很重要，因为根据上述以手动测试套件为例的文档批准过程，很明显应该对自动化过程进行同样的控制。

在向我们自己和客户解释并证明了前两点的合理性之后，我们编写了一个测试策略，要求业务分析师在需求中添加其他字段，并根据可以形成自动化集合的答案形成一系列问题。

在我们的案例中的问题清单：

1. 在这种特殊情况下是否可以自动化测试？
2. 组件*测试是否自动化才能稳定？
3. 我们应该多久运行一次为组件编写的测试？
4. 此功能对业务至关重要吗？
5. 自动化测试有多困难？

*稳定=一段时间未更改组件，并且不计划在即将发布的版本中更改组件。
**根据业务分析员添加到需求中的字段的值来附加。


一般而言，决策过程如下：

1. 输入内容符合FRS的要求。
   将编译一个设计矩阵，其中每一行都是FRS的要求。作为列：
   
   • 要求说明
   • 问题1-5
   • 团队决定
   • 预计写作时间
   • 批准书
   • 留言
2. 团队给出问题的答案，并根据收到的数据确定是否值得对全部或部分特定需求/一组需求进行自动化测试。
3. 客户检查提议的解决方案并批准最终版本。
4. 经Design Matrix批准后，将编写自动测试。自动测试的脚本在Gherkin上进行了描述，并且进行了类似于手动测试的审查（全球质量控制，技术负责人，企业所有者）。步骤定义，页面对象等在请求池中进行审查，包括由客户方面的技术专家进行审查。预计全球QC会提供自动测试结果和生成的报告。

自推出以来的两年中，我们切换到与数据仓库中数据的下载，配置和显示相关的两个应用程序的验收测试的部分自动化，并且在不久的将来，如果可能的话，我们计划继续在为客户开发的其他产品上继续使用组合方法。

结论

最后，我想指出的是，正式的验收测试并不是很多人所害怕或无用的东西。它允许充分利用场景方法进行测试，以促进对未来版本的测试，确认必要和足够水平的软件质量，并最终使客户放心。在客户开发中，重要的是什么？