作为测试leader怎样保证测试的质量分析

作为测试Leader如何保证测试的质量？关于测试结果的质量评估的前提条件测试过程结果质量的评估并不是一件非常容易的事情，最少在现在的测试过程任务来说，测试过程任务的可观察性及其质量的可评估性并没有想象般的那么显而易见。虽然现在软件工程角度对于测试过程任务的划分来说，其可见性和观察性已经比以前的项目有着非常大的改进。但就测试过程结果本身来说，质量的评估并不是非常的容易，所以导致效率的评估也是一场空谈。对于基本相同的需求来说，测试过程的结果并不一定有一个可以很容易评定的标准，比如，是占用内存大，运行速度较快的程序比较好，还是占用内存小，运行速度较慢的程序比较好呢？当然，这是最少在两个程序都是在可以正常运行的情况下的比较。所以有一个最低标准：可以正常运行的程序肯定要比不能正常运行的程序要好，虽然也许不能正常运行的程序有着非常优良的架构，有着非常优良的设计，有着非常好的编码习惯及有着非常好的文档，但有一点，最最重要的一点，不能正常运行，所以，尽管可以正常运行的程序在结构上要稍稍欠缺一些，在设计上可能并没有照顾到方方面面，也许编码习惯会因这个测试组成员的个人差异而有不同层次的参差不齐，或者在一定程度上文档也没有完整性，但这个程序的最大的也是最重要的部分在于可以正常运行。所以，在对于测试过程结果质量的评估的最低标准应该是测试过程结果最低限度的符合需求并且可以正常的运行。关于测试过程结果质量的评估的需求标准从另一角度来说，测试过程结果最低符合标准可以正常运行后，可以从需求角度考察测试过程结果，对于测试过程结果来说，完完全全的符合需要的情况是非常非常的少，一般情况下总会有或多或少的不合适，当然，对于测试过程结果与需求的评定方面可以从功能点考虑，当然，功能点可以适当的细，这样，才能比较容易的观察到测试过程结果与需求的偏离度。当然，可能有些时候一些功能点所占的比重并没有其它某个功能点所占的比重那么大，但一般情况下，在系统越大的时候，功能点的比重越可以看得平均，在此，相对来说，大系统的需求偏离度的判定比小系统要容易一些。当然，这是从理论的角度考察整个测试过程项目后得出的结论，尤如从5000米的高空观察中国，发现除了人驾驶着汽车朝着不同方向运动外，很难再得到其它方面的信息。所以，从高屋建甐的角度来观察测试过程结果的质量，所得出的结论只会有一定的参考性，却也不能完全作为唯一的标准。从系统的整体架构方面评估测试过程质量系统的整体架构方面来说，需要有稳定性和稳固性两个方面。对于稳定性，比较合适的比喻是一个系统的整体架构在确定之后，对于需求的变更，可以产生不同的设计的变更，也可以产生需要分析方面的某种程度的反作用力，犹如现在的建筑，当确定了钢筋混凝土结构及房屋的架构设计后，对于房屋的一些其它方面的需求比如窗户的设计或者是屋内布局的设计不影响到已经确定的房屋的架构设计，系统的架构的稳定性越好，则系统相对于需求的可变化性就越小，相对来说，则系统适应大规模的需求变动的适应性就越差，但在这种情况下，系统的稳固性越好，有利于整个测试团队的磨合及整个测试团队的前进方向的专一性及成长方式的专一性。当然，大规模的需求变更并不是不允许，大规模的需求变更可能会引发系统整体架构的剧烈变动，具体变动未知，所以说系统的架构的稳定性和稳固性与系统架构的可适应性是相斥的一个方面，简单的说，一个系统的稳定性和稳固性越好，则系统架构的可适应性就越差，可适应性越差带来的影响是架构的变更成本的上升及开发团队的重新建设或者测试团队整体方向上的变更。及测试团队中成员的学习成本的上升。当然，上面所提到的系统的架构的设计的稳定性和稳固性及适应性的关系是在大规模的变更时的一种情况，比如从JAVA团队转型为C团队。从测试团队的成长评估测试过程结果的质量从测试团队的成长角度来评估测试过程结果的质量，是一个带有多数主观因素的评估，当测试团队中的每个人都在最合适的位置上的时候，则测试过程进程将会变得顺利和平滑，让做系统设计的人做系统设计，让擅长处理问题的人处理问题，让擅长文档化的人做文档化工作，在这一种状态工作的，对于测试团队的整体素质提高会有一定的作用，但当测试团队有少量变更的时候，可能原来做系统设计的人被放在了处理问题的位置，而处理问题的人去做了文档化工作，文档化的人去做了系统设计，在这一种情况下，对于测试团队个人的成长是比较有利的，最少在一定程度上，接触不同的方方面面，不论是在系统设计角度，问题处理角度，还是工作文档化角度上，在做擅长的任务的时候，都会不自觉的从其它角度来考虑问题，对于测试团队的后续需求的开发和测试团队的持续性成长是有好处的，但这种情况下带来的问题是不同位置上的人的学习成本的增加及做自己并不擅长时的工作时的结果并没有做自己擅长时的结果所得到的结果那么好，所以，按同样需求的来说，从测试团队的成长评估测试过程结果的话，对于测试团队的成长应该在不影响整体需求和时间约束等各方面的情况下，达到最大限度的成长。从测试的流程和过程改进评估测试过程结果的质量测试过程结果的质量与测试团队测试这个结果时经历的流程和过程有着相当大的关系。对于测试团队的流程和过程记录将会有助于改进现有的流程和过程，在这个角度上面，测试过程结果的质量应该在一定程度上取决于流程的记录和过程记录的完整程度。如果测试团队有应用改进后的流程，或者说在开发过程中，更替过流程，来观察测试过程速度或者效率的影响及当时小范围的结果的评定，观察整个测试过程及开发过程中的流程，对于在不同的观察对象所产生的效果和结果，及对于观察对象所涉及的过程和流程进行改进的建议也应该作为测试过程结果的质量的评估标准。从测试过程结果的文档建设及文档知识传递程度评估测试过程结果的质量对于测试过程结果的文档建设来说，非常广，非常全的文档当然是有好处的，但是在现实的情况下，并没有如此大的精力和时间去建设非常广，非常全的文档。所以，择其重要性而有选择性的进行文档建设，是一个测试团队所需要的，单纯从文档建设的数量上来评估测试过程结果的质量，是很失真的一种行为，但是如何去选择文档的重要性，不同的人有不同的观点，我觉得，文档的重要性一是对于整个测试过程有帮助的，另一是对当前需求的测试过程的知识传递程度两个方面来评定文档的重要性。就此，可以比较容易的观察到整个测试过程结果的文档建设及文档知识传递程度来评估测试过程结果的质量。相对来说，系统的架构设计的稳定性和稳固性在其所适应范围内的，比如我们可以划一个圆圈A，在圆圈A内，这个系统架构设计的稳定性和稳固性是表现的非常好，只要是符合圆圈A内的需求如何的变动，系统的架构都能非常灵活的适应。但当出了圆圈A进入圆圈B或者圈A的范围比设计的时候要大上整整一个圈的时候，则系统的稳定性和稳固性与可适应性表现的是相斥的关系。所以总结说，在系统架构的可适应范围内，系统架构的稳定性和稳固性与可适应性是呈相辅相成的，当需求的变更超越系统架构的可适应范围，则系统架构的稳定性和稳固性与可适应性是相斥的关系，即系统的稳定性和稳固性越好，在可适应范围内，它的适应性越强，适应所做变更的成本越低，当超越了适应范围，则它的适应性越差，它所做变更所做的成本将越高。对于此，如何评估一个测试过程结果的现有系统架构的质量将会是比较困难的事情，可以考虑从写入约束和写入其适应范围的角度来做一个评估。从测试团队的成长评估测试过程结果的质量从测试团队的成长角度来评估测试过程结果的质量，是一个带有多数主观因素的评估，当测试团队中的每个人都在最合适的位置上的时候，则测试过程进程将会变得顺利和平滑，让做系统设计的人做系统设计，让擅长处理问题的人处理问题，让擅长文档化的人做文档化工作，在这一种状态工作的，对于测试团队的整体素质提高会有一定的作用，但当测试团队有少量变更的时候，可能原来做系统设计的人被放在了处理问题的位置，而处理问题的人去做了文档化工作，文档化的人去做了系统设计，在这一种情况下，对于测试团队个人的成长是比较有利的，最少在一定程度上，接触不同的方方面面，不论是在系统设计角度，问题处理角度，还是工作文档化角度上，在做擅长的任务的时候，都会不自觉的从其它角度来考虑问题，对于测试团队的后续需求的开发和测试团队的持续性成长是有好处的，但这种情况下带来的问题是不同位置上的人的学习成本的增加及做自己并不擅长时的工作时的结果并没有做自己擅长时的结果所得到的结果那么好，所以，按同样需求的来说，从测试团队的成长评估测试过程结果的话，对于测试团队的成长应该在不影响整体需求和时间约束等各方面的情况下，达到最大限度的成长。从测试的流程和过程改进评估测试过程结果的质量测试过程结果的质量与测试团队测试这个结果时经历的流程和过程有着相当大的关系。对于测试团队的流程和过程记录将会有助于改进现有的流程和过程，在这个角度上面，测试过程结果的质量应该在一定程度上取决于流程的记录和过程记录的完整程度。如果测试团队有应用改进后的流程，或者说在开发过程中，更替过流程，来观察测试过程速度或者效率的影响及当时小范围的结果的评定，观察整个测试过程及开发过程中的流程，对于在不同的观察对象所产生的效果和结果，及对于观察对象所涉及的过程和流程进行改进的建议也应该作为测试过程结果的质量的评估标准。从测试过程结果的文档建设及文档知识传递程度评估测试过程结果的质量对于测试过程结果的文档建设来说，非常广，非常全的文档当然是有好处的，但是在现实的情况下，并没有如此大的精力和时间去建设非常广，非