2013年10月22日,星期二09:04

在软件测试项目中执行早期生命周期验证的四种经济有效的方法

撰写者

生命周期的早期验证并不是软件测试领域的新概念。它侧重于测试团队验证软件开发和测试的上游生命周期阶段的关键结果的实践。但是,仍然有许多测试项目未能有效地实施这些实践。 这主要是由于执行这些实践的方式不一致和不正确。该观点基于作者的经验,描述了在测试项目中实施早期生命周期验证实践的四种最有效方法。这有助于项目实现更高的生产率和应用程序质量。它还旨在降低项目的总体成本,因为在项目的早期阶段就可以发现并修复缺陷。

为什么在软件测试中进行“早期生命周期验证”?

过去仅在软件生命周期的最后阶段即在系统测试或性能测试期间才对软件质量进行检查的日子已经一去不复返了。早期生命周期验证(ELV)是Or Shift左(通常称为)规范,在所有类型的软件测试项目中都越来越流行。在这种方法中,重点是测试团队对上游生命周期过程的可交付成果进行全面验证。 轻型电动车的主要优势包括

  • 修复缺陷的工作量和成本较低,因为修复缺陷的成本在每个生命周期阶段均呈指数级增长
    愚人节Oct22
  • 确保系统一流的质量,因为它确保了项目每个阶段的良好输入质量
  • 软件开发生命周期(SDLC)
  • 在生命周期的早期发现缺陷可以节省项目的总周期时间,从而确保更好的上市时间

关键成功标准

实施早期生命周期验证方法的关键成功标准是-

  • 协作方法–要执行ELV活动,它需要一种协作方法,其中涉及各种相关团队,例如–客户利益相关者,业务用户,开发团队,体系结构团队,功能测试团队,性能和其他特殊测试团队,帮助文档编制团队等。每个团队都需要在最佳周期内拥有一流的应用程序质量的单一愿景。他们应该开放以接受其他一些团队成员指出的关于其工作产品的建议和问题。
  • 提供适当的技能来执行这些活动–要执行这些活动的关键人员需要具备以下技能
    • 优秀的领域和应用知识
    • 对项目中正在使用的IT技术有很好的理解
  • 客户愿意投资于ELV活动– 轻型电动车不建议削减SDLC的任何现有评估活动,例如设计审查,代码审查等。这些是在基本评估活动之上提出的一些其他活动。因此,让客户愿意花额外的钱进行这些活动所需的精力和时间很重要。与执行这些活动的投资相比,这些投资的预期投资回报率是巨大的。

如果没有以下任何要点,则ELV的整体方法将无效。

轻型电动车的各种方法

有多种执行ELV的方法。但是我认为,以下是在测试项目中实施ELV的前4种方法。

1.需求评审(RR)

一旦业务需求文档(BRD)和系统需求规范(SRS)被客户团队/开发团队的有关利益相关者作为基线,测试团队便可以开始使用这种方法。因此,在开始后续的SDLC阶段(即设计阶段)之前,应该有一个阶段由测试团队对业务和系统要求进行全面审查。在质量检查小组中,应该有可以有效发挥“用户代理”作用的个人资料,他们可以戴上客户的帽子,从用户的角度了解系统的本质和细节,从而可以从用户的角度进行思考。该用户代理还应该对正在考虑的应用程序有很好的了解。他/她还应该具备有关领域和整个行业趋势的技能。例如,如果所考虑的系统出于某种法律合规性的观点,则用户代理应了解有关以下内容的详细信息:

  1. 完整的法律方面知识,以建立合规系统
  2. 行业趋势,例如其他公司/竞争对手为遵守该趋势所做的工作

用户代理可以从团队中挑选更多成员,并以组审阅模式执行这些活动。需求文件(BRD和SRS)都从关键的3个角度进行了全面审查,即功能验证,结构验证和一致性验证。

功能验证- 团队确保业务需求能够准确,完整地表示业务目标和用户需求。正确翻译为系统要求的形式。对于前者-团队可以提出以下观察到的意见

评论 含意/客观

BRD-“所有过去的工资单应提供给员工”。
SRS –“应向员工提供最近5年的工资单”
澄清。

需要立即解决此问题,而不是陷入测试或生产阶段
SRS –提及财务要求X偏离了SOX规范。为什么? 如果在生产过程中意识到这一点,则需要立即讨论并结束,否则可能会导致罚款

结构验证– 轻型电动车团队从结构的角度检查需求,即检查表达的歧义,寻求澄清,以结构化的自然语言(例如英语)重新陈述,并应用“原因图”或“决策表”技术以更好地表达。他们还考虑了一些与自然语言相关的清单和诸如歧义检查器之类的工具,以针对自然语言的缺陷来验证需求。

对于前-团队可以提出类似的意见

评论 含意/客观

SRS-“如果是交易x,则更新相关的相应数据,例如EPF,薪水结构等。”

这个“等”是什么意思?是否还有其他记录需要更新?我们不能将其留给个人来解释。
SRS –“在适当的时间检查帐户是否存在差异” 需要明确和清楚地提到适当的时间。

符合性验证轻型电动车团队将确保在需求追踪矩阵(RTM),需求优先级,需求变更程序,流程遵循等方面符合需求管理流程。因此,团队可以提出类似的观察

评论 含意/客观

检查RTM并检查从BRS到SRS的可追溯性。对于前。 BRS讨论了5条策略,但SRS仅提及了4条策略。

需要澄清和分类要实施的确切政策数量
检查是否为需求更改请求(RCR)定义了任何流程。 主要检查是否足够?质量检查团队在RCR管理流程中是否可以发挥作用?质量检查团队何时会知道任何RCR?

所有这些观察都应与相关团队和利益相关者讨论。我们还需要确保根据观察结果更新业务和系统需求文档。

因此,此步骤可确保要求明确,明确且完整。

2.设计质量保证(DQA)-适用于高级和低级设计

如果进行了彻底的“需求审查”阶段,那么可以确保设计&架构团队对创建设计即系统架构(高级设计或HLD)和低级设计(LLD)的需求提出了明确的要求。一旦高级设计或体系结构阶段结束,ELV团队将再次汇聚在一起,以执行设计质量保证,即DQA活动。期望ELV团队在技术,数据库,报告工具等方面具有良好的工作知识。该团队可以采用以下方法进行DQA

  • 根据业务/系统需求,列出我们需要验证系统架构的主要需求和优先级清单
  • 架构团队向ELV团队解释了系统的总体架构
  • 轻型电动车团队审核设计,以验证体系结构是否可以满足系统的预期业务需求。
  • 可以进行一些样本设计审核问题/观察
评论 含意/客观

在接口应用程序中,MyApp应该从7个数据库和5个系统中提取数据吗?但是架构图仅显示了7个数据库和4个系统。

检查并确保从所有相关接口提取数据。
在体系结构图中,没有显示用于“报告”的组件。但是在SRS中有一个单独的选项卡用于报告。 这是一个真正的小姐还是以不同的方式表示了相同的意思?

应该与相关团队和利益相关者讨论所有这些观察,并确保根据观察更新高级设计和体系结构文档。
因此,此步骤可确保高级设计和体系结构能够满足业务的技术需求和系统要求。

一旦详细的设计阶段结束,便可以采用类似的方法。在这种情况下,ELV团队可以计划以样本为基础对低级设计进行审核。因此,他们将要求体系结构团队指导他们完成一些关键功能的详细设计。一些示例审计问题可以是

评论 含意/客观

安全方面–有关银行信息–您是否需要额外登录才能为用户检索此信息?

检查安全性实施
基于触发的活动–例如-在各个日期关闭交易窗口时通过电子邮件发送邮件-如何实施?从哪里获取日期? 验证基于触发器的方法

应与相关团队和利益相关者讨论所有这些观察,并确保根据观察更新相应的设计文档。

因此,此步骤可确保底层设计和体系结构能够满足业务的技术需求和系统要求。

3.代码质量保证(CQA)

如果执行“设计质量保证”阶段,则可以确保构建团队正在就需要创建代码的设计进行清晰的设计。构建阶段结束后,ELV团队将再次集会以执行代码质量保证,即CQA活动。在这里,期望ELV团队拥有技术,数据库,报告工具等方面的工作知识。该团队可以采用以下方法进行CQA

  • 根据业务需求,列出最重要的需求和优先级清单,我们需要通过这些清单来验证代码中的实现
  • 开发团队将带领ELV团队完成关键代码实现,以实现ELV团队要审核的关键功能。
  • 轻型电动车团队审核代码以验证它是否可以满足系统的预期业务需求。
  • 轻型电动车团队还可以使用一些产品质量分析器工具,这些工具可以以统计方式分析代码以检查代码的结构质量。此类工具可以从各个方面创建有关代码运行状况的详细报告,例如可维护性,性能最佳实践,与安全相关的最佳实践,以及是否以优化方式编写代码等。
  • 有关CQA的一些示例审计问题可以是
评论 含意/客观

如果需求可追溯性矩阵是完整的,直到针对所有BRS需求的编码阶段为止

检查可追溯性
是否遵循基础语言的编码标准?有证据吗?一些填写清单? 确保工件中存在一致性和最佳编码实践
解释所得税计算的关键算法和逻辑。 尝试了解关键功能的基本逻辑

应该与相关团队和利益相关者讨论所有这些观察,并确保在代码中重新实施这些观察。
因此,此步骤可确保构建阶段考虑系统业务需求的所有重要方面。

4.小组审查测试范围,要求和策略

在上述3个流程中,我们看到质量检查团队对SDLC上游流程的可交付成果进行了审查,即需求,设计和编码。在这种实践中,STLC的上游阶段成果得到了其他相关利益相关方的验证。这是一个非常简单但功能强大的步骤,我们可以用来确保为系统概述的测试范围,测试要求和测试策略是适当的,并且与系统期望的结果保持一致。我们可以使用小组审查的方法。相关小组的所有利益相关者都可以执行此活动。质量检查主管可以协调此活动。应当检查捕获测试范围,测试要求,测试策略和方法的所有相关文档,以进行检查

  • 如果测试足够
  • 这些小组在测试方法中可以看到的任何明显问题
  • 选择测试策略
  • 正确理解测试范围和测试要求

此类小组审核的示例审核问题可以是

评论 含意/客观

质量检查人员选择的用于测试自动化的工具是“ X”,用于自动化的技术是“数据驱动”。但工具应为“ y”,所选技术应为“关键字驱动”

这是来自一组审阅成员的输入,基于她在其他类似项目中的经验,其中他们面临着工具X和“数据驱动”方法的问题。如果这次Fagan检查没有发生,那么他们的选择也将面临类似的问题

通过这次审查,可能出现的问题和障碍将会出现,并且质量保证团队将有机会在STLC阶段的开始阶段纠正这些问题,而不是这些问题遍历各个STLC阶段并在很晚的时间点发现。此外,每个子组的参与都可以确保为系统的每个部分提供足够且正确的测试方法。 

结论

如我们所见,通过采用上述简单但功能强大的技术(如下图所示),可以显着提高软件质量。

愚人节Oct22 2

我们可以在SDLC OT STLC的更早阶段发现这些缺陷,而不是在过程的末期发现它们。我们还看到了执行这些活动的样本投资回报率。所有相关利益攸关方必须采取一种协作方法,以使其有效。我们已经在其组织中实施这些项目的项目中看到了其好处。精选案例研究的这些好处如下

  • 改进了测试用例的准备和执行 生产率 在范围内 19-34%
  • 瑕疵 使用ELV技术检测到-范围从 600-750缺陷 (否则只有在质量检查时才能检测到)
  • 质量节约成本 在范围内 300 K USD为3。4 M USD
  • 关于 99-99.8% 测试有效性确保达到UAT /生产阶段时产品/应用程序的极高质量

Effort 和 cost incurred 进行这些活动的费用非常低,大约在10-40 K美元之间,因此我们获得了很高的投资回报率

因此,在测试任务中,这些方法被认为是最经济有效的早期生命周期验证方法。

不要忘记在下面留下您的评论。

参考文献

  • Infosys验证方法
Mugdha Divekar

Mugdha在Infosys Limited的IT行业拥有超过16年的经验。 她的软件开发和交付经验超过12年,并已加入软件工程流程小组约4年。她的软件交付经验包括各种领域(主要是金融服务,零售和物流),一系列技术(例如Microsoft技术,BI技术,Borland技术)以及一系列项目类型(包括开发,维护,过渡,测试,程序)管理处)。她的软件过程专业知识涉及各种类型的测试和验证服务,程序管理和帐户管理。她在印度浦那发表了有关SPIN活动的程序管理实践的演讲。

来自Mugdha Divekar的最新消息

©BA Times.com 2020

麦格雷戈徽标白色网站