小型团队的测试该何去何从

简介: 版权声明:欢迎转载,请注明沉默王二原创。 https://blog.csdn.net/qing_gee/article/details/43634971 很不幸,我不知道自己应该...
版权声明:欢迎转载,请注明沉默王二原创。 https://blog.csdn.net/qing_gee/article/details/43634971

很不幸,我不知道自己应该不应该谈论这件事,“小型团队的测试该何去何从”,我没有十足的经验,更没有十足的理论,然而回想起昨日大家一起的讨论结果,我到现在依然沉浸在失望和苦闷的滋味中,究竟是增强开发人员的自测能力以及自我驱动力还是增加测试人员来做问题的过滤?


首先,我们先抛开需求分析,为什么这么重要的环节要先抛开,因为国内的小型团队面临着无法避免的严重问题:

  1. 客户压根不懂需求,遇到一个稍微懂一些需求的客户,那都是上天对你的恩赐。
  2. 时间太过紧迫,经常在客户眼里,这个什么功能简单的很,实现起来不就是一会儿时间的问题,都不需要什么技术。
  3. 迫于市场压力和成本考虑,前期做大量的需求分析压根无从下手、也容不得你多做考虑。

当然,我们小型团队依然会做需求分析,只是占比太少,我们必须快速迭代,交出产品,让客户依据我们的做出的产品衡量他的需求。那么问题来了,在快速开发的过程中,如何保证软件质量呢,也就是所谓的测试,如何进展。


我在会上提出了自己这样的观点,从开发人员做起,而不是从需求分析处找问题,更不是留到测试人员找问题。怎么从开发人员做起,那就是增强开发人员的自测能力,使开发人员的效率最大化。在小型团队中,开发人员才是团队的核心竞争力,开发人员必须具有强大的自我驱动力,并且要海纳百川,需要做的不是照着可能已经存在问题的需求分析书敲代码,也不是自我感觉良好不进行代码的自我review,更不是极不情愿的不去做代码测试、集成测试。然而我这样的观点在会上受到了严重的歧视或者反对,有如下观点:

  1. 你所处的产品环境和我们组有着巨大的差别,你所处的环境中,你们组每个人对自己的模块很清楚,而我们组每个人对彼此的模块不清楚;你们组的代码量加起来不及我们组的十分之一,你所能看到的问题不能和我们组相提并论。
  2. 我们开发人员无法做太多的测试,因为在我测试的时候,可能数据库表结构都不存在了,其他人压根不会告诉我,你让我怎么测试,我只能留到测试人员发现。
  3. 由于需求经过多次传递,需求在开发人员处已经不再明确,开发人员必须按照自己的理解去做出结果,开发人员没有责任,需求分析也没有责任。
  4. 测试人员其他工作过多,导致不能把所有的时间用来做测试。

而所总结出来的解决方案是,开发人员自测虽然是个好观点,但是可实施性不大,减少测试人员的其他工作,专心做测试,如果一个人员不够增加人员。


对于以上观点和理由,我不做过多评价,我想是我自己鼠目寸光,见识短浅,没有去体会别组的难处。也许在他们眼里,我们组的情况是这样的“项目复杂度远远不够,人少问题就少,并且每个人都懂得其他人的模块”。


 我很失望,我失望的不是自己的观点得不到认同,而是我们项目组的很多成员无法意识到自己的问题,这样久而久只会积劳成疾。我不是说自己有多优秀,我自己从前也厌恶做测试,测试不就是测试人员的专利嘛,我干嘛要自己测试,况且很多人开发的模块我也不清楚,我干嘛去了解其他人的开发内容,况且那么复杂,我根本了解不到,况且很多问题都是需求上出现了问题,又不是我自己的责任。


在现实中,是这样的。就我自己而言,我接到我目前的项目马上就有一年的时间了,在这期间,领导给予了我很大帮助,我的同仁们也给予了我很大帮助,时至今日,基本上能够把控整个期货交易平台的开发以及质量。我们组从一开始就没有需求分析师,更没有所谓测试人员,如何能做到问题越来越少呢,我想这多半和自己的些许努力是分不开的。我刚接手项目时,项目虽然已经上线运行,但是存在问题我都不敢回首。期间两个原来开发的核心成员都早早的离职了,我必须承担很多角色,以前别人说,我们小组人员少,所以在敏捷开发中的角色定位也就不存在任何问题,一人身兼多职理所当然。我要做需求分析,和客户讨论,自己琢磨方案,自己参与调查,参与架构,参与大量的开发工作,尤其是还有大量的测试工作,然后还有不停的修改bug,我曾经很痛苦为什么我要帮别人擦屁股,为什么我的成员对自己的代码如此不负责任,几乎都是一遍开发,能够自测是我不能太多奢求的。那么这就要求我,要做好自测,同时做好其他人的测试,当然我自己开发的也曾在上线后出现低级的问题,这也更加锻炼了我的自测能力。


我认为,小型团队,如何调度开发人员的效率最大化,才是公司发展的最强生命力。很多时候,很多成员抱怨自己时间多么紧迫,任务多么积压,但是我所看到的现象是,大多数时间成员无所事事,也许如果我们组一开始也有一个测试人员,那么我也会形成一种他人测试的依赖症。虽然我不能说我们小组的测试有多么好,成员的自测能力有多强,我只是想让团队推广“自测”、“自我驱动力”的意识,然而这种观点并没有多少人认可。


总结:说了上面这么多废话,有些话也不知道自己应该说不应该,把这些事情记录下来,不是抱怨团队,而是为自己立下警钟,无论以后身处何地,必须高举“自测”、“自我驱动力”的旗帜,而不是抱怨需求分析没做好,然后把问题留给测试人员,更不是归咎于项目的难度而去规避开发人员的责任。

相关文章
|
7月前
|
安全 测试技术
测试团队的一次复盘实践
测试团队的一次复盘实践
239 0
|
2月前
|
安全 测试技术
北大李戈团队提出大模型单测生成新方法,显著提升代码测试覆盖率
【10月更文挑战第1天】北京大学李戈教授团队提出了一种名为“统一生成测试”的创新方法,有效提升了大模型如GPT-2和GPT-3在单一测试中的代码生成覆盖率,分别从56%提升至72%和从61%提升至78%。这种方法结合了模糊测试、变异测试和生成对抗网络等多种技术,克服了传统测试方法的局限性,在大模型测试领域实现了重要突破,有助于提高系统的可靠性和安全性。然而,该方法的实现复杂度较高且实际应用效果仍需进一步验证。论文可从此链接下载:【https://drive.weixin.qq.com/s?k=ACAAewd0AA48Z2kXrJ】
78 1
|
3月前
|
人工智能 测试技术 开发者
北大李戈团队提出大模型单测生成新方法,显著提升代码测试覆盖率
【9月更文挑战第27天】北京大学李戈团队在人工智能领域取得重要突破,提出HITS新方法,通过将待测方法分解为多个切片并利用大型语言模型逐个生成测试用例,显著提升代码测试覆盖率,尤其在处理复杂方法时效果显著,为软件开发和测试领域带来新希望。尽管存在一定局限性,HITS仍展示了巨大潜力,未来有望克服限制,推动软件测试领域的创新发展。论文详情见【https://www.arxiv.org/pdf/2408.11324】。
137 6
|
2天前
|
数据采集 人工智能 自动驾驶
VSI-Bench:李飞飞谢赛宁团队推出视觉空间智能基准测试集,旨在评估多模态大语言模型在空间认知和理解方面的能力
VSI-Bench是由李飞飞和谢赛宁团队推出的视觉空间智能基准测试集,旨在评估多模态大型语言模型(MLLMs)在空间认知和理解方面的能力。该基准测试集包含超过5000个问题-答案对,覆盖近290个真实室内场景视频,涉及多种环境,能够系统地测试和提高MLLMs在视觉空间智能方面的表现。
32 16
VSI-Bench:李飞飞谢赛宁团队推出视觉空间智能基准测试集,旨在评估多模态大语言模型在空间认知和理解方面的能力
|
安全 Java 测试技术
带你读《2022技术人的百宝黑皮书》——大淘宝用户平台技术团队单元测试建设(1)
带你读《2022技术人的百宝黑皮书》——大淘宝用户平台技术团队单元测试建设(1)
128 0
|
7月前
|
敏捷开发 人工智能 机器人
【测试】无测试组织:测试团队的敏捷转型
【测试】无测试组织:测试团队的敏捷转型
123 0
|
7月前
|
敏捷开发 测试技术 项目管理
在如今的大环境下你是否选择测试岗?——打造敏捷测试团队
在如今的大环境下你是否选择测试岗?——打造敏捷测试团队
|
9天前
|
监控 JavaScript 测试技术
postman接口测试工具详解
Postman是一个功能强大且易于使用的API测试工具。通过详细的介绍和实际示例,本文展示了Postman在API测试中的各种应用。无论是简单的请求发送,还是复杂的自动化测试和持续集成,Postman都提供了丰富的功能来满足用户的需求。希望本文能帮助您更好地理解和使用Postman,提高API测试的效率和质量。
49 11
|
1月前
|
JSON Java 测试技术
SpringCloud2023实战之接口服务测试工具SpringBootTest
SpringBootTest同时集成了JUnit Jupiter、AssertJ、Hamcrest测试辅助库,使得更容易编写但愿测试代码。
65 3
|
2月前
|
JSON 算法 数据可视化
测试专项笔记(一): 通过算法能力接口返回的检测结果完成相关指标的计算(目标检测)
这篇文章是关于如何通过算法接口返回的目标检测结果来计算性能指标的笔记。它涵盖了任务描述、指标分析(包括TP、FP、FN、TN、精准率和召回率),接口处理,数据集处理,以及如何使用实用工具进行文件操作和数据可视化。文章还提供了一些Python代码示例,用于处理图像文件、转换数据格式以及计算目标检测的性能指标。
80 0
测试专项笔记(一): 通过算法能力接口返回的检测结果完成相关指标的计算(目标检测)

热门文章

最新文章