你是否遵循了测试活动的最佳实践?
请谨慎行事。
最佳实践并不总是“最佳”的,它们并非你想象中的金科玉律,它们高度依赖于具体的项目情境。
在一种情境下效果极佳的方法,在另一种情境下可能会适得其反。
我将解释这一概念,剖析为何在测试环境中情境至关重要,并告诉你如何面对这些挑战。
为何不存在通用的“最佳实践”
“最佳实践”意味着它是一种万全之策。它表明,测试有一种普遍最优的方法,可以适用于任何情境。
但事实并非如此!
软件开发和测试是复杂的活动,它们受到各种因素的影响。这些因素可以是项目需求、团队氛围、利益相关者的期望和技术栈等。根据这些因素的不同,同样的实践可能会产生不同的结果。
以敏捷方法为例来说明这一点。
敏捷实践,如持续集成和持续测试,被广泛认为是最佳实践。然而,这些实践可能并不总是适合你。
在资源有限的小型初创团队中,由于成本或时间限制,实施一个功能完备的CI/CD流水线可能并不切实际。
这在大型企业中可能会有所不同。他们可能有多个团队在开发同一个产品,此时CI/CD几乎成了确保顺畅协作和快速交付的必需品。
作者/译者:Jayateerth Katti/Ares
来源网站名称:jayateerthk.medium.com
来源文章网址:https://jayateerthk.medium.com/testing-is-contextual-no-best-practices-please-d79f3fc93510
测试窝链接:
你正在遵循最佳测试实践吗?
请谨慎行事。
因为最佳实践并不总是“最好”的,它们并非你所认为的黄金准则。它们在很大程度上依赖于具体的测试场景。在一种情况下效果极佳的方法,在另一种情况下有可能会适得其反。
我将通过解释为什么测试场景在测试中至关重要来阐述这一概念,并告诉你如何面对这些挑战。
为何不存在通用的“最佳实践”
“最佳实践”意味着它是一种万能良药。
它还暗示着存在一种普遍最优的测试方法,且这种方法可以应用于任何情境。
但事实并非如此!
软件开发和测试是复杂的活动,它们受到多种因素的影响,这些因素可以是项目需求、团队动态、利益相关者的期望以及技术栈等。根据这些因素的不同,相同的实践活动可能会产生不同的结果。
以敏捷方法为例。
敏捷实践,如持续集成和持续测试,被广泛认为是最佳实践。然而,这些实践可能并不总是适合你。
在资源有限的初创型小公司环境中,由于成本或时间限制,实施一个完整的持续集成/持续部署(CI/CD)流水线可能并不现实。这在大型企业中可能会有所不同。大型企业可能有多个团队在开发同一个产品,此时,CI/CD几乎是确保顺畅协作和快速交付的必要条件。
来自我个人经历的一个例子
这里分享一个我职业生涯中的经历来说明这一点。
我当时正在参与一个项目。在这个项目中,我的团队负责测试一个特定的用户故事。该故事预期的功能正常工作。因此,我将其关闭了。测试期间我发现的缺陷已上报并与该故事相关联,这似乎是一种合乎逻辑且有效的方法。
这个流程在那个项目中运行得很好。我因此将其总结为一项“最佳实践”。
显而易见,对吧?
现在我开始参与一个新项目。在那个不同的项目中,我采用了同样的方法,但很快就遇到了麻烦。项目经理将问题升级了。原因令我警觉。他主张,只要与该用户故事相关的任何缺陷未解决,就不应关闭该故事,即使其主要功能运行正常。
他是正确的。原因是关闭一个用户故事可能会向开发人员传达出该功能已完成且已准备好投入生产的信号。这可能会导致缺陷被忽视或优先级降低。
这次经历给了我一个教训。
我认为在某种情境下是最佳实践的方法,在另一种情境下可能并不适用。项目的特定需求、利益相关者的期望以及衡量成功的方式,这些因素共同导致了我之前方法的失败。
接下来我们深入探讨……
理解测试中的不同情境的重要性
每个项目都可能有所不同。
因此,你的测试方法和流程会根据以下因素而有所不同:
- 项目要求
- 利益相关者的期望
- 所使用的技术
- 团队动态
- 风险承受能力
让我为你们逐一解释这些因素。
1. 项目要求各异
每个项目都是独一无二的。
它有着独特的要求、目标和限制条件。一种在某种情境下高效的做法在另一种情境下可能并不可行。
以这个为例:在一个时间紧迫的项目中,相较于彻底性,可能更优先考虑完成时间。这与那些将质量放在首位且时间不是限制条件的项目相比,必然要求采用不同的测试策略。
在我参与的一个项目中,我们正在开发一个关键的财务应用程序。利益相关者对缺陷零容忍。于是我们设定了一套流程:先开发测试用例,再进行审查。这些工作都是在产品准备好进行测试之前完成的。当产品准备好进行测试时,我们执行了这些测试用例。发现的任何缺陷都进行了上报。在接下来的后续版本中,我们测试了缺陷修复情况。在“预发布版本”上,我们运行了这些测试用例,作为回归测试的一部分。
现在,说说另一个项目。
我们当时正在开发一个社交媒体应用程序,这是一个风险较低的产品。客户更关心的是产品能否迅速推向市场。
因此,我们采用了不同的方法。我指示我的测试团队采用探索性测试,不提前开发测试用例。我们探索产品并只编写高级别的测试用例。回归测试同样采用探索性方法,结合了之前探索中已确定的测试场景。
2. 不同的利益相关者的期望
你的项目/产品将涉及不同的利益相关者。他们可以是项目经理、产品经理、开发人员和客户等。
他们分别有不同的期望。一些人可能更看重质量交付而非速度,而另一些人可能更关注满足紧迫的截止日期。你需要根据你的利益相关者优先级来调整你的测试方法。
看看这个例子。
我参与过一个项目,当时的产品经理非常注重细节。她坚持要求在产品发布前解决每一个Bug,无论它多么微不足道。产品经理的这种做法要求我们采取不同的测试方法。我们不得不投入大量的时间和资源来进行测试。这导致了发布的延迟,但确保了产品的高质量。
现在来看这个例子:
在另一个项目中,我与一个不同的客户合作。那位客户更关心快速部署。只要产品能迅速交付,客户愿意接受一些小的Bug。我们相应地调整了测试策略。那是基于风险的测试。我们专注于高优先级的测试领域,我和项目经理有意识地决定发布带有已知Bug的产品!
3. 技术栈和工具
现在来谈谈技术方面。
技术栈、工具和环境也会影响哪些实践活动是合适的。一种实践活动与一组工具配合良好,但可能无法与另一组工具顺利集成。
我记得另一个项目。我们当时正在使用一种特定的自动化测试工具,它非常适合进行应用程序的功能测试。但它并不适合用于另一个产品的测试。因为这款工具无法唯一地识别产品中的所有对象。
起初,我们尝试对这两个应用程序都使用相同的工具。因为我们认为标准化地使用单一工具集是最佳实践。
然而,结果并不理想。我们不得不切换到另一个更适合测试其他产品的自动化工具。
这次经历再次强调了这样一个教训:必须根据项目的具体需求选择合适的工具。
4. 团队动态
现在来说说人的因素。
你的团队可能有多名成员。团队成员的技能集、经验水平和团队动态都起着重要作用。与经验丰富的专家相比,初级测试人员可能需要采用不同的方法。因此,你需要根据你的团队的优点和缺点来定制你的实践方法。
我来举一个例子。
在我负责的一个项目中,我带领着一支初级测试人员的团队。我意识到,让测试人员自己编写测试脚本的传统方法并没有取得预期的效果。这些测试人员感到很吃力。这导致了错误频发,多次反复审查。
为了解决这个问题,我引入了一个带有可重用组件的功能库。这种方法帮助测试人员将注意力集中在业务测试上,而不是编写脚本上。这一调整提高了测试的质量和速度。
更重要的是,它减轻了测试人员的工作负担,也减轻了我的工作负担!
5. 风险承受能力
风险管理至关重要。
一些项目比其他项目更能承受风险。在高风险项目中,不进行任何省略的严格测试是至关重要的。但是,低风险项目可能会允许更快、不太彻底的测试方法。
我曾参与过一个医疗保健应用程序的项目。由于数据的敏感性和任何Bug可能带来的潜在影响,该项目对风险的承受能力极低。因此,我们实施了一个非常详细的测试流程,包括对代码库进行任何更改之前的多级审查和批准机制。
另一方面,在一个低风险的内部工具项目中,我们采用了更灵活的方法。我们加快了发布速度,并减少了全面测试。项目利益相关者理解并接受了与这种方法相关的风险。原因是该产品不面向客户,如果发现问题可以迅速更新。
通过这些例子,你现在可能已经感受到了测试工作是如何具有情境性的。测试过程并非处处相同,而是需要因境而异,因境制宜。
给大家的实用建议
基于我的经验,这里有一些建议给大家。
这些建议将帮助你适应测试的动态变化。
- 先评估情境
- 保持灵活性
- 与团队沟通
- 从错误中学习
- 寻求反馈
- 记录你的过程
让我稍微解释一下每一条。
1. 先评估情境
测试工作的情境至关重要。
在开始任何测试实践之前,先退一步。评估一下当前的情境。
了解:
- 项目的目标是什么?
- 技术栈是什么?
- 利益相关者有哪些?
例如,如果你正在处理一个时间紧迫的项目,你可能会优先考虑自动化测试来加快测试过程。
然而,在一个时间线更长、质量要求更高的项目中,你可能会更加注重全面测试,以确保全面覆盖。
2. 保持灵活性
要保持灵活性和适应性。根据当前的情境随时准备调整你的方法。
灵活性是测试中的一项关键技能。在一个项目中,我不得不从手动测试方法切换到自动化测试方法。这是在项目中途由于需求变更而做出的调整。这种灵活性使我们能够顺利实现项目的目标。
3. 与团队沟通
沟通是至关重要的。
确保团队中的每个人的信息都保持同步,讨论并商定适合当前项目的实践方法。请记住,之前在项目中奏效的方法这次可能需要进行调整。
在我领导的一个全球分布式团队的项目中,清晰的沟通至关重要。这是为了确保每个人都理解测试方法以及他们在其中的角色。我们定期召开会议,讨论进度、挑战以及测试策略中任何有必要的调整。
4. 从错误中学习
不断学习,不断学习,不断学习。
每个项目都会带来新的教训,利用这些经验来完善你对不同情境下哪些实践方法最有效的理解。为每个项目保留一份“经验教训文档”。
例如,在一个项目中遇到测试工具的问题后,我特别注意在未来项目选择工具之前对其进行彻底评估。这个持续的学习过程帮助我避免了再次犯下类似的错误。
5. 寻求反馈
听取他人的意见。
定期向你的团队和项目利益相关者征求反馈。他们可以提供宝贵的见解,这些见解有助于你根据项目的需求调整实践方法。
在一个项目中,我收到了开发人员的反馈,他们认为我们的测试方法太耗时,这减缓了整个开发进程。于是我们通过编写高优先级测试用例来实施探索性测试,从而调整了方法。这个过程提高了测试效率,且没有造成延误。
6. 记录你的流程
做好笔记。
在每个项目中,记录哪些方法有效,哪些无效。随着时间的推移,这将建立一个知识库,这个知识库可以在未来的项目中为你提供指导。
我开始维护一个测试指南,该文档包括我们使用的方法、面临的挑战以及我们是如何克服这些挑战的。这本指南在后续项目中成为了一项宝贵的资源,它帮助我和我的团队避免了之前犯过的错误,并在我们取得的成功基础上继续前进。
结论
测试并非一刀切的活动。
避免刻板地遵循所谓的最佳实践。相反,要专注于理解每个项目的独特背景。这样做,你将能够避免潜在的陷阱。同时,你也将自己定位为一位深思熟虑且适应能力强的测试人员,能够为任何团队增添真正的价值。
测试工作具有情境性,因境而异。如果理解了这一事实,你将更能轻松应对每个独特项目所带来的挑战。