CMMI5在项目中的精简应用.doc

CMMI5在项目中的精简应用CMMI5在小型项目中的成本过高，根据自己对CMMI5的实施体会与在实际项目中的应用，在项目实施的过程中精简了CMMI5的实施流程和部分文档，这个精简的流程在项目实施的过程中既可以确保流程规范与质量信赖又可以节约项目成本。以下跟大家分享一下CMMI5在项目中的精简应用：一、需求与规范的管理1、 由测试负责人（或专门的需求分析负责人）统一接收来自移动总的行业网关相关规范和新需求，测试负责人浏览规范获知大意后回复邮件，将规范和新需求转发给开发经理、项目经理、相关的开发人员和测试人员，同时commit到CVS；2、 测试负责人（或专门的需求分析负责人）、项目经理仔细阅读规范与需求后，对规范和新需求进行研究，并就难点和疑点进行讨论，整理出重点内容，并将重点内容发给开发经理、项目经理、相关的开发人员和测试人员，同时commit到CVS；3、 开发经理、项目经理、测试负责人、需求分析负责人、相关的开发人员与测试人员开会对规范、需求和重点内容进行讨论，确定需求的具体含义以及最终实现的需求和功能点；4、 项目经理根据规范、需求和开会讨论结果编写需求规格说明书与功能列表，测试负责人（或专门的需求分析负责人）对文档进行检查并修改完善，然后commit到CVS；5、 测试负责人（或专门的PPQA）确认所有相关文档经过了评审并都已经commit到CVS。二、项目计划与测试计划1、 由开发经理组织项目计划讨论会，在讨论会上各开发负责人对自己所负责的模块所需要的工作量进行评估，根据工作量和工程需求初步确定总体开发计划、测试计划和发布时间；2、项目经理根据估算工作量和工程需求编写项目计划，使用CMMI5总体测试计划模板并对其进行适当的裁剪和补充，编写适合本项目的项目计划；3、测试负责人根据项目计划与发布时间编写测试计划，使用CMMI5总体测试计划模板并对其进行适当的裁剪和补充，编写适合本项目的测试计划；4、项目计划与测试计划编写完成后发送给开发经理、项目经理、相关的开发人员和测试人员，开发经理、项目经理、相关的开发人员和测试人员阅读项目计划、测试计划后将建议和意见以邮件的形式反馈给项目经理与测试负责人，项目经理与测试负责人收集大家的邮件分别对项目计划与测试计划进行修改完善，同时回复邮件说明项目计划与测试计划修改情况，如果存在争议则召开一个小型会议对异议进行讨论，修改后的项目计划、测试计划commit到CVS；5、测试负责人（或专门的PPQA）确认所有相关文档经过了评审并都已经commit到CVS。三、开发设计与评审1、 项目经理构思系统设计，项目组开发成员一起讨论系统的设计，对设计形成较为清晰的思路；2、 项目经理负责编写概要设计文档，与开发经理、开发团队成员与测试负责人一起讨论概要设计；3、 概要设计完成后，项目经理编写详细设计文档、数据库设计文档和编码规范，各模块负责人负责编写所负责的模块进行详细设计；4、 设计文档编写完成后，发邮件通知开发经理、项目经理、测试负责人、相关开发人员和测试人员；5、 开发经理、项目经理、测试负责人、相关开发人员和测试人员对所提交的概要设计文档、详细设计文档进行审查，将建议和意见以邮件的形式反馈给模块负责人；6、 模块负责人收集邮件中的修改建议并对设计文档进行修改，同时回复邮件说明详细设计修改情况，修改后的详细设计commit到CVS；7、 如果对设计存在争议或出现明显不合理的设计，召开一个小型会议对异议进行讨论，有效解决设计所出现的分歧8、 测试负责人（或专门的PPQA）对开发最终修改的详细设计计划进行检查，并确认所有文档都已经commit到CVS。注：在大型的项目中，必须先完成概要设计后再完成详细设计，在小项目或需求中可做适当剪裁概要设计与详细设计合在一起完成。四、测试方案与评审1、在项目的设计阶段，测试负责人根据规范文档、功能列表和概要文档编写总体测试方案与性能测试方案；2、测试方案编写完成后，发邮件通知开发经理、项目经理、相关开发人员和测试人员；3、开发经理、项目经理、测试负责人、相关开发人员和测试人员对所提交的测试方案进行审查，开发经理和项目经理对测试方案进行总体性的审查，而各模块负责人则负责相关模块或功能的测试方案的审查，将建议和意见以邮件的形式反馈给测试负责人；4、测试负责人收集邮件中的修改建议并对测试方案进行修改，同时回复邮件说明测试方案修改情况，修改后的测试方案commit到CVS；5、测试负责人（或专门的PPQA）对最终修改的测试方案进行检查，并确认所有文档都已经commit到CVS。五、编码实现与单元测试1、在产品详细设计完成后，开发工程师依据设计进行编码工作；2、编码完成后，开发工程师编写单元测试案例并进行单元测试，单元测试完成后提交单元测试报告；3、项目经理根据项目实际情况对开发工程师编写的代码组织Code Review，记录相关问题；4、产品模块单元测试完成后，开发之间进行产品联调测试，并修改所发现问题以及提交联调测试报告；5、产品初步完成后，在提交测试前进行一次产品演示，参加人员包括开发经理、项目经理、测试负责人、开发工程师、测试工程师、售前工程师与售后工程师，在演示的过程中对产品提出改进建议；6、各模块负责人对Code Review以及产品展示所发现的问题进行修改，相关的代码与文档commit到CVS；7、项目经理对编码完成后的系统进行确认，确保提交测试的系统是可运行的，测试负责人（或专门的PPQA）确认所有文档和代码都已经commit到CVS。六、测试设计与评审1、 在项目编码阶段，测试方案编写完成后，测试负责人或相关测试人员根据测试方案、规范文档、功能列表和详细设计进行测试用例设计；2、 测试案例设计的类型包括功能测试，边界测试，异常测试，性能测试，压力测试等，在用例设计中，除了功能测试案例外，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题；3、 在编写测试案例的过程中，对于存在疑问的地方或测试重点，主动与开发负责人或项目经理沟通讨论，一方面有助于设计完善的测试案例，另一方面也有助于开发进一步清晰编码思路；4、 测试用例编写完成后，发邮件给开发经理、项目经理、相关开发人员和测试人员；5、 开发经理、项目经理、相关开发人员和测试人员对所提交的测试案例进行审查，开发经理与项目经理对测试案例进行总体性的检查，各模块负责人则负责检查自己所负责的测试案例，将建议和意见以邮件的形式反馈给测试负责人；6、 测试负责人收集大家的邮件对测试案例进行修改完善，同时回复邮件说明修改情况，如果存在争议则召开一个小型会议对异议进行讨论，修改后的测试案例commit到CVS；7、 测试用例编写完成之后需要不断完善，软件产品新增功能或更新需求后，测试案例必须配套修改更新；在测试过程中发现设计测试案例时考虑不周，需要对测试案例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试案例存在漏洞造成，也需要对测试案例进行完善；8、 测试负责人（或专门的PPQA）对最终修改测试案例进行检查，并确认所有文档都已经commit到CVS。七、测试实施1、代码提交前一天准备相关的测试环境（如服务器或数据库等），代码提交后测试人员向Build Master申请打包，并搭建正式测试环境，为了不做到测试以及确保产品可以跨平台，每个测试人员各自搭建一个测试环境，每个平台至少要有一个以上的测试人员负责；2、测试环境搭建好后进行烟雾测试，如果烟雾测试通过则继续详细的功能测试，否则中断测试并返回给开发；3、测试人员按照预定的测试计划和测试方案逐项对测试案例进行测试，在测试过程中发现的任何与预期目标不符的现象和问题都必须详细记录下来，填写测试记录，在必要的时候协助开发追踪与修改所发现的问题；如果在测试的过程中发现重大的bug或因为某些bug导致测试不能继续，测试中断并返回给开发；4、每个测试阶段测试结束后，由测试负责人总结测试情况，对测试结果进行分析和下一阶段测试测试计划与可能引进的bug数量进行预测，并提交“测试阶段分析报告”，并发送给开发经理、项目经理、相关测试人员和开发人员；5、开发经理对测试阶段分析报告中存在的问题采取恰当的措施和调整相关资源，确保下一阶段的开发与测试计划顺利进行；6、开发对bug进行修改；7、开发对bug修改后测试人员进行回归测试，经过修改的软件可能仍然包含着错误，甚至引入了新的错误，因此，对于修改以后的程序和文档，按照修改的方法和影响的范围，必须重新进行有关的测试；8、产品的功能比较完善后，进行产品的性能压力测试，并根据测试结果进行性能调优；9、确认测试，在软件发布前，对产品进行确认测试；10、当测试产品达到测试计划所制定的产品质量目标和测试质量目标，整理产品发布包和编写相关文档，确认发布包和文档完整后进行产品发布。八、产品发布当测试产品达到测试计划所制定的产品质量目标和测试质量目标，整理产品发布包和编写相关文档，在发布前对照功能列表进行一次全面的确认测试，确认发布包和文档完整后进行产品发布。对于新产品来说，必要的文档必须包括：（1） 产品安装操作手册;（2） 产品白皮书;（3） 产品管理维护手册;（4） 用户操作手册;（5） 总体测试报告（6）性能测试报告。九、版本控制在测试过程中，软件的打包统一由Build Master完成。新版本软件发布之后，马上对代码进行质量控制：（1） Build Master给新版本的源代码打一个cvs tag，方便代码回滚check out。比如，发布版本为IAGW1.0.0，则给该软件源代码也打一个与发布版本相同名字的tag IAGW1.0.0。这样做的一个好处是，在目前的软件的基础上做了修改并发布新的版本后，如果需要check out某个版本的源代码，则可以通过这个版本的tag来check out，代码的修改可以在该版本上进行。（2） Build Master对新发布的软件源代码进行cvs lock，不允许开发人员在软件发布之后commit源代码，直到有新版本需求修改再给开发人员开放commit权限。这样做的好处是避免开发人员随意修改和commit源代码，确保源代码服务器上的源代码版本与当前最新的发布版本一致。十、自动测试产品稳定后，进行自动测试工具开发，对于稳定的功能使用自动测试工具进行测试，新增的功能使用手工测试，使用自动测试+手工测试的模式，可以大大提供测试效率。十一、小结：应用推广思路与体会整体思路是：首先对项目进行需求分析，有效的需求分析方法是需求分析人员、项目经理、开发经理与测试负责人分别阅读规范与原始需求，特别是需求分析负责人与项目经理，需要对需求进行深入的分析研究，然后开会讨论，消除对需求的误解与遗漏，讨论结束后编写功能列表说明文档与需求规格说明书并评审；对于规范中不明确的问题集中后由测试负责人（或需求分析负责人）直接与移动总规范负责人直接交流，确保不会因为规范的理解不正确导致项目实现与需求不一致。需求分析完成后，编写项目计划书与测试计划书；项目计划、测试计划编写前先开会讨论，由模块负责人估算工作量，能确定的问题和时间安排都在讨论中确定下来，然后根据工作量和工程需求制定项目计划和测试计划。开发在编码前需要进行概要设计和详细设计，开发工程师在编码前对系统的总体设计架构、各自所负责的模块有一个清晰的设计思路，经评审后确认模块的设计是否合理；开发在编码完成后在提交测试前必须进行单元测试与联调测试，提交给测试的软件是一个可运行的产品。测试工作中，在项目设计或编码阶段，测试负责人对项目进行测试设计，指导测试实施有依可循，在编写案例的过程中会遇到很多与流程和细节处理相关的问题，与开发一起讨论也有助于提前发现问题与完善代码；在测试实施阶段，测试人员记录所发现的问题，并协助开发及时解决，在测试过程中所遇到的问题，测试负责人进行记录和分析，在每个阶段完成后提交经分析后的测试阶段报告，在软件测试阶段报告中总结分析了测试过程中所发现的问题并对这些问题提出解决建议，在后续的开发与测试中进行改进与调整，确保项目能够按时保质发布。为了节约资源，计划或设计都是以邮件的形式进行评审；对于存在严整分歧的问题，组织一个小型会议进行讨论有效解决问题，小型讨论会是解决问题的一种有效途径，任何问题都可以通过face-to-face的交流达到共识。软件的管理和版本管理则由Build Master负责，确保软件得到良好的控制。在整个项目实施的过程中，需要有一个PPQA对流程进行检查与监督。这个精简的实施流程，不但确保了软件的质量，而且实施成本较低，在团队实施中非常容易推广。 在整个流程中，测试负责人除了负责测试相关任务以外，同时承担了需求管理、流程跟踪、协调沟通等工作（当然，也可由项目经理或开发经理等担任），在其中由测试推动项目开发与实现，在开发成员之间、开发与测试之间搭了一座沟通的桥梁，这样的一个协调与推动促进了项目的顺利完成，适合于五至二十的小型团队。不过这种测试与开发的模式，对测试负责人的要求很高，不但要求测试负责人具有很强的责任心与沟通协调能力，而且还需要具有很高的业务分析能力和CMMI5实施经验。CMMI5在小型项目中的成本过高，根据自己对CMMI5的实施体会与在实际项目中的应用，在项目实施的过程中精简了CMMI5的实施流程和部分文档，这个精简的流程在项目实施的过程中既可以确保流程规范与质量信赖又可以节约项目成本。以下跟大家分享一下CMMI5在项目中的精简应用：一、需求与规范的管理1、 由测试负责人（或专门的需求分析负责人）统一接收来自移动总的行业网关相关规范和新需求，测试负责人浏览规范获知大意后回复邮件，将规范和新需求转发给开发经理、项目经理、相关的开发人员和测试人员，同时commit到CVS；2、 测试负责人（或专门的需求分析负责人）、项目经理仔细阅读规范与需求后，对规范和新需求进行研究，并就难点和疑点进行讨论，整理出重点内容，并将重点内容发给开发经理、项目经理、相关的开发人员和测试人员，同时commit到CVS；3、 开发经理、项目经理、测试负责人、需求分析负责人、相关的开发人员与测试人员开会对规范、需求和重点内容进行讨论，确定需求的具体含义以及最终实现的需求和功能点；4、 项目经理根据规范、需求和开会讨论结果编写需求规格说明书与功能列表，测试负责人（或专门的需求分析负责人）对文档进行检查并修改完善，然后commit到CVS；5、 测试负责人（或专门的PPQA）确认所有相关文档经过了评审并都已经commit到CVS。二、项目计划与测试计划1、 由开发经理组织项目计划讨论会，在讨论会上各开发负责人对自己所负责的模块所需要的工作量进行评估，根据工作量和工程需求初步确定总体开发计划、测试计划和发布时间；2、项目经理根据估算工作量和工程需求编写项目计划，使用CMMI5总体测试计划模板并对其进行适当的裁剪和补充，编写适合本项目的项目计划；3、测试负责人根据项目计划与发布时间编写测试计划，使用CMMI5总体测试计划模板并对其进行适当的裁剪和补充，编写适合本项目的测试计划；4、项目计划与测试计划编写完成后发送给开发经理、项目经理、相关的开发人员和测试人员，开发经理、项目经理、相关的开发人员和测试人员阅读项目计划、测试计划后将建议和意见以邮件的形式反馈给项目经理与测试负责人，项目经理与测试负责人收集大家的邮件分别对项目计划与测试计划进行修改完善，同时回复邮件说明项目计划与测试计划修改情况，如果存在争议则召开一个小型会议对异议进行讨论，修改后的项目计划、测试计划commit到CVS；5、测试负责人（或专门的PPQA）确认所有相关文档经过了评审并都已经commit到CVS。三、开发设计与评审1、 项目经理构思系统设计，项目组开发成员一起讨论系统的设计，对设计形成较为清晰的思路；2、 项目经理负责编写概要设计文档，与开发经理、开发团队成员与测试负责人一起讨论概要设计；3、 概要设计完成后，项目经理编写详细设计文档、数据库设计文档和编码规范，各模块负责人负责编写所负责的模块进行详细设计；4、 设计文档编写完成后，发邮件通知开发经理、项目经理、测试负责人、相关开发人员和测试人员；5、 开发经理、项目经理、测试负责人、相关开发人员和测试人员对所提交的概要设计文档、详细设计文档进行审查，将建议和意见以邮件的形式反馈给模块负责人；6、 模块负责人收集邮件中的修改建议并对设计文档进行修改，同时回复邮件说明详细设计修改情况，修改后的详细设计commit到CVS；7、 如果对设计存在争议或出现明显不合理的设计，召开一个小型会议对异议进行讨论，有效解决设计所出现的分歧8、 测试负责人（或专门的PPQA）对开发最终修改的详细设计计划进行检查，并确认所有文档都已经commit到CVS。注：在大型的项目中，必须先完成概要设计后再完成详细设计，在小项目或需求中可做适当剪裁概要设计与详细设计合在一起完成。四、测试方案与评审1、在项目的设计阶段，测试负责人根据规范文档、功能列表和概要文档编写总体测试方案与性能测试方案；2、测试方案编写完成后，发邮件通知开发经理、项目经理、相关开发人员和测试人员；3、开发经理、项目经理、测试负责人、相关开发人员和测试人员对所提交的测试方案进行审查，开发经理和项目经理对测试方案进行总体性的审查，而各模块负责人则负责相关模块或功能的测试方案的审查，将建议和意见以邮件的形式反馈给测试负责人；4、测试负责人收集邮件中的修改建议并对测试方案进行修改，同时回复邮件说明测试方案修改情况，修改后的测试方案commit到CVS；5、测试负责人（或专门的PPQA）对最终修改的测试方案进行检查，并确认所有文档都已经commit到CVS。五、编码实现与单元测试1、在产品详细设计完成后，开发工程师依据设计进行编码工作；2、编码完成后，开发工程师编写单元测试案例并进行单元测试，单元测试完成后提交单元测试报告；3、项目经理根据项目实际情况对开发工程师编写的代码组织Code Review，记录相关问题；4、产品模块单元测试完成后，开发之间进行产品联调测试，并修改所发现问题以及提交联调测试报告；5、产品初步完成后，在提交测试前进行一次产品演示，参加人员包括开发经理、项目经理、测试负责人、开发工程师、测试工程师、售前工程师与售后工程师，在演示的过程中对产品提出改进建议；6、各模块负责人对Code Review以及产品展示所发现的问题进行修改，相关的代码与文档commit到CVS；7、项目经理对编码完成后的系统进行确认，确保提交测试的系统是可运行的，测试负责人（或专门的PPQA）确认所有文档和代码都已经commit到CVS。六、测试设计与评审1、 在项目编码阶段，测试方案编写完成后，测试负责人或相关测试人员根据测试方案、规范文档、功能列表和详细设计进行测试用例设计；2、 测试案例设计的类型包括功能测试，边界测试，异常测试，性能测试，压力测试等，在用例设计中，除了功能测试案例外，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题；3、 在编写测试案例的过程中，对于存在疑问的地方或测试重点，主动与开发负责人或项目经理沟通讨论，一方面有助于设计完善的测试案例，另一方面也有助于开发进一步清晰编码思路；4、 测试用例编写完成后，发邮件给开发经理、项目经理、相关开发人员和测试人员；5、 开发经理、项目经理、相关开发人员和测试人员对所提交的测试案例进行审查，开发经理与项目经理对测试案例进行总体性的检查，各模块负责人则负责检查自己所负责的测试案例，将建议和意见以邮件的形式反馈给测试负责人；6、 测试负责人收集大家的邮件对测试案例进行修改完善，同时回复邮件说明修改情况，如果存在争议则召开一个小型会议对异议进行讨论，修改后的测试案例commit到CVS；7、 测试用例编写完成之后需要不断完善，软件产品新增功能或更新需求后，测试案例必须配套修改更新；在测试过程中发现设计测试案例时考虑不周，需要对测试案例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试案例存在漏洞造成，也需要对测试案例进行完善；8、 测试负责人（或专门的PPQA）对最终修改测试案例进行检查，并确认所有文档都已经commit到CVS。七、测试实施1、代码提交前一天准备相关的测试环境（如服务器或数据库等），代码提交后测试人员向Build Master申请打包，并搭建正式测试环境，为了不做到测试以及确保产品可以跨平台，每个测试人员各自搭建一个测试环境，每个平台至少要有一个以上的测试人员负责；2、测试环境搭建好后进行烟雾测试，如果烟雾测试通过则继续详细的功能测试，否则中断测试并返回给开发；3、测试人员按照预定的测试计划和测试方案逐项对测试案例进行测试，在测试过程中发现的任何与预期目标不符的现象和问题都必须详细记录下来，填写测试记录，在必要的时候协助开发追踪与修改所发现的问题；如果在测试的过程中发现重大的bug或因为某些bug导致测试不能继续，测试中断并返回给开发；4、每个测试阶段测试结束后，由测试负责人总结测试情况，对测试结果进行分析和下一阶段测试测试计划与可能引进的bug数量进行预测，并提交“测试阶段分析报告”，并发送给开发经理、项目经理、相关测试人员和开发人员；5、开发经理对测试阶段分析报告中存在的问题采取恰当的措施和调整相关资源，确保下一阶段的开发与测试计划顺利进行；6、开发对bug进行修改；7、开发对bug修改后测试人员进行回归测试，经过修改的软件可能仍然包含着错误，甚至引入了新的错误，因此，对于修改以后的程序和文档，按照修改的方法和影响的范围，必须重新进行有关的测试；8、产品的功能比较完善后，进行产品的性能压力测试，并根据测试结果进行性能调优；9、确认测试，在软件发布前，对产品进行确认测试；10、当测试产品达到测试计划所制定的产品质量目标和测试质量目标，整理产品发布包和编写相关文档，确认发布包和文档完整后进行产品发布。八、产品发布当测试产品达到测试计划所制定的产品质量目标和测试质量目标，整理产品发布包和编写相关文档，在发布前对照功能列表进行一次全面的确认测试，确认发布包和文档完整后进行产品发布。对于新产品来说，必要的文档必须包括：（1） 产品安装操作手册;（2） 产品白皮书;（3） 产品管理维护手册;（4） 用户操作手册;（5） 总体测试报告（6）性能测试报告。九、版本控制在测试过程中，软件的打包统一由Build Master完成。新版本软件发布之后，马上对代码进行质量控制：（1） Build Master给新版本的源代码打一个cvs tag，方便代码回滚check out。比如，发布版本为IAGW1.0.0，则给该软件源代码也打一个与发布版本相同名字的tag IAGW1.0.0。这样做的一个好处是，在目前的软件的基础上做了修改并发布新的版本后，如果需要check out某个版本的源代码，则可以通过这个版本的tag来check out，代码的修改可以在该版本上进行。（2） Build Master对新发布的软件源代码进行cvs lock，不允许开发人员在软件发布之后commit源代码，直到有新版本需求修改再给开发人员开放commit权限。这样做的好处是避免开发人员随意修改和commit源代码，确保源代码服务器上的源代码版本与当前最新的发布版本一致。十、自动测试产品稳定后，进行自动测试工具开发，对于稳定的功能使用自动测试工具进行测试，新增的功能使用手工测试，使用自动测试+手工测试的模式，可以大大提供测试效率。十一、小结：应用推广思路与体会整体思路是：首先对项目进行需求分析，有效的需求分析方法是需求分析人员、项目经理、开发经理与测试负责人分别阅读规范与原始需求，特别是需求分析负责人与项目经理，需要对需求进行深入的分析研究，然后开会讨论，消除对需求的误解与遗漏，讨论结束后编写功能列表说明文档与需求规格说明书并评审；对于规范中不明确的问题集中后由测试负责人（或需求分析负责人）直接与移动总规范负责人直接交流，确保不会因为规范的理解不正确导致项目实现与需求不一致。需求分析完成后，编写项目计划书与测试计划书；项目计划、测试计划编写前先开会讨论，由模块负责人估算工作量，能确定的问题和时间安排都在讨论中确定下来，然后根据工作量和工程需求制定项目计划和测试计划。开发在编码前需要进行概要设计和详细设计，开发工程师在编码前对系统的总体设计架构、各自所负责的模块有一个清晰的设计思路，经评审后确认模块的设计是否合理；开发在编码完成后在提交测试前必须进行单元测试与联调测试，提交给测试的软件是一个可运行的产品。测试工作中，在项目设计或编码阶段，测试负责人对项目进行测试设计，指导测试实施有依可循，在编写案例的过程中会遇到很多与流程和细节处理相关的问题，与开发一起讨论也有助于提前发现问题与完善代码；在测试实施阶段，测试人员记录所发现的问题，并协助开发及时解决，在测试过程中所遇到的问题，测试负责人进行记录和分析，在每个阶段完成后提交经分析后的测试阶段报告，在软件测试阶段报告中总结分析了测试过程中所发现的问题并对这些问题提出解决建议，在后续的开发与测试中进行改进与调整，确保项目能够按时保质发布。为了节约资源，计划或设计都是以邮件的形式进行评审；对于存在严整分歧的问题，组织一个小型会议进行讨论有效解决问题，小型讨论会是解决问题的一种有效途径，任何问题都可以通过face-to-face的交流达到共识。软件的管理和版本管理则由Build Master负责，确保软件得到良好的控制。在整个项目实施的过程中，需要有一个PPQA对流程进行检查与监督。这个精简的实施流程，不但确保了软件的质量，而且实施成本较低，在团队实施中非常容易推广。 在整个流程中，测试负责人除了负责测试相关任务以外，同时承担了需求管理、流程跟踪、协调沟通等工作（当然，也可由项目经理或开发经理等担任），在其中由测试推动项目开发与实现，在开发成员之间、开发与测试之间搭了一座沟通的桥梁，这样的一个协调与推动促进了项目的顺利完成，适合于五至二十的小型团队。不过这种测试与开发的模式，对测试负责人的要求很高，不但要求测试负责人具有很强的责任心与沟通协调能力，而且还需要具有很高的业务分析能力和CMMI5实施经验。QA的工作方法探讨1前言近期有SQA抱怨工作内容不明确，发展方向不清晰；同时也发现有些QA在实际工作中对工作方法、目的和意义了解不够，导致对待工作任务比较粗糙，工作效果大打折扣。这种现象对于在质量工作领域的筒子们来说很正常，就如同人力资源岗位一样，这个领域和岗位是企业运作的辅助岗位，是一个保障性的平台，是为了保障公司的主要业务能够顺畅运行的有效机制。然而，正因为这样，很多人容易迷失方向，不清楚自己的未来在哪里，如何工作才能起到作用，为公司业绩带来影响的同时为自己的未来做好铺垫。要做一个合格的SQA，需要走的路很长。国外有很多案例，其中一些模式都值得我们借鉴，比如：SQA需要至少5年的开发经验，SQA有权给项目开不符合项并责成项目整改，SQA可以直接向高层领导汇报等。在中国国情下，有些做法很难被认同。那么，SQA该怎么做呢？这里稍微整理一下思路，给还在这个岗位或立志于这个岗位的筒子们参考。2SQA的工作范围和职责SQA的工作范围和职责，不同国家、不同公司的差别还是比较大的。主要分为：过程QA、产品QA，这俩类的具体做法也差别很大。过程QA：一般公司的定位是过程和方法推广、过程审计、过程数据收集和分析、过程改进，有些公司分得更细致，过程QA只是做过程审计，不关心改进工作，另外设立了过程改进工程师。产品QA：一把公司的定位主要是做软件系统测试，验证产品需求和发现产品缺陷为目的，确保在产品发布到客户前产品符合客户提出的需求，质量达到可发布的标准。这里重点说说过程SQA的主要工作范围和职责：1）熟悉和了解项目和产品特征，理解和指导项目进行过程定义；2）熟悉和了解企业标准和公司标准，并指导项目按照标准实施项目活动；3）跟踪项目进展，了解项目偏差情况，包括进度、质量、范围、问题和风险等，并及时向项目经理发出预警；4）根据项目计划制定项目审计计划，并按照计划实施审计，其中包括过程审计和部分产品审计；5）针对审计的不符合项督促制定预防纠正措施，并跟踪关闭；6）制定项目数据收集和度量计划，并按计划实施数据收集、分析和报告；7）负责制定和实施组织级的内外部审计，以发现偏差和改进方向，为后续改进规划做准备。3SQA的工作方式职责很清楚，但操作起来却有些困难。作为监管部门，难免在实施中会有很多阻碍。这里面首先我们自己要理清楚思路，以下这几点就是两个核心思想：知己知彼（1和2）、胡萝卜（3）加大棒（4、5）的策略：1）项目和产品运作模式的理解对于自己要服务和监管的项目或产品，如果自己是外行，完全不懂，那么你怎么能够理解项目的语言，知道项目需要什么过程、适合什么管理模式呢？接手一个项目，最初始的工作内容就是项目和产品的学习。作为SQA不需要了解到代码级，但是需要懂得产品需求、产品系统架构、主要的设计方案和测试方案，只有这样才能与项目组有着共同语言，给出的建议或意见才更有发言权。2）对项目进展的了解度知道了产品干什么的，项目的计划和范围，接下来的是项目进展跟踪。很多SQA不太跟进项目，待审核时则拿着检查单，凭借检查单的条目机械的去寻找证据。检查单帮助我们关注到该关注的点，不至于遗漏。但是检查单无法帮助我们理解项目组为什么这样做，是否合理。只有跟进了项目，知道项目如何在开展，你才能很快了解到检查项缺陷是项目组未有效开展还是标准本身需要调整。由于不属于项目组的直接成员，很多信息只能间接获取。我们推荐的一些方式包括：日常沟通、参加项目例会、参加项目方案讨论或评审、参加里程碑会议、查阅项目文档、查看项目数据、了解项目问题或风险解决情况等等，通过这些活动以方便要使得项目组认为SQA是项目组成员之一，同时也能获得很多的项目信息，便于判断当前项目需要的支持或者改进。关于参加项目活动，有一个现象是：项目组通常不会主动的通知SQA去参加，导致SQA不能及时参与项目活动获得相关信息。我们通常是与项目组项目经理协商，确定哪些活动是SQA必须参加的，并由项目经理通知到SQA。同时，也要求SQA主动关注项目的日常活动，自行选择参加。3）给以项目的咨询和支持度这点上其实是对SQA本身有很高的要求，如果自己对过程理解不到位，对产品和项目特点不清楚，对项目的组织结构和管理模式不熟悉，那么虽然有检查单帮助发现问题，但却不一定能给出合适的解决方案。这点不容易做到，也是项目人员最为关心和最易抱怨的。SQA除了以上的两点自身充实外，需要学习业界的很多专业知识，包括软件工程、度量、质量知识、组织标准和模板等，至少在过程领域是需要能发出权威的声音，获得项目的认可，在项目需要时能够给以必要的支持和引导。这其中包括：给以标准、制度和模板的使用指导，定期观察项目情况并及时提醒，定期出具项目质量数据给项目组做参考，协助项目经理分析项目问题等等，这些活动会让项目组真正体会到SQA的价值所作。4）畅通的汇报机制历来任何事情要有效推动都需要有胡萝卜加大棒，对于质量工作也是一样。光给以支持、引导和帮助，但是没有有效的惩罚措施，说什么也是白搭。遇到能力水平较高的项目团队，可能工作较好开展，但若遇到认识不到位的项目团队，此时光依靠单方面的引导而不给以压力，工作会在很长时间内不会有成效。虽然，我们说工作要做到人心，首先理解到位了再说操作的问题，但是实践中很多事情往往是先推动和落实，在此过程中不断加深理解。这种体验很多很多，也往往产生了良性的结果，因此是值得的。因此，在制度上需要给以保障，包括考核机制和汇报机制。说到汇报机制，这个度往往是SQA比较犯难的。什么情况下需要汇报给QA经理、产品总经理或高层？对审计发现问题的处理，我们的原则是：一般的不符合项，首先由QA与项目成员或项目经理协商制定改善措施，之后由项目组实施、QA跟踪关闭；以下情况SQA需要汇报给产品总经理及其QA经理：1是当项目组在计划时间内没有落实相关措施，且无任何合理的解释时；2是项目组有合理理由，但未在合理的期限内解决时；3是项目发生的问题或不符合程度比较严重时。此时QA经理需要与产品总经理沟通协商确定改进措施，并指派项目经理或专人进行处理；若仍然没有成效时，QA经理负责向公司高层汇报，以便督促相应工作的落实。5）对公司考核制度的把握公司制度体现了公司的业务方向和关注重点。对于软件产品而言，SQA的发现是保障产品质量、进度和成本的关键环节之一，需要作为KPI之一纳入考核体系。只有有了考核指标的要求，并逐步分解为可落实的措施上，才能有效开展工作。说到考核，有一点是需要关注的：在考核设计中对SQA工作成果的应用要关注最终结果而不是过程，最为简单的例子是，日常审核的结果不能作为考核内容，而半年或一年的定期审核，可以专门用于考核，以便于评估考核周期内项目的质量状况和改进情况。4SQA的审计方式和重点QA的审计其实是有方法的，而不是简单机械的使用检查单去审核。我们尤其反对那种日常不参与项目活动，只在审核时才出现的方式。然而到底要怎么审计效果才更好呢？1）检查单的使用使用检查单做审计是一种非常好的方式，检查单帮我们总结了需要审计的范围和关注点，好的检查单甚至也积累了很多人对某过程的深刻理解，对于知识传承、培养新人起着很重要的作用。同时，也是检查结果的一个客观反映，杜绝了太多的人为干扰。因此，我们要求所有组织标准和过程都要有检查单相对应，以便QA能够有效开展工作。但是，检查单本身的质量、使用检查单人的能力对于最终应用结果起着重要的影响。因此，我们重视检查单但不能依赖检查单，我们强调对各检查单条款的具体理解，并在检查中需要融会贯通。2）证据和访谈的使用SQA审计中很关注证据和访谈的作用，尤其是直接证据。由于在直接证据中能够很轻易的获取到项目实施情况的数据，从一定程度上客观反映了情况，也避免了与人交流的复杂性，尤其是对不喜欢与项目沟通的QA。有好处也有坏处，既然是看证据，项目团队也存在为了审核而造证据的现象，无法真实反映项目能力水平。因此，审核要采取多种方法，包括看证据、访谈合适的人员，同时结合日常对项目的了解给出判断。若有了日常的了解，基本上我们能够看出来证据的有效性和项目的实际情况，并能够给出合适的审核结果。3）规范性和有效性问题审核要关注的两个方面，1是规范性，2是有效性。规范性比较容易检查，通过检查单、证据和访谈都可以获取到，更多看到的执行结果。而有效性要求更高，不仅仅关注做到没有，而且关注怎么做，为什么这么做的问题。这里就需要SQA有着较高的素质才能做好。有两点我们发现SQA经常遗漏，但实际上却对审核有效性很重要：1是检查需求的可追溯性，2是检查计划执行状况。任何过程的检查前，我们需要先了解项目初始计划、当前计划和当前状况，以便确定项目当前应该做到什么，没有做到什么；当检查项目的工程过程时，无论是设计、开发还是测试过程，都需要关注需求的可追溯性，抽查几条需求，检查是否在相应的设计开发和测试环节中都考虑到，这是很关键的，只有这样才能看出项目团队是否是为了文档而写文档，而是真正考虑了项目的需求。4）检查计划和检查结果SQA在项目启动后就应该制定项目审核计划，审核计划应该与项目立项时的计划相匹配。当项目计划调整时，QA审核计划需要相应的进行调整，以便能够跟上项目的节奏，起到及时预警的作用。每次审计的结果，对于符合项和不符合项都需要进行确认，包括项目团队的确认和QA经理的评审，尤其是针对新QA的工作成果更需要评审和确认的过程。很多QA经理一忙就难以保证这点，实际上是工作质量的缺失。QA的由来我们知道，国外很多的大公司，QA的职责就是测试（主要是系统测试），比如IBM、CA、PeopleSoft等。其实在最初，几乎所有的公司都是这样的。后来，由于缺乏有效的项目计划和项目管理，留给系统测试的时间很少（注：我以前做的一个项目，项目经理就明确告诉我系统测试就1天，没得商量）。另外，需求变化太快，没有完整的需求文档，测试人员就只能根据自己的想象来测试。这样一来，测试就很难保障产品的质量，事先预防的QA职能就应运而生。事先预防其实是借鉴了TQM的思想，而且也符合软件工程“缺陷越早发现越早修改越经济”的原则。这些思想的渊源还可以追溯到中国古代的典故中，比如曲突徙薪、扁鹊论医术等。特别是扁鹊论医术这个典故，我偶然在国外的一篇文章中看到了（后来在林锐的文章中也看到了），常感叹我们国人连祖先的思想文化遗产都丢的差不多了。3 QA的现在目前，实施CMM的企业越来越多了。CMM模型就要求建立QA角色。这里的QA类似于过程警察，主要职责是，检查开发和管理活动是否与已定的过程策略、标准和流程一致，检查工作产品是否遵循模板规定的内容和格式。在这些企业中，一般还要求QA独立于项目组，以保障评价的客观性。从国内来看，多数的QA没有技术背景，检查出的偏差多为鸡毛蒜皮，再加上自己没有令人信服的背景，领导也不支持，当然做起来就很困难了。缺乏信任和支持只是一个方面，QA工作本身就很具挑战性。它要求QA具有软件工程的知识、软件开发的知识、行业背景的知识、数理统计的知识、项目管理的知识、质量管理的知识等等。我们常常遇到这样的问题，改进到一定程度就很难突破，感觉心有余而力不足了，就开始郁闷了。后来通过学习、培训、交流，思想和技能得到升华，又发现了木桶中最短的那块，然后又开始改进，然后又遇到了玻璃天花板，然后就这样处于郁闷的循环中。假使我们掌握了所有的知识，能突破所有的玻璃天花板，那是不是QA就可以一帆风顺了。答案是否定的。QA角色定义本身就有很大的局限性。QA充当的是过程警察的角色，无论是否有意义，都专横地强制过程的执行，容易在项目组中造成敌对的关系，受到排挤，而且这种警察的姿态也破坏了团队精神。如此一来，QA工作还需要的是人际关系技能，就如我以前写的质量平衡和QA应该独立于项目组吗？一样，艺术化地处理这种关系。4 QA的未来从某种程度上说，独立的QA审查机制是瀑布模型的产物。随着现代软件开发技术的演变，螺旋模型和迭代模型的兴起，QA机制正在悄然发生变化。这种变化就是从独立专职的QA向贯穿过程的兼职QA演变。在CMMI模型中，这种兼职的QA也是被允许的。为什么会发生这种改变呢？无论是XP、RUP还是其它先进的方法论，都是先产生架构，然后再增量开发，直到完成。这种模式中，需求和设计缺陷在各个迭代周期被所尽早发现和修复，质量也内建于架构和过程中，项目的成本和进度也得到保障。到那时，是不是独立的QA就不复存在了呢？有些成熟度较低的企业还是需要的，主要是保证过程执行的有效性和评价的客观性 质量平衡前几日，我有幸听了唐骏关于“成功软件企业的经营模式与文化”的演讲。在会上，他谈到中国目前靠软件盈利（一定规模）的企业最多不超过5家。这一结论深深地震撼了我。难道国内成千上万家软件企业都在亏损吗？而为什么亏损呢？我想，一个个的软件项目延期、超出预算、质量低下是亏损的原因，而最根本的不是技术问题，而是管理问题。质量管理也是很重要的方面。从理论来看，质量管理应该属于项目管理的一部分。我们在实际运作过程中也不要把项目管理和质量管理分离开来。有些项目经理认为“提高质量就意味着成本更高、延迟交付”，这是一个比较片面的观点。多数情况下，质量和进度不是矛盾和冤家，而是可以协调和统一的。举例来说，移动网管维护项目为完成一个约20人日的维护需求，在设计和编码阶段比计划多花了0.5人日，测试阶段就比计划少花了6.5人日完成。这说明质量不但提前了进度，而且降低了成本。在有些特殊情况下，比如规模较小、需求变化较快、进度较紧的项目，我们可以采取更为灵活、敏捷的开发方式，但是这些方式应该在不影响产品质量的前提下进行。然而，现实情况往往比较复杂，也许会存在质量与进度相对立的情况。在这种情况下，应该以公司的商业目标为基准，寻求质量、进度、成本三者之间的平衡。而如何寻找平衡点呢？由于项目相关者（包括公司、部门经理、项目经理、员工、客户等）对质量利益（包括短期利益和长期利益）的获得不同以及质量观念的差异，存在不同的平衡点，从而引起质量方面的纷争和抵触。为了协调项目相关者的这种矛盾，责权利最大的一方（一般是公司）应该起到关键的作用。一方面要解决质量观念差异的问题，最好通过自上而下的教育、培训。为什么需要自上而下呢？经验告诉我们，公司领导学好了质量管理方法，才能采用正确的质量管理方案，才能有更强的执行力，才能选用合格的质量人员，才能看得到比较明显的质量改善效果，才能形成良性循环。另一方面，就是授权相关人员进行监督，控制平衡点移动到最佳位置。一般情况下，公司的质量管理员应该担当这种责任，但领导需要授予他们相应的权利。在企业中，责任和权利是成正比的。如果质量管理员的地位无足轻重，那么必然导致产品质量无足轻重。从另一个层面来说，质量管理员应该具备双重