【3019】为什么不开除测试,让用户来

前些日子,在知乎上看到一个很有趣的问题:

 

为什么互联网公司不开除测试,转而让大众来测,找到一个Bug给100元?我一时脑洞大开,请做测试的大牛来说道说道。

为什么不开除测试,让用户来
为什么不开除测试,让用户来

 

回答的讨论也很有意思,有不少都是围绕“100块够不够、给不给、怎么给”来说的,我的角度是,测试绝对是产品团队里一个重要的角色(注意,不是自然人,创业团队可能就是产品经理来做这个角色),没了他们还真的不行,回答如下:

 

  • 默认前提是,开发已经做了单元测试冒烟测试(原则上冒烟应该测试来做,但,人家都被你们开除了啊,只好让开发来做了,至少保证交给大众的是一个能跑起来的产品),这两项总不至于期望大众来帮忙做吧;
  • 很多Bug其实并不是非此即彼的,产品就这么设计的,内部的测试知道,但外部的大众不知道,觉得用的不爽,提了,这钱是给还是不给?哪怕公司内,测试发现此类问题(比如为了安全考虑,密码第二次输入确认的框不允许复制黏贴),开发说这是一个需求/特性,大家还得再把产品叫过来一起讨论下,外部可做不到;
  • 专业的测试是需要测试用例(Test Case,更不要说TC评审了)的,常见的测试用例(临界值相关、内存会不会泄露、特殊字符什么的……专业测试玩起来一套一套的,分分钟把开发认为没问题的程序搞挂),在大众那里可没有,不踏实,感觉……有点像西医和中医的区别,敏感话题不展开;

 

  • 专业测试提的Bug是分级的(成熟的产品也应该分级标准和规范),几级以上必须全部close才能发布什么的,开发也会按照级别来确定修复顺序,大众提交上来的,还得安排人去分级review;
  • 专业测试会把Bug指定给特定的开发或产品经理,背后的逻辑是知道技术角度的模块划分,以及对应的负责人,方便流程往下,大众提交上来的,还得安排人去做assign to这个动作;
  • 专业测试懂得用开发明白的语言描述,说清楚是什么机器、什么系统、什么版本……特别是“如何重现”这件事,大众提上来的,Bug重现不了,急死你;

 

  • 内部经常有针对Bug的讨论,部分Bug可以defer或reject,那么问题来了,谁来牵头组织讨论,确定Bug状态的流转与控制?可不要指望大众会“跟进”自己提交的Bug;
  • 如果开发比较牛逼,理解了,修完了,是否修复的验证谁来做,谁来close这个Bug,确认修复?整体的回归测试谁来做?

 

  • 以上还只说了狭义的功能测试性能测试压力测试怎么办?大众没法帮你模拟10万人同时XXX;还有,自动化测试谁来做?
  • QA相关的还没说呢;

 

  • 其实,这个在方法论里面接近于“UAT,用户接受度测试”,有的也叫验收测试,经常由产品经理代表用户做(当然,有资源最好让用户亲自来),不是找Bug,而是看产品是否满足用户需求、设计是否符合用户认知什么的;
  • 这事儿很好,有条件都做吧,但更多的目的是找个理由和用户互动;

 

好问题,帮我复习了一遍和测试有关的概念,暂时想到这么多,大家可以补充。

对了,近期iamsujie.com做了改版,大大提升了移动端的阅读体验,欢迎尝试。

iamsujie 微信公众号二维码
iamsujie 微信公众号二维码

【3018】最近对项目管理的一些实践

最近,因为产品的需要,又开始做一些项目管理的工作,一直认为,各种管理工作都是手段,是为了产品服务的,所以切忌“杀鸡用牛刀”,本着够用就好的原则,和团队(10多个人,运营占了大半的奇怪组合,呵呵)一起边做边设置一些规则,下面是最近我发的一封邮件,加上点评分享一下。

首先,开发同学工作时间分配的共识:

a) 因为产品属于“二手房改建”,所以各种Bug和可优化的地方很多,开发很容易被各种零散需求占满,但产品还处于新生阶段,必须强制只留20%的时间给日常bug修复和优化,确保主要精力还是在做一些整块的需求,保证产品整体是在向前走的(产品进入成熟期,可以把大部分时间留给优化);

b) 因为团队结构里,运营人数很多,之前每位运营都会直接找开发提需求,把开发的工作计划打乱、碎片化,所以规定运营可以直接找技术,但只限于严重的问题,技术不接运营直接提的任何需求,必须走产品人员过一下(必须有人通盘衡量,运营人员通常会站在自己负责的一件事上,把自己需求的优先级无限提高);

c) 技术同学的评估,之前因为经验不足,会把“工作量”和“工期”混在一起,现在分开,并不是说工作量10人天,2个人做的话,就是5个工作日后发布(也是让团队所有人明白两者的不同);

其次,在公司里找了一个小系统,管理日常的Bug和优化(积累了几十条以后,用口头、邮件什么的管理都是不靠谱的),主要是写给运营了解的一些原则:

1 优先级判断

a) 1-urgent,系统大面积不可用,必须马上改,需要申请紧急发布;

b) 2-high,明显的bug,需要修改,尽量赶下一次发布;

c) 3-medium,不严重的bug,平时过掉;

d) 4-low,优化建议,平时过掉:优化可以用“严重程度”字段来表达重要性;

2 使用流程

a) 运营先提给产品,状态new

b) 由产品来确定优先级和指派给谁,确认方案,需要修复的,状态改为open,指派给开发安排,确定“期望修复时间”;

c) 开发修复完成,状态改为fixed

d) 产品验证后,状态改为closed

3 系统里的具体条目,产品平时和开发排掉,产品运营双周会上不讨论,需要特别说明的,请录入者在会上提出:

a) So,需要录入者会前自己review一下自己提出的条目(如果状态已经不是new,就说明已经安排了)

b) 平时,每个人都可以随时去系统里查看自己提出的条目的进展,有异议找产品沟通(前提是,我们团队有一个产品原则的共识,比如“目标用户有哪几种,他们的优先级排序,每个群体的需求又有哪几类,优先级排序……”);

4 UED也视为技术人员,给UED的需求也用系统管理;

大家批判着看啊,周边条件不同,做法一定不同,希望有启发就好。

【3017】又到一周周报时

又到周五了,意味着大家又要开始憋周报了,从@纯银的一个段子开始——

公司有个技术牛人,某产品专员向他提单,牛人一看内容很扯,质问“你觉得这个需求有价值吗?”对方诚恳回答:“没价值,但是我总得写周报啊。”牛人想了一分钟,回答说好吧我帮你做,因为我也得写周报啊。

我想,看这个博客的人,基本上都要写周报吧,更有甚者估计要写日报,但多少人打心底里觉得写的周报没有意义?只是为了写而写?今天,不妨从两个方面,简单说说,如何让周报真正的有意义。

第一个话题:写什么内容。

这个万变不离其宗,其实和敏捷里的站立晨会是一样一样一样的。形式不重要,说清楚3件事即可。

本周做了什么:重点不在于做了什么,而是拿到了什么结果(有共识的)。举个例子,花了半天时间和谁谁开了个什么会不重要,重要的是会上做了什么决定,会后定了什么后续的行动方案。

下周要做什么:同样,重点在于希望拿到什么结果,推进什么事情。不要是“继续优化Q2的产品规划”这样虚的东西,而应该是“与某某老板讨论Q2产品规划,并达成共识,从而下下周可以启动某项目”。

碰到了什么问题:怎么去尝试解决,搞不定的需要什么资源,打算找谁,打算让老板或同事怎么帮你。

然后,针对你的工作内容,细化一下,比如分为“项目、日常需求、其他”几个模块,有的时候再加一点工作感悟,也挺好,比如我,就是从每周500字的感悟渐渐写出一本书的,:)

第二个话题:发给谁。

可能有人觉得这个没啥可讨论的,传统上,周报不就是汇报工作(说白点,方便老板汇总周报)么?发给自己的主管不就行了么,我觉得这是最傻的,这大大浪费了“写周报”这个及其费脑子的工作。

稍好一些,周报可以发给主管和团队同事,团队里的人互相了解都在做什么,可以便于工作展开。

更好的,周报应该发给主管、团队同事、下属、以及有干系的合作方(其他部门的人),并且酌情区分“To”和“CC”,这才是真正的信息流通,发挥最大价值。愿意把周报发给下属的主管是好主管,:)

这位说了,周报里有敏感的内容啊,不方便发这么多人……我说两句:第一,互联网的精神就是开放共享,再想想,你觉得敏感的内容,是不是真的敏感;第二,稍稍做点技术处理,很简单的,可以共享的内容发给所有人,实在敏感的内容,在邮件上再回复一下,补充给对应的收件人好了。

要不,改变从今天开始?