51Testing软件测试论坛

标题: 关于敏捷项目中的测试瓶颈问题 [打印本页]

作者: dolgy 时间: 2012-9-13 23:54
本主题需向作者支付 20 测试积点 才能浏览

作者: angle-ying 时间: 2012-9-14 15:22
晕，奇怪明明是求助问题还要求别人给你综合技术指数的分数...咋回事儿捏

作者: mainer 时间: 2012-9-17 13:52
有意思。

作者: wuliangye 时间: 2012-9-17 16:06
这个问题在以前我们项目组也出现过，主要是由于对于进度的安排极度不合理导致测试根本没有时间去做针对性或者全功能覆盖的测试，建议LZ将需求分析从敏捷项目中的三周一个迭代中去掉，给开发和测试留下三周完整的时间进行开发和测试

作者: dsc_vida 时间: 2012-9-25 14:10
LZ不厚道，求助问题还要求别人给你支付综合技术指数的分数...

作者: zhang3111194 时间: 2012-10-9 09:08
LZ不厚道，求助问题还要求别人给你支付综合技术指数的分数...

作者: 布丁qhh 时间: 2012-11-2 17:17
？

作者: 布丁qhh 时间: 2012-11-2 17:18
先说一下我项目的环境：
小团队，我们做的是三周一个迭代的非常强调用户体验的iOS产品，除了BVT外，其他内容全部手工黑盒测试

第一周主要时间是用来明确当前版本具体做哪些feature
  test在第一周主要工作是review需求，写case
第二周主要工作是编码和实现
  test在第二周主要工作是跟进dev每天check in的变更点
第三周bug fix&发布
  第三周test会做比较全面的测试，测试重点是功能的变更点和新的feature

整个项目中虽然每个阶段测试的重点都在新功能和变更内容上，但所有功能的测试工作穿插在项目中的真个过程，每个功能在三周中都能测试到

问题：
进度上的瓶颈经常block到开发进度上，总是在release当天上午才code freeze，下午就发布了
对于模块上的某个变更点去进行全面的测试效率低，时间上不允许，所以对变更内容去做针对性测试的思路我认为是对的
每天代码上的change在20个左右，dev对每个change的描述上和test沟通不清（dev和test思想上的区别），会出现变更的影响范围描述不清导致测试不能很好的跟进
结果好几个版本在release当天的change出现bug，然后测试时间不够导致bug露出

我希望测试人员能够针对代码上的change去做百盒测试，这对测试人员的要求不比负责code review人员的能力低，并且要从另一个角度出发去测试
现在没有一个水平能够达到这种要求的人，项目的节奏不变的话这个问题就会一直存在
怎样才能解决bug漏出呢？

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