求安慰~~领导在现场发现了一个bug，大发脾气，心里好难过~~

爱加菲

回复  爱加菲


    我也是，最多的时候一个人面度几个项目。不过还好 我们领导如果发现我没有看到的bu ...
楠族开心果 发表于 2011-1-6 10:42

起码你们领导还理解你一个人测试的辛苦

sakuna

我从来就不牛X，这回我让他明白我不是万能的了。。。
但是不知道回来该怎么跟他沟通。。。。估计得一顿 ...
爱加菲 发表于 2011-1-6 10:27

领导之所以这样，我觉得可能有两方面，一方面是客户的因素，总要给客户一点交代，这可以理解为一种踢猫行为，如果他是了解你们的，即便是要K你，也会有所保留的。
另一方面是领导确实不了解测试，这个时候，你的任务除了要做好日常的测试工作，还要让你们领导了解你们是怎么工作的，K一次也就算了，老是被K，谁受得了，是不
再说了，领导不是还没K你嘛，所以没有什么好委屈的，要是不K你了，那你岂不是白委屈了，对不

爱加菲

领导之所以这样，我觉得可能有两方面，一方面是客户的因素，总要给客户一点交代，这可以理解为一种踢 ...
sakuna 发表于 2011-1-6 10:50

昨天头找我呢，因为我没在躲过一顿尅。。。
其实不怕尅，确实是我疏忽了，尅我我也心服口服。

关键是我觉得如果再这么做下去，没法保证测试的质量，如果连续被尅，我肯定受不了。

觉得委屈是，即使是经过细致的测试的设计、评审和执行过程，可能也会有些隐藏的bug不被发现。更何况我们现在的这种测试过程，有漏测点、bug被疏忽、太容易发生了。如果领导不意识到现在的设计、开发、测试过程之中存在的很多问题，不能根本上去解决问题，以后类似的情况还是会频繁的发生。

sakuna

回复 23# 爱加菲


觉得委屈是，即使是经过细致的测试的设计、评审和执行过程，可能也会有些隐藏的bug不被发现
感觉这种观点有点问题啊，你一定要淡然，不然你压力会很大的哦

chengning

  淡定啊 ，习惯就好了，比起你来  我更惨

爱加菲

回复  爱加菲


觉得委屈是，即使是经过细致的测试的设计、评审和执行过程，可能也会有些隐藏的bug不被 ...
sakuna 发表于 2011-1-6 11:24

说的对，我应该淡定点。。。。
可能是太较真了，对自己要求太高，不现实。

爱加菲

淡定啊 ，习惯就好了，比起你来  我更惨
chengning 发表于 2011-1-6 11:30

淡定淡定。。。谢谢安慰。。。

samraul

深表同情。你比我情况还好。我这里也只有1个测试人员，而且我是刚入职。对系统对业务还不太了解。测试没有需求，没有设计文档。前期的设计讨论会议也没有叫上我去，相关邮件也没有抄送给我。之前已经像经理反映过了。到系统开发快结束了，才叫我测试，那个被动啊，相当的不规范，很多业务和后台的东西都不了解。自己只有多问、多了解，把发现的BUG提交给开发人员，并修复了。凭我测试的工作经验，后期系统基本没有什么BUG了，但郁闷的是，一个业务需求的功能没有实现（学校是商户，学校里面每个饭堂再分作下一级商户，因为每个饭堂可能承包给不同的商家，涉及权限问题），我在没有需求和设计文档，并且刚入职没多久，项目前期又没有让我提前介入的情况下，这个真没想到，我觉得可以理解，也不是我想的，你做好，我测试权限就行了。开发人员也没有考虑到，所以没做。但开发人员责怪我测试没有站在用户角度测试，思维不够发散。我解释我的情况，他就说“你好像还不服哦”。我觉得他对测试的认识有误，他觉得测试人员要想到面面俱到，不能有一个BUG漏掉。我发现那么多BUG，发散思维提了那么多建议他没看到，这个问题就放大来看。后来我忍了，没理论，以后自己更用心做好就行了。

愚人

看到风险，根据之前的情况，对某些模块做重点测试……

Jackc

开始看时，想笑（莫拍砖..真实感受）

看到后面，有些莫名的抓狂...

估摸着下午你们领导就该找你“聊天”了（当然，也许他很忙，忘记了也说不定，呵呵）
——————————————————————
说正事，其实这次事件，可以看作是用户体验这方面，领导好比用户（当然，会比普通用户挑剔了）。让用户打法雷霆的bug，优先级也不低了，仅仅次于主要功能未实现的bug了。

建议你稍微调整一下测试策略，除从功能实现着手设计用例外，增加“用户可见”和“用户感受”两个用例设计因素（这两个概念都比较虚，我尽量描述一些）。
--------------------------------------------------
用户可见：在用户角度，能察觉到的就是bug，不能察觉的即不算bug。故设计用例时，增加用户常用区域用例，减少用户不常用区域的用例，这样的测试活动比较符合产品价值分布规律。
如，在某个边远小功能，存在一大堆bug，但用户基本不使用那一块，那么有必要花费宝贵的资源来发现，并修改它们么？（按照bug价值率来布置测试资源，经常会用到资源不足的测试中）
当然，不是说那遥远的小功能连基本功能测试都能省略哈......

用户体验：这个就比较虚了。对于产品的感受，不同人都不一样。而这部分的bug主要不是通过实际测试完成。大多是通过设计用例，发现疑点，然后评审/协商确认需求，最终达到大家可认可的平衡点。也就是说，可以在测试实际执行未投入的开发阶段，可将部分重心放置于此，减少后期因为纠结于“测试/开发分歧”而浪费宝贵的测试资源。
————————————————————————

Jackc

看了LZ兄弟的描述，领导若因此事找你，多半你只能闷声了....
其实若是强一些的领导，谈谈自己的测试策略以及关注点，多半就过了...

话说回来，居然还有认为测试能发现一切的领导....（如果不是管理策略知而固为之，那我只能祈求兄弟多福了）

爱加菲

深表同情。你比我情况还好。我这里也只有1个测试人员，而且我是刚入职。对系统对业务还不太了解。测试没有需 ...
samraul 发表于 2011-1-6 11:51

这位同学，我觉得你能在这种情况下把测试起来简直就是奇迹。。。。
深表同情。。。。

爱加菲

看到风险，根据之前的情况，对某些模块做重点测试……
愚人 发表于 2011-1-6 11:59

谢谢指点。
我今天就在找重点地方重新测。

linyucc

这种情况有个  优先级的方法，什么功能最重要 最先测 重点测 ，比如说 流程 逻辑 算法  这是我们最为关心的，站在客户角度来  他看重的界面显示  查询结果 统计结果 是否正确  ，这些东西你可以仔细点测。
还有就是遇到这种情况 首先你要先向领导反应 工作量大，时间紧，会导致测试中会有遗漏，为可能出现的失误做好退路。

zhaoshucong

建议你们领导再招个人，这样两个人可以互测，减少bug数，除非你们那不重视测试

crystal50112

当然以保证质量为前提

wangsc_testing

我觉得这里边与测试经验有关系。保证质量这是必须的，但质量不仅仅那些主要业务功能的质量，那些附带的功能模块同样也要保证它不会出现很明显的BUG。挨骂了，说明这个BUG是很明显的，应该是很容易测出来的，但被你忽视了。对于你说的测试时间紧迫，功能又多，把所有功能模块测试过来有点难度，那么主要的业务功能模块你肯定要全部测试一遍，对以附带功能，需要你的经验来判断，哪些地方容易出现BUG，哪些地方可能存在BUG，其实也就是对附带功能采用探索性测试方法，虽然发现不了深层次的问题，但至少可以发现很明显的问题。

张志英

回复 25# chengning


    你怎么个惨法了？？？

bj_liuqiang

这样的公司趁早走！

tianshi861

你们领导太不尊重测试了吧，其实出现了问题，你心里比谁都不好受，总结就可以了！