最近在搞BBIT, 所谓的BBIT就是开发的新版本代码从来没有正式合入系统跑过, 尚不敢交给测试人员测试. 此期间为了代码质量, 开发部从测试部协调人员过去进行早期投入, 一边开发, 一边进行黑盒功能测试. 在HW内部的话说, 就是测试人员从后端伸手到前端去. 那么, BBIT的目的也比较清楚了, 就是系统在转测试之前, 尽可能的发现多的问题, 尽少的遗留问题到后端, 即内部的说"带病迭代." 同时, 在过程中开发与测试相互传递技能, 测试兄弟教开发如何进行系统级客户化场景测试, 开发教测试兄弟一些定位手段, 定位函数以及相关维测手段.
作为第一次担任BBIT组长, 身上还是有一些压力. 不但要负责具体测试工作, 还要协助开发人员定位, 盯结对测试进度. 每天要发日报(发日报是HW工作极具有土著特色的方式之一, 许多人深恶痛绝之, 但是不可否认的是, 它是管理项目进度的重要方式). 遇到发现严重问题, 定位时间长, 测试平台有限, 测试进度被阻塞, 让人惴惴不安, 晚上又得加班测了!
目前BBIT已经进行第三周, 从老大的层面看效果还是不错的. 但是自己觉得并不满意, 特别有一些工作细节处理得不好, 目前最突出的还是结对测试人员工作效率的问题.
结对测试人员的工作效率实在不敢恭维. 可能是开发代码只对代码情有独钟的缘故, 对于深挖bug 没有欲望, 这是测试人员工作的一大忌!! 质量意识还不够强烈. 对于当前全职投入的测试工作, 只是把它当成任务完成而已, 反正过了这一阶段又回开发部去了. 责任心不够强烈, 感觉不到有担当. 一副软塌塌的样子 , 作为同龄人, 都有点让人恨铁不成钢. 所谓"定位决定地位, 眼界决定境界", 长期以往, 如何是好? 或者是我多虑了吧! 每个人都独特价值的地方, 以自己的这套标准去衡量, 会不会有失偏颇?
问题来了, 在自己队友能力尚缺的情况下, 如何帮助其进行有效提升? 如何确认经其手的工作是无误的? 要知道, 如果一个Test case测出来明明是存在bug的, 但被粗心的或偷懒的测试人员置上pass, 偏偏这个bug在商用版本里面发布了, 秋后算账是很厉害的! 曾经终端的一个兄弟这么干过, 最后被全公司通报批评, 直接辞退. 此兄有一特点, 遇到疑似问题几乎不我求助, 一个人闷着头继续往下搞, 折腾半天浪费时间. 这个现象已经不是一次了! 我其实是很乐意提供帮助的, 要好好利用身边的资源哪(当然, 这一点不过要光说别人, 自己做得也是远远不够的). 这一点目前还没有有效的解决办法! 对于其测试执行, 老大的建议是, 对于其测试过的用例进行定期抽查, 如果发现有明显的漏测, 在日报上及时通报, 适当给予一些压力, 以促使其注重测试执行质量.
明天周一, 相关问题要有一定的改观! 先记这么多吧, 跑步去了.
本文分享了作者在BBIT(边开发边测试)项目中的工作经验,包括测试人员参与开发过程、提升测试效率的重要性以及面对团队成员责任心不足的思考。文章提到,尽管高层认为效果良好,但作者对结对测试人员的工作效率和质量意识感到不满,并探讨了如何在队友能力有限的情况下提升测试质量和效率。
980

被折叠的 条评论
为什么被折叠?



