像测试人员一样思考

简介: 像测试人员一样思考

大家好,我是阿萨。作为测试人员,测试的时候该如何思考?请看下文。


测试不是与生俱来的技能,也不是只有少数幸运儿才能继承的稀有基因。人类并不是天生的测试人员。


测试也不是简单的死记硬背就可以了。任何人都不可以用小抄和一些时间来死记硬背成为一名测试。


测试是一个有深度和挑战性的领域,需要实践和经验才能做好。这也是一项有些人似乎比其他人更擅长的活动——有些人似乎只是有一种“测试者思维”……他们“像测试者一样思考”。


这种思维是什么?你如何培养和发展这种思维?


以下是我发现的优秀测试员与众不同的5个特点。所有这些都很容易掌握,但很难精通,任何愿意投入时间和精力的人都可以学习。

注意:我使用术语“测试人员”泛指任何想要执行测试活动的人,在我看来,应该是每个人。这篇文章并不是提倡专门的“测试人员”或者只有测试人员进行测试——这是一个完全不同的、更广泛的讨论。


逆向思维与举证责任


我的第一个老板告诉我:“当你测试软件时,就假设有bug。如果你以软件应该工作的方式来处理软件,然后试图找到bug,你不会发现很多。你会看到你想看到的。然而,如果你假设bug存在,如果你说服自己它们确实存在,你就会突然发现它们无处不在。”


这条简短的建议完美地概括了“倒置举证责任”的思想。在测试软件时,必须先假设软件不能工作。事实上,这根本行不通。很难想象它会起作用。这不仅是错误的,而且是完全错误的。有人实际上是在试图欺骗你,把这个软件冒充“工作”。也许你被人耍了。


有了这样的理解,就强迫软件向您证明是错误的。让它执行每一个动作,展示每一个行为,直到它可以毫无争议地说服你,这不是一个骗局。奇迹中的奇迹,它实际上是一个可以工作的软件。


换句话说:在证明软件无罪之前,应该假定软件有罪。

优秀的测试人员用这种颠倒的心态来对待软件——他们假设最坏的情况,然后从最坏的情况出发。你可以称之为健康的怀疑主义,建设性的悲观主义,或者其他一些术语或短语,但它归结为一种假设,即所有软件都不能工作。从这里开始,并迫使软件证明事实并非如此,这有助于对抗自然的确认偏见,并帮助优秀的测试人员发现可能会从其他人那里溜走的错误。


反转思维并不仅限于软件测试,它在从数学到投资的各个领域都有自己的风格和支持者。每个人都可以学习它(即使是最乐观的开发人员!)。


同理心和角色扮演


从别人的角度看世界,理解他们的经历,感受他们的感受,这种能力并不容易。事实上,这是高情商的标志,在测试软件时,这是一种非常有价值的心态技能。


优秀的测试人员能够想象自己站在用户的角度,预测他们可能会做什么,他们可能会如何困惑,或者他们为什么会感到沮丧。深入理解用户并模拟他们的行为可以让测试人员在bug逃逸并给实际用户造成实际问题之前发现它们。


用户同理心不仅仅是“他们想要订购一本书,所以我也会订购一本书”。它是了解用户的心态、动机、历史和目标。这通常需要研究和想象力。


我遇到的最接近的相关技能是创造性角色扮演(如:表演、话剧、即兴喜剧等)。这些都是“换位思考,把自己想象成他们,并采取相应的行动”。在某种程度上,这些都是在练习同理心。


是的,我的意思是,在你的队伍探索巴托九地狱的过程中扮演矮人牧师会让你成为一名更好的测试员。


具有挑战性的假设


这个短语经常被用来描述测试心态,以至于它已经变味é,失去了它的很多意义。挑战假设不仅仅是大喊“为什么?”就像一个任性的五岁小孩。还有比这更多的事情,像其他事情一样,它需要练习。


“挑战假设”并不意味着“挑战每一个假设”。这并不意味着把所有东西都扔出窗外,从头开始。作为测试员,我们不需要像Bertrand Russell那样花360页去证明1 + 1 = 2。


事实上,识别和利用假设对于成为一个有效的测试人员是至关重要的。当您坐下来测试一个重要应用程序中的一些新功能时,几乎有无限数量的可能操作或路径可以测试,这些操作或路径可能导致错误。假设正是您用来将可能测试的无限范围缩小到最有可能发现问题的合理集合的。假设是缩小范围的工具,假设是有价值的。

关键的技能是能够准确地评估假设,以确定它们是否正确地指导了您的行为,或者它们是否将您引入歧途。这些假设是有害的还是有益的;他们是否允许你放弃低风险的领域,而支持更有利可图的测试,或者他们是否在想法背后隐藏了有效的担忧,比如我们不需要测试,那不可能发生?


“挑战假设”把这一点简单化了——你不是在盲目地挑战假设,你是在利用所有可以利用的工具来更好地理解挑战哪些假设,何时挑战它们,以及如何挑战它们。


例如:“我们的应用程序利用了这个开源库……我不会只是假设它可以工作,我也会测试它!”这可能是一个不太有价值的假设,可能会浪费时间。然而,在图书馆周围做了一些调查(它已经被数百万人使用了吗?还是它是由大学里的某个孩子创建的?)它有一个活跃的社区吗?您是冻结版本,还是在开发过程中增加版本?)可能是完全合理的。

测试人员的心态不断地识别和评估假设,以确定这些假设是否有效和有价值,或者误导他们的测试活动。


然而,不要认为你会做对。


直觉思维和探索行为


如果测试可以提炼成一个简单的操作列表,我们就不需要测试人员了。即使它可以简化为基于有限输入集的可预测的、确定的步骤集(例如,验收标准和SUT),我们仍然不需要测试人员。测试是一种非线性的、不可预测的活动。它需要批判性思维,创造力,依赖于本能和直觉,因为它需要算法执行行动。测试在本质上通常是探索性的——当你开始时,你并不完全知道你要去哪里。优秀的测试人员接受测试的直觉性和探索性。

将它与它的对立面进行对比,就更容易理解我们所说的意思,不幸的是,这种观点仍然存在于某些圈子里。这是如何进行的:“测试是通过基于边界分析、等价类、组合分析和其他形式的测试用例生成策略,为每个AC开发测试用例列表,来验证给定故事中验收标准的枚举列表。一旦创建了完整的测试用例列表,测试人员就会运行它们,并记录哪些通过了,哪些失败了。”

对于持有这种观点的人来说,测试是一组直接的、可预测的活动。在开发测试用例时可能需要一些技巧,但是考虑到这一点,您可以将这些说明提供给任何人。一旦你想出了这些测试用例,你甚至在开始之前就知道你要测试什么。


正如我刚才所说,现在业界还有一些人持这种观点。我不太确定为什么,因为大多数有实际测试经验的人都反对它。我有一种预感,一些经理喜欢它,因为它将测试简化为一种容易商品化的活动——他们认为,这种活动可以被分割,然后分发给出价最低的人。


我可以用接下来的20页来描述测试的探索性和直觉性,但是许多有经验的测试人员(可能还有更好的作者)已经这样做了。我强烈推荐探索它!Elisabeth Hendrickson和James A. Whittaker的探索性软件测试。Lisa Crispin和Janet Gregory的《敏捷测试和更敏捷的测试》涉及到这个主题,但是更广泛地讨论了敏捷团队中测试人员的角色。最后,詹姆斯·巴赫和迈克尔·博尔顿经常在这个话题上充满激情地写作。我特别推荐这篇文章。

无论您将其称为深度测试或结构化探索性测试或其他短语,都无关紧要。真正重要的是这样一种心态:测试需要实时的实际思考,测试活动和方向必须不断地重新评估,并随着新的理解的获得。它不是接受标准的算法外推,也不能预先计算。

作为一名测试人员,您必须在没有完整的路线图的情况下开始我们的旅程。测试的这种不可预测和不可知的方面让一些人感到不安,但我发现伟大的测试人员似乎在这方面茁壮成长。


人性的认识


作为测试人员,您要测试软件,但要牢记软件只是一个长期过程的最终产品。这是一群人随着时间的推移合作,创造出比他们任何一个人单独创造的更大更复杂的东西的最终结果。


软件中的缺陷不是凭空出现的,它们是开发过程中出现问题的征兆。因此,作为一名测试人员,您需要关注软件开发过程以及其中人员的行为,就像您需要关注最终的软件产品一样。


如果你研究人类的本性,你很快就会意识到人类远不是具有完美记忆力、动机和注意力的确定性机器人。事实上,我们恰恰相反。

人类会分心,健忘,无聊。我们会感到沮丧、烦恼和疲惫。我们嫉妒别人的成功。我们有自己的议程、野心和人生目标,其中为这家公司开发这个特定的软件可能甚至排不上前十。我们中的一些人被金钱所激励,一些人被酷炫的技术所激励,一些人被有趣的领域所激励,一些人被社会的肯定所激励,而根据一个虚构的反派人物的说法,有些人只是想看着世界燃烧。

最重要的是,人类的思维是启发式的,并且经常采取捷径或倾向于有助于作为塞伦盖蒂哺乳动物生存的模式,但在构建软件时就不那么有用了。行为科学家将这些捷径称为“认知偏差”。例如,人类倾向于看到并接受与现有信念一致的证据(确认偏误),一旦我们投入了努力,我们就很难改变方向(沉没成本谬误),我们过度强调容易想到的证据(可用性偏误),我们执着于看到的第一个证据(锚定偏误)。这些只是几个例子;有很多。


人类行为中的所有这些缺点都存在于软件开发中,就像它们存在于人类的其他经验中一样。当开发人员开发时,当业务分析师分析时,当高管执行公司战略时,当中层管理人员....时,他们都在场中层管理。

当您坐下来测试软件时,请理解您正在查看受这些偏见、倾向和缺点影响的人类活动的最终产品。您正在寻找的bug通常是这些问题的症状,而不仅仅是开发人员错误地实现了一个已知的算法或需求。了解和理解创造软件的人类机器将帮助你发现它们。


带着这种心态进行测试,软件开发的根源是混乱的人类协作,并遭受人类努力的所有正常失败。


相关文章
|
7月前
|
监控 测试技术 开发者
测试人员日常工作都做什么?
测试人员日常工作都做什么?
|
4月前
|
运维 监控 测试技术
漫谈测试策略
本文以团队内约定俗成的测试策略概念为主题,总结了一些个人经验和思考结论,可能对其他业务/团队而言,存在术语定义不一致,希望对大家有参考意义,欢迎探讨,感谢理解。
|
4月前
|
测试技术 持续交付 网络安全
测试策略的实现
测试策略的实现
49 0
|
5月前
|
测试技术
软件交付问题之为什么测试用例不能全由开发人员告知测试人员
软件交付问题之为什么测试用例不能全由开发人员告知测试人员
|
7月前
|
测试技术 数据安全/隐私保护 UED
测试人员需求分析都做什么
测试人员需求分析都做什么
|
7月前
|
人工智能 Java 测试技术
测试人员如何提升自己的测试技能?
测试人员如何提升自己的测试技能?
255 0
|
7月前
|
安全 测试技术
测试人员是如何分工的?
测试人员是如何分工的?
914 0
|
机器学习/深度学习 存储 测试技术
软件测试:单元测试和系统测试
1)自动生成的CalculatorTest类 (2)修改和完善Calculator类 (3)Point2d的测试用例 (一)修改之前的Calc
80 0
|
测试技术 程序员
软件工程——软件测试(黑盒测试、白盒测试、测试分析报告)
经过前面软件测编码阶段,是不是我们就可以把软件发布出去供用户使用了呢?不是的,为了确保软件不会出现不必要的差错,还需要经过重重测试的。
|
测试技术
测试人员的质量观
提升技术很快,改变观念很难~
111 0
测试人员的质量观

相关实验场景

更多