一、与实际项目设立有关的事项
介绍项目情况、当前项目阶段情况、项目市场预测和项目时间讨论。
资源:需要人力、物力、技术、工具、常用的开发语言、工具、测试工具、系统运行需要的工具。
情况:参与部门,主要负责人,部门只需要职责,后期主要工作内容
与项目相关的文件:指导文件、技术文件、项目介绍文件等。
项目的里程碑:开发开始和结束时间,测试开始和结束时间,发布时间,可能还有详细的分期时间等。
二、小程序项目立项会议
项目介绍:项目介绍文件
测试团队人员介绍:开发人力,多少,测试人力。
测试团队模块分配:模块被分配给人员。
测试团队准备测试相关事宜:工具准备、设备准备、人员招聘等。
三、项目规则
根据不同的项目制定不同的规则,如:
1.邮箱配置:方便工作中与不同部门、同事沟通,做好记录。
2.如何处理项目中遇到的问题,比如找什么部门,负责人介绍,相关人员联系方式制定。
3.项目中的时间安排
4.电子邮件使用规则:注意事项、标题、休假、附件订单等规则。
四、项目测试团队此时的任务
准备测试相关的设备、工具和人力安排;
产品出来后熟悉系统,比如画功能模块图。如果没有出来,研究项目相关的文档,比如项目介绍;
完成项目建立中的相关任务,如邮箱配置,确认邮箱可以正常使用,包括显示名称和发件人名称设置。
一、与实践中的项目评价有关的事项
1.评审概念
需求评审是对产品需求文件的评审。需求文档是根据用户的需求抽象提炼成产品需求,对于我们的技术人员来说也是一个相对直观的需求文档。通过这个文档,技术人员可以知道用户想要什么样的产品,它是用户和技术人员之间的桥梁,所以它的审查非常重要。
评审采用的方法一般是同行评审。
2.审查目标
首先,产品需求文档能够全面清晰地描述产品的功能和性能;
第二,项目组成员对用户需求有相同的理解;
第三,形成可以指导研发的最终文件,后续工作要在此文件的基础上进行。
3.评审流程
4.审查的对象包括:
概念:产品需求规格
阶段:系统计划和项目计划。
开发阶段:详细设计、单元测试用例(方案)、集成测试用例(方案)、代码、数据库脚本等。一般来说,在编码之前,应该进行详细的设计评审,以确保程序的正确性,减少后续修改带来的不利影响。
验证阶段:系统测试计划、系统测试方案和系统测试用例。
发布阶段:安装文档和使用文档
5.审查中的原则:
预审期间应使用检查表,以避免发现缺陷和不知道记录在哪里。
避免过度依赖清单
评审会议以2小时为限,避免长时间讨论偏离评审会议主题。
“磨刀不误砍柴”,需要给陪审员提供足够的预审时间,一般提前两天比较好。
如果一些与会者没有准备好,会议将被推迟;如果有人真的抽不出时间,重新安排/取消复习。
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!