测试负责人该如何去分析bug和做业务测试会更好？
本帖最后由 QTP2008 于 2016-10-17 09:09 编辑不怕大家笑话，负责软件测试也有4年了，最近工作有点不顺，带领测试组做业务测试，由于需求文档缺乏（可以说需求文档编写人员经验比较少，业务分析不透彻），经常出现连业务都没有想到的情形，但是出现上线问题后，开发人员都一致指向测试，说是测试没有测试到，把责任都推给测试，有的甚至开发人员都没有做这些异常的校验。细化分析每个bug吧，开发人员又不开心了，有的开发人员负责的模块bug比较多，一分析都影响他们的绩效，拿的绩效奖金少了，更不开心了，处处为测试开展工作设置障碍，甚至联合开发人员一起来欺负测试人员，测试人员也很无赖，本来好好的开展工作，结果变成了职场政治斗争，悲剧呀。
我想请教同行3个问题：
1.大家在日常的测试工作中，是如何开展业务测试这块的？怎样才能将业务测试这块做好？指个方向也行。
2.如何分析bug才能既不得罪开发人员，又能为研发团队提出优化、改进建议，让研发总监也满意？
3.和开发人员如何相处，才能缓和目前的这种紧张氛围？
先谢谢大家啦！
你需要是规范流程，需要的是需求分析评审，需要的是标准，bug的分类，建议每周（或者两个）开一个会，做做总结报告什么。 缓解紧张气氛，部门活动联谊最好的办法了。让公司出部门经费 如何相处，这就要看公司制度以及自己的为人处世了。 上面的都说了，这个是公司规程方面的问题。
需求有问题，就应该和上面反映做好需求；开发人员没有异常检验，是因为没有做好设计，单元测试、集成测试或代码走查也都没有或走形式；开发人员的绩效和缺陷挂钩本来就是有问题的吧；业务不精通请领导找业务人员做培训，测试人员本来就应该是业务专家的。
所以需要的是领导方面的支持，把相应的流程和关系理顺，给开发和测试设定边界，到底开发应该做哪些，测试做哪些，哪些是必须的，哪些是可以根据具体情况少做甚至忽略的，相应会有什么影响。
不用总指望自己方面做好就能解决问题，从描述看，就是公司方面出了问题而已。
测试本来就是辅助部门，很多时候就是背锅用的，所以不需要太委屈，看公司对测试的定位。
多和领导沟通，让领导知道测试方面的委屈，即使背锅也不会影响太多的，领导比较偏向开发那就一点办法也没有了。
想摔锅就写测试用例，多写，强制让开发方面进行测试用例审核，不审核就不进行测试，审核过出问题开发还JJWW，至少有说法。
说真的，大部分的公司主要没有强力QA，如果有QA在前面顶着，测试工作应该会好做很多，我一向不建议测试对开发指手画脚，太拉仇恨了。
多和开发联络，说明大家都是一个碗里吃饭的，不是敌人是朋友，缺陷太难看就不要写缺陷单，直接和开发人员说让他们改，给领导看的和实际用的未必一定要一致，具体情况看公司的氛围吧。 对事不对人，设置做事的原则；不该承担的，不承担，直接出分析报告，给领导，说自己哪错了，开发的错让领导报告里自己看 感觉公司的问题居多吧，争取领导、开发的支持，自己先把测试前需求分析做好，可以拉着开发进行会议，先把自己的工作做好先 我也是测试部门负责人，不过和开发沟通还算可以，主要问题是公司不太注重测试这块，你们还有需求，我们是产品压根不出需求，出现问题了找测试，就连新版上线都没通知测试，除了问题找测试，我也是无语了，最近一直在考虑要不要跳槽，但是担心调了之后其他公司还是这样 需求不明确，以bug来考核绩效，肯定会出问题。。。
规范开发。测试流程。。
页:
[1]
