实践系统思维以改进您的软件测试

2024-12-13   出处: ministryoftesting  作/译者:Konstantinos Konstantakopoulos/溜的一比

对被测系统及支持系统(如 CI/CD)的全面理解使我能够有效地测试系统,因为我对它们的内部工作了如指掌。凭借这些知识,我能够理解应用程序的运行方式,确定错误所在的位置,最重要的是,思考测试策略。

好消息:你已经是一个系统思考者了!
本文的灵感来源于塑造我软件测试方法的现实生活经验。简单来说:日常生活的活动需要你思考系统,无论是否涉及“技术”。一旦你意识到自己已经在进行系统思考,你就可以更深入地理解你在工作中测试的系统。

在你的日常生活中,你是否:

  • 规划餐食、采购食物、制定并遵守预算,并及时准备好晚餐?
  • 送孩子上学然后准时上班?
  • 修理家里的东西,或者学习如何引导他人解决明显的问题?

猜猜看:你已经是一个系统思考者了!这种能力在作为软件测试员时对你非常有用。但你可能需要发展这些技能,并比现在更深入地练习它。

面对“损坏”的系统:学习我的车库门

作为一个丈夫和父亲,我经常发现自己在解决家务问题,比如修理家里的东西或为儿子组装新玩具。但正是处理一个无法通过遥控操作的车库门促使我起草了这篇文章。我意识到,我处理这个问题的学习方法与我作为测试员处理学习情境的方法有很多相似之处。在寻求帮助或修理之前,我想了解事物的工作原理。

当车库门无法通过遥控器打开时,我首先在网上搜索其机制以及如何自行修复。但我也担心任何行动可能会使问题恶化。所以我打电话寻求帮助,但由于缺乏理解,我无法与维修专业人员有效沟通。他用我不了解的术语问我问题,令我们双方都感到沮丧。

于是,我继续搜索有关遥控操作车库门的信息。我发现门是通过连接到房屋电源的机械电机运作的。门在连接到电机的三条铁轨上上下滚动。虽然最终我需要一个维修人员来修理门,但我对其工作原理有了宝贵的见解,现在我能够深入地与维修人员讨论问题所在。我对未来处理门的问题也不再那么担心了。

系统思维的持续改进:当车库门再次损坏

果不其然,几个月后,车库门再次停止工作。这一次,它发出了巨大的噪音,让我觉得它已经无法修复了。第一次事件后我有的信心烟消云散,就像代码问题的修复在生产环境中停止工作时一样。

我再次打电话给维修人员,他们通过调整其中一条铁轨应用了另一个“热修复”。在维修过程中,我询问了有关问题、发生原因的问题,并观察维修人员的操作,以了解他们如何应用修复。

第二天,当我从学校接儿子回来时,我开始担心每天多次使用车库门。也许是频繁使用导致了它的故障。然后我意识到,我完全理解它的工作原理。我已经看到了内部部件,并了解它们如何协同工作。如果将来出现另一个问题,我认为我应该能够处理它,或者理解维修专业人员如何处理。

同样的逻辑也适用于我对软件测试的处理方式。

在软件测试中建立系统思维实践

有时候,我们的工作要求我们更深入地进行系统思考,无论我们是否认为自己已经准备好了。这就是我的经历。

一个好的开始:全面的产品知识

几年前,我在一家从50人团队成长到超过1000名员工的初创公司担任测试员(Beat,前身为Taxibeat,现在是FreeNow的一部分)。随着工程部门的扩展,团队开始负责特定领域以实现有效扩展。

当我加入公司时,我负责测试公司的移动应用程序,涵盖新功能计划时的回归测试,并为五个国家的移动应用程序执行回归测试周期。后来,我专注于乘客和司机移动应用程序的激励功能。

在我作为测试员的早期,我主要进行用户验收测试和功能测试。我使用Postman进行API测试,使用Selenium和Appium进行网页和移动UI测试自动化。我的最大优势是对我负责测试的产品领域有深刻的理解。

当深入的产品知识还不够时……

一切都很好,直到我们的团队负责一个新的产品领域。我突然感到迷茫。

我们必须通过一个新的微服务配置产品设置,该微服务连接到另一个从数据科学部门检索数据的服务。所有这些都是通过连接到旧的管理面板的后端单体管理的。而最终用户功能必须在iOS和Android移动应用程序中对出租车乘客和司机都可用。如果你在有多个集成点的管理面板中更改任何内容,就有可能完全破坏配置。

这种情况就像车库门一样——一个我需要在考虑任何测试计划之前彻底理解的未知系统。

拥抱对系统的深刻理解

理清系统配置的细节

我与经理讨论了我的担忧,我们一致认为,仅仅负责测试本身并不是一个足够的保障。我们决定我还应该“拥有”管理面板和微服务配置区域,以便我能够全面了解它们的工作原理。

我花了很多天时间学习管理面板设置,阅读所有可用的文档,并为每个服务绘制API端点图。我研究了数据科学团队如何通过Kafka事件将信息发送到微服务,并设置了一个连接到暂存环境的本地Kafka代理,以了解消息流。

然后,我将管理面板中的每个设置映射到我们移动应用程序使用的端点。这是最困难的部分,因为管理面板目前没有API文档。我获得了管理面板、后端和微服务的GitHub仓库访问权限,克隆了每个仓库并在本地运行它们,以了解每个设置背后的逻辑。

创建学习路径:探索产品代码

起初,我感觉自己不像一个软件工程师,但一步步地,这种感觉发生了变化。我开始学习git和版本控制,在我的笔记本电脑上安装了第一个集成开发环境(IDE),并使用Sublime等文本编辑器打开仓库并搜索代码。我学习了设计模式、事件驱动架构和微服务。我还探索了用PHP、JavaScript和Go编写的仓库,而我们的测试是用Java编写的,让我接触到了不同的编程语言和概念。

我培养了一种实验心态。如果有任何我不理解的东西,我会在网上搜索并咨询团队中的开发人员。我订阅了多个新闻通讯和博客,关注测试领域的专家,并开始每天学习工程概念。这种对工程世界和系统工作原理的深入研究成为了我的常态。我现在知道,持续学习和研究的日常承诺是测试员和工程师的必备技能。

在测试中建立系统思维的常规实践

今天,我定期深入研究我所工作的系统。我获取所有仓库、架构图、API文档、C4图和业务逻辑文档的访问权限。我尝试理解持续集成和交付(CI/CD)过程以及测试环境的部署方式。对被测系统及支持系统(如CI/CD)的全面理解使我能够有效地测试系统,因为我对它们的内部工作了如指掌。凭借这些知识,我能够理解应用程序的运行方式,确定错误所在的位置,最重要的是,思考测试策略。

我的系统思维实践导致了以下行动:

  • 我确保了解风险。我知道在代码的特定方面更改时应该覆盖的区域,了解哪些层次被测试,哪些没有被测试。
  • 我评估较低层次的测试覆盖,如应用程序代码中的集成测试。
  • 我了解我们是否在部署过程中包含任何端到端测试。按照规定,端到端测试描述的是一个业务流程或用户流程,这意味着我们需要在某个地方部署整个系统。
  • 我将验收标准和需求映射到测试场景。

正如Donella Meadows在《系统思考》一书中精彩描述的:

“一个系统的行为是其随时间的表现——其增长、停滞、衰退、振荡、随机性或演变。如果新闻在将事件置于历史背景方面做得更好,我们将对行为层面的理解更深入,这比对事件层面的理解更深。当一个系统思考者遇到问题时,他或她首先会寻找数据、时间图表、系统的历史。这是因为长期行为提供了对潜在系统结构的线索。而结构是理解不仅发生了什么,而且为什么发生的关键。”

测试员还是工程师?所有角色都需要良好的系统思维实践

阅读业务需求和验收标准对于理解客户需求至关重要,但这对于有效测试来说还不够。如果不了解系统,你将面临太多未知因素,拖慢团队进度。例如,有效沟通质量问题需要对系统有详细的了解,以准确定位问题。

曾经有几次,我在测试过程中识别出一个问题,认为它是一个缺陷,但后来发现这是由于测试设置在现实世界中不会发生的问题。对系统的这种更深入理解使我成为了一个更好的工程师。作为软件测试领域的专业人士,无论你的官方角色是什么,你都是负责系统质量的软件工程师。你必须从后端到前端了解系统的工作原理,以向客户提供最佳质量。

在我目前担任Orfium的首席测试工程师职位上,我强烈倡导一种结合了测试和工程思维的角色。这种方法反映在我们的招聘流程、职位发布、入职程序以及我们制定的指导方针中。公司内测试员的角色应与开发团队紧密集成,并成为工程部门的一部分。测试员必须彻底了解被测系统,以确保其与我们旨在服务的指导方针和使命保持一致。

良好的测试自动化依赖于严格的系统思维

沉浸于产品各组件如何交互可以显著提升你的测试自动化工作。以系统思维的心态来进行自动化检查——我更喜欢称之为自动化测试——可以增强你在测试计划和设计中的信心,从而产生有意义的测试。每次运行这些测试时,它们将允许你收集反映软件业务逻辑和实际用户流程的有价值反馈,使你能够在发布前后自信地传达系统的质量状态。最终,这有助于提升软件的整体质量。

随着软件的发展,持续维护测试自动化项目至关重要,以确保它们继续为你的团队提供有意义的反馈。拥抱系统思维使你具备有效实施、维护和扩展测试代码所需的技能。你将乐于探索诸如为什么要测试、测试什么、如何测试以及何时在团队的CI/CD流程中运行测试等重要问题。

培养基于系统思维的心态不仅提升了测试自动化的效率,还激励了团队的工程师们采用这种方法,显著改善了组织开发软件的整体质量。

总结

像为家庭规划一周的餐食或排除遥控操作车库门故障一样,深入理解系统的纪律对于有效的软件测试至关重要。你应该努力每天对应用程序进行实验并学习新知识,渴望学习并重新思考测试软件的方式。

这种积极的心态,以及好奇心和成长心态的实践,可以渗透到你的团队中。通过它,你可以体现出测试工程师的真正本质。

更多信息

  • 《测试部社区的批判性思维指南》
  • Michaela Greiler 的《大型软件系统测试的障碍》
  • Mark Winteringham 的《自动化分解:通过任务分析告别全栈测试》


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
20° /203 人阅读/0 条评论 发表评论

登录 后发表评论
最新文章