测试员=背锅侠?测试员:这个锅我不背
2018-01-10 18:39
162 查看
在很多团队,测试人员的定位就是质量保障,这就导致了项目如果质量出现问题,那么测试同学首席背锅侠的命运是无法逆转的。(更多精彩内容请戳:必看!那些年软件测试员踩过的坑)
开发团队水平高
水平高的开发团队往往产品质量会好,如果在高水平开发团队中担任测试是一种大树底下好乘凉的体验。
开发提交的代码往往缺陷少,正常和异常流程的表现大都合理,可能细节还要推敲,不过总的来说项目会给人一种很稳的感觉。
高水平的开发团队中,信息往往是对称的。比如有1个需求,开发在实现的时候,测试同学都可以提出自己的一些疑虑,比如异常情况的处理,数据的有效性校验建议,数据一致性保障建议等。
一些需求里不清楚的东西在开发过程中就可以讨论清楚,不需要等到提测之后再确认。
水平一般的开发团队
在水平一般的开发团队当测试人员大概应该是这样的一种体验,开发大部分的活干的中规中矩,没有极大的失望,但是也没有惊喜信息不算太透明。
开发跟测试表面上合作沟通,实际上各自为战测试同学在提测的时候大概都知道会出什么问题,优先测这些问题。
如果发现很多就把这个版本给打回去偶尔会出现因为环境问题而导致测试无法按时进行下去的情况。
如果让整个团队都遵循一定的流程,项目质量往往会有所提高测试同学多发现一些bug,项目的质量往往有所提高产品/项目发布上线的时候,心里可能会惴惴不安,如果有问题遗留到线上心中反而长舒一口气,该来的总是要来。
水平低于一般的开发团队
在这样的团队里,你会发现信息极度不透明,开发人员憋大招,测试同学在此期间有点无所事事提测难产,会因为各种各样的问题造成项目无法提测。
比如环境问题质量意识淡薄,开发可能在上线前临时改代码修复问题而不通知测试同学开发负责按时交货。
出了质量问题,嗯,那应该是测试的责任,谁让他们没测出来产品/项目发布上线的时候,测试同学可以拜拜神,反正心中没谱,只能靠老天保佑。
如果质量都靠开发来保证,那么测试做什么?
如果所有的质量都靠开发来保证,那么测试同学做什么?
其实也不是所有的质量都靠开发保障,一些产品项目往往需要有对业务相当熟悉的人站在整体的角度去评估某些逻辑是否合理,一些操作带来的问题是否会影响到用户之类的。
这种人可以是产品人员或BA,不过很多情况下,产品人员不专注于找茬挑毛病,于是从更专业化的角度上讲,这些活就落在了测试同学的身上。
既然你要我给你挑毛病,那么至少你需要保证产品或系统是可以测试的,这基本的诚意,开发团队是多少要拿出来的。
如果开发团队的水平高,测试人员可能不需要特别努力就能让产品维持在一个相对可以接受的质量水平上;
如果开发团队的水平一般,测试人员需要相当努力就能让产品维持在一个相对可以接受的质量水平上;
如果开发团队水平低,测试同学打了鸡血一样的测试可能也于事无补;
在团队中,测试需要做什么?
在开发能力相对不强的团队,测试同学需要做到以下几点:
推动一些流程管理,比如bug生命周期和提测发布流程之类的,起码让项目质量管理有一个底线;
推动开发团队吸收一些水平相对较高的成员,在规模不算太大的开发团队,大神光环对质量提升非常有帮助;
有时间多学一些能有核心竞争力的能力,说不定哪一天需要被锅走人;
最关键的一点:尽量消除信息不对称,最好知道开发每天在做啥,让开发告诉你他在做什么,写代码的时候就给开发一些建议,不要把希望寄托在提测后的测试周期,要知道,这个周期往往是会被拼命压缩的;
好的产品经理一定有非常优秀的缺陷发现能力,尽量争取到同一阵营;
增加测试人力,多个人多测一点总没坏处,人多自己被锅的概率也会相对小一点。
测试同学打了鸡血一样的拼命测试就一定可以保障项目的质量吗?
不一定,这需要看开发团队的整体水平:开发团队水平高
水平高的开发团队往往产品质量会好,如果在高水平开发团队中担任测试是一种大树底下好乘凉的体验。
开发提交的代码往往缺陷少,正常和异常流程的表现大都合理,可能细节还要推敲,不过总的来说项目会给人一种很稳的感觉。
高水平的开发团队中,信息往往是对称的。比如有1个需求,开发在实现的时候,测试同学都可以提出自己的一些疑虑,比如异常情况的处理,数据的有效性校验建议,数据一致性保障建议等。
一些需求里不清楚的东西在开发过程中就可以讨论清楚,不需要等到提测之后再确认。
水平一般的开发团队
在水平一般的开发团队当测试人员大概应该是这样的一种体验,开发大部分的活干的中规中矩,没有极大的失望,但是也没有惊喜信息不算太透明。
开发跟测试表面上合作沟通,实际上各自为战测试同学在提测的时候大概都知道会出什么问题,优先测这些问题。
如果发现很多就把这个版本给打回去偶尔会出现因为环境问题而导致测试无法按时进行下去的情况。
如果让整个团队都遵循一定的流程,项目质量往往会有所提高测试同学多发现一些bug,项目的质量往往有所提高产品/项目发布上线的时候,心里可能会惴惴不安,如果有问题遗留到线上心中反而长舒一口气,该来的总是要来。
水平低于一般的开发团队
在这样的团队里,你会发现信息极度不透明,开发人员憋大招,测试同学在此期间有点无所事事提测难产,会因为各种各样的问题造成项目无法提测。
比如环境问题质量意识淡薄,开发可能在上线前临时改代码修复问题而不通知测试同学开发负责按时交货。
出了质量问题,嗯,那应该是测试的责任,谁让他们没测出来产品/项目发布上线的时候,测试同学可以拜拜神,反正心中没谱,只能靠老天保佑。
如果质量都靠开发来保证,那么测试做什么?
如果所有的质量都靠开发来保证,那么测试同学做什么?
其实也不是所有的质量都靠开发保障,一些产品项目往往需要有对业务相当熟悉的人站在整体的角度去评估某些逻辑是否合理,一些操作带来的问题是否会影响到用户之类的。
这种人可以是产品人员或BA,不过很多情况下,产品人员不专注于找茬挑毛病,于是从更专业化的角度上讲,这些活就落在了测试同学的身上。
既然你要我给你挑毛病,那么至少你需要保证产品或系统是可以测试的,这基本的诚意,开发团队是多少要拿出来的。
如果开发团队的水平高,测试人员可能不需要特别努力就能让产品维持在一个相对可以接受的质量水平上;
如果开发团队的水平一般,测试人员需要相当努力就能让产品维持在一个相对可以接受的质量水平上;
如果开发团队水平低,测试同学打了鸡血一样的测试可能也于事无补;
在团队中,测试需要做什么?
在开发能力相对不强的团队,测试同学需要做到以下几点:
推动一些流程管理,比如bug生命周期和提测发布流程之类的,起码让项目质量管理有一个底线;
推动开发团队吸收一些水平相对较高的成员,在规模不算太大的开发团队,大神光环对质量提升非常有帮助;
有时间多学一些能有核心竞争力的能力,说不定哪一天需要被锅走人;
最关键的一点:尽量消除信息不对称,最好知道开发每天在做啥,让开发告诉你他在做什么,写代码的时候就给开发一些建议,不要把希望寄托在提测后的测试周期,要知道,这个周期往往是会被拼命压缩的;
好的产品经理一定有非常优秀的缺陷发现能力,尽量争取到同一阵营;
增加测试人力,多个人多测一点总没坏处,人多自己被锅的概率也会相对小一点。
相关文章推荐
- 给定一个日期,输出这个日期是该年的第几天。 C语言来做
- lastIndexOf() 找出指定元素出现的所有位置(返回的是下标数组)---lastIndexOf() 这个方法是倒叙查找,正序的是indexOf()
- 静下心面对这个浮华的时代
- 【PAT_Basic日记】1002. 写出这个数
- CubeDragBannerView增加了下面这个方法后可以把下拉事件传递下去
- JVM调优总结(这个总结得比较全面)
- 用我账号的哥们 别随意留言 谢谢 这个账号有特殊意义
- 怎样 配置这个网络拓扑
- C语言:返回两个数组中第一个元素的指针,并输出这个值
- 题目:有一分数序列:2/1,3/2,5/3,8/5,13/8,21/13...求出这个数列的前20项之和。(java)
- 指针数组 与 数组指针(假如有这个东西的话)
- ipc连接时出来这个提示: 不允许一个用户使用一个以上用户名与一个服务器或共享资源的多重连接。中断与此服务器或共享资源的连接,然后在试一次...
- win10无法打开这个应用解决办法
- 为什么数据库主键不要自增,而要用UUID这个类
- 进入了这个社团
- 12306官网自动刷票5秒太慢了,试试这个方法提速
- 该不该玩这个游戏
- 编写多线程程序,模拟多个人通过一个山洞。这个山洞每次只能通过一个人,每个人通过山洞的时间为2秒(sleep)。随机生成10个人,都要通过此山洞,用随机值对应的字符串表示人名,打印输出每次通过山洞的人名
- 现在这个新的CSDN网站做的很烂,真的很烂,很差
- 1. Src:该目录中存放的是该项目的源代码,这个目录包含了你即将创建的Java源代码文件,这个目录里的文件是根据package结构管理的,它与普通java项目中的/src目录很相似。 2.Gen: