51Testing软件测试论坛

标题: 一个QA的烦恼。 [打印本页]

作者: vanillapple 时间: 2011-10-8 15:35
标题: 一个QA的烦恼。
本帖最后由 vanillapple 于 2011-10-8 15:44 编辑

1.测试发现BUG，然后回归测试。。如此多次。临近发布，又发现一个BUG，但是BUG不大，只是界面之类的问题，有时会出于内心的纠结，报上去还是不报上去会犹豫。

2.测试完毕，项目发布，过了3个月，突然发现好像有个BUG，只是当时没测到。纠结中。

3.发现一个BUG，不影响功能，或影响非常少量功能。开发说，改不了，不会改。不知道是真不能改呢，还是其实可以改。要是真不改了，看着那个BUG，就是心里疙瘩。

4.老项目接手开发新功能，原来的测试不是我，结果发现遗留的BUG，报上去，开发回复说，原来就是这样子的。

总得来说，项目组XDJM还是工作积极，但是总是会碰到那么一丁奇奇怪怪乱七八糟不能用技术一锤定音的各种问题。

作者: fkueangle 时间: 2011-10-9 09:39
虚则QA 实则测试

作者: chinalinglin 时间: 2011-10-9 17:41
今天看到你这么一说，才觉得这些问题也是问题，以前也遇到过，没有在意过。

作者: birdtwm 时间: 2011-10-10 02:19
发现Bug报上去，是我们QA的职责；
尽量让Bug得到解决，是我们QA的责任心；
不管Bug最终能不能得到解决，都有一个准确的处理记录，是我们QA的素质；
对于漏测的Bug进行总结，是我们QA的上进心。
我想，做好上面这几点，也心安理得了吧。

作者: vanillapple 时间: 2011-10-10 10:20
回复 3# chinalinglin

亲，那正常情况下，你是怎么做的哈

作者: duyahui2008 时间: 2011-10-20 16:26
亲那，我现在也是啊，不过我们有历史遗留bug，跟开发和项目经理沟通他们说暂时不改，我就没所谓了，反正bug我已经提交了。

作者: sandyzone 时间: 2011-10-20 17:12
QA专门负责抓人的，哈哈，检查各种规范，测试用例评审结果审查那些的，以前被抓过好几次，郁闷！

作者: sandyzone 时间: 2011-10-20 17:16
本帖最后由 sandyzone 于 2012-3-3 00:07 编辑

哎，这个是每个公司都存在的问题

作者: 小妖童 时间: 2011-10-21 10:12
回复 1# vanillapple
首先，你做的是测试人员的工作。
1(1)为什么到了临近发布才发现bug，按理说界面上的bug是很直观的，这个跟你的测试方法有关吧。
(2)需要把bug提出来，让开发人员进行评估是否进行修改。
2要明白一点：测试人员不可能一次性把所有的bug发现出来，只是尽可能的去发现。
3 必须要他们修改。
“不会改”这个绝对是推辞，是因为他们懒，让他们咨询高级开发人员，
4 明确的告诉开发：以前的是错的，有问题的，现在需要改过来。
作为一个测试人员，态度要强硬一点，要自信，要相信自己所提的bug。出现上面的几种情况，都可以用下面这个方法来解决：把遗留的bug，遗漏的bug，不确定是否需要修改的bug整理出来，发给开发人员抄送给测试组长，让他们进行评估。

作者: zhong3269 时间: 2011-10-24 22:49
我是来找QA的相关资料，但我知道沟通也是QA的职责，
其次，研发说不会改，这个问题也是QA的职责，QA有责任就说服研发去修改，如说服不了，只能上报项目经理及时与上级沟通。
最后，发现bug就要及时上报，然后由QA职能组长和项目经理决定是否修改，修改的话是否有延迟等吧！

作者: hzjceshi2009 时间: 2012-3-16 15:33
同感，常遇到这些问题。以前也是束手无策。
现在我的做法是，统一整理成文档，发给项目经理或上司沟通确认是否需要修改。
将确认的结果记录下来，
若以后出现什么问题，可以作说明。

作者: mascot 时间: 2012-3-23 16:31
1.测试发现BUG，然后回归测试。。如此多次。临近发布，又发现一个BUG，但是BUG不大，只是界面之类的问题，有时会出于内心的纠结，报上去还是不报上去会犹豫。
界面的bug在临近发布时出现，这是test case覆盖率的问题。
2.测试完毕，项目发布，过了3个月，突然发现好像有个BUG，只是当时没测到。纠结中。
bug是永远也找不完的，但要看你发现的是什么bug，如果是基本的功能问题，那肯定是测试有问题。如果是不能重现的bug，那么出现的几率不大，可以原谅。
3.发现一个BUG，不影响功能，或影响非常少量功能。开发说，改不了，不会改。不知道是真不能改呢，还是其实可以改。要是真不改了，看着那个BUG，就是心里疙瘩。
测试开发和项目经理可以一起讨论这个问题的严重性，以及影响的范围有多大，再决定。
4.老项目接手开发新功能，原来的测试不是我，结果发现遗留的BUG，报上去，开发回复说，原来就是这样子的。
的确是bug当然要改，以需求为准。

总得来说，项目组XDJM还是工作积极，但是总是会碰到那么一丁奇奇怪怪乱七八糟不能用技术一锤定音的各种问题。

技术不能代表一切，项目的进度，成本代价才是参考的重要因素。沟通协调是一门学问！

作者: 雪候鸟南飞 时间: 2012-3-26 14:51

作者: sunny0843 时间: 2012-4-8 15:55
up

作者: iTest99 时间: 2012-4-13 11:40
有问都提上去，改不改由项目老大负责决策。

作者: shamokafei 时间: 2012-4-20 11:28
这有啥纠结的，我天天遇到。

我的观点就是有bug一定报，而且越早越好。开发不修改的问题，我会跟他讲明这点不修改会导致的结果。依然不修改则直接上报给项目经理。

作者: miraclej 时间: 2012-4-20 14:31
回复 16# shamokafei

我所在项目的项目经理每次都跟我说：这个么不是流程过不去的大问题，客户对系统也认可了，就不作修改了。
好吧，反正我要离职了，这项目经理就爱咋样咋样吧，我也管不着。

作者: noyafz 时间: 2012-9-14 17:01
貌似都遇到过，那样纠结的心里和你说的很贴切

作者: mainer 时间: 2012-9-17 14:06
回复 1# vanillapple

下面分条说一下。
1、必须报，至于是否修改，什么时间修改，可以与开发人员沟通。
2、这个属于漏测，那就是你的问题了，呵呵
3、你怎么确定这个bug影响非常小，有跟开发、产品进行分析吗？开发说不会改或者改不了都不是理由，而且你也不能凭自己个人看法来确定这个bug的影响，要评估。
4、原来的问题你也必须提出来，如果当前开发人员不修改，就提交给项目负责人，由他来评估，并且安排给谁来修复这些bug；

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)