在软件测试工作中的自我提升

发表于:2010-4-29 13:35

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:挽起袖子(gameres)    来源:51Testing软件测试网采编

  1、辅助过程裁减、细致化、明确项目规范。清晰产品在面向最终用户时的形态,对策划案(产品需求)中阐述不清晰或者有逻辑冲突的地方提出质疑。实际开发中,程序员受限于工作的焦点,所以QA/QC人员必须做到更了解产品将要达到一个什么样的形态,期间QA/QC人员的思路应保持在最终用户的身份上,而非开发参与者。

  要求:

  仔细阅读策划案(产品需求)。

  对阐述不清或者产品需求本身逻辑冲突所导致的疑问,要求做出释疑。

  依照开发目标,清晰该开发阶段产品的目标形态,以及与最终形态的差距。

  2、制定〈质量保证计划〉参考相应的产品策划案,严谨斟酌产品需求的合理性以及大胆假设在即定需求下有可能产生的BUG,以此制定出质量保证计划(测试流程)产品将要实现的功能必须严格遵守产品需求,对于产品需求本身的合理性以及需求中所忽略的重要缺憾及时的对开发团队提出见解。

  要求:

  确保《质量保证计划》严格的依照产品的需求。

  对需求合理性及缺憾性需求提出成熟的见解。

  制定出完善的质量保证计划,测试流程中不仅要保证每项功能的实现还必须最大程度的假设可能出现的情况。

  3、产品检查。确保产品在严格依照策划案(产品需求)实现了有效功能的同时,最大力度的保证实际开发人员所未预料到的BUG得到如实的反馈。依照制定的《质量保证计划》严谨的落实测试项,并且如实详尽的以书面形式(BUGZILLA)反馈。

  要求:

  遵照已有的测试计划完整的进行测试。

  参考现有产品需求,以用户的角度斟酌是否合理和完善,并且如实向开发团队反馈成熟建议。

  在确保测试流程完全落实,并且所有已知BUG已经反馈的情况下,进行大量重复性的测试(就公司产品而言,就是反复玩,实际工作中,仅仅有30%左右的BUG是在预先制定的测试流程中可以体现的,其他大部分BUG在无序测试中反而更容易被侦测到)。

  未预料到的BUG出现,则总结该BUG的类型,并且将非偶然性的BUG添加入《质量保证计划》中。偶然性BUG权衡后记录,见注①。

21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号