改进软件测试部门工作过程的小小看法
近来了看了一些文章，主题是讨论测试流程模式，因为随着敏捷开发的思想迅速被推广，许多公司在研发上都引入的敏捷的特性，自然，引入新的模式，并不意味着就丢了原来的模式，实际生产上，往往是采用传统的开发模式和敏捷思想并行，这种新旧混搭模式会暴露出许多问题，例如：
1、开发的周期变短，原来计划是三个月的开发周期，根据敏捷的方法来执行会被缩短为两个月。自然、测试的周期也会被压缩，甚至出现开发无法准时进入测试，而导致测试的时间再次被动地被影响到。
2、原来具有明确规范化的用需和软需，根据敏捷中弱文档思想，需求文档可能仅保留其中一份，更或者二者全无。缺少了需求的定义，如何提前进入熟悉产品、如何测试用例设计、如何执行手工测试，严重的问题摆在面前。
3、各种各样的会议变多，例如每日的站立会、产品规划会、成果演示会、开发总结会等等。这些会议往往都会要求测试方参与，可是参与了又往往无法从会议上获取有效的信息。
4、产品研发生产线上各个环节出现问题，产品部、开发部、界面部、测试部、品质保证部、运维部、市场部、各个环节上的信息传递可能因为模式的改变导致传递不及时而造成的反复确认和摩擦。种种此类问题都和测试方息息相关。
当然、为了解决因敏捷开发思想引入而对测试部门造成的压力，自然有与之对应的对策，即敏捷测试（探索性测试）、但是理论的东西总归是理论，拿来主义必然是行不通的，测试流程模式取决于研发的流程，因为测试流程也是属于研发流程的一部分，研发的模式应该作为改进测试模式的主要依据。当然，理论的东西照搬肯定不行，需要对其进行裁减优化为适合自身的实际情况。为了顺应开发模式的变更，测试部门的测试模式也应该是适当的引入探索测试的部分精华，例如更加强调测试人员的主动性、尽早地分析需求、从测试人员的角色到产品专员角色的互换、从被动的测试到主动的测试进行转换等等。
坦白讲，就俺目前的测试部门而论，其实早已沦入此般的困境，陷泥潭而难自拔，保守派、维新派、中立派（无所谓派）、啥子皆有。鞋子还是合脚的好，如果觉得不合脚了，不妨先让一只脚换换新鞋，感觉是否合脚。过程风险肯定存在，关键是选择一种可以合理规避风险的方案。一个人总对着自己背影哀叹是不会成长的，一个团队亦然！
