测试团队已逐渐介入公司各项产品的测试，并根据团队的开发模式、产品方向不断调整测试策略、方法。团队创建至今颇有感概，特趁渊哥约稿之际，与大家分享一下我的从业经历（软件测试、软件项目经理）及公司现状下，测试团队的定位及存在意义，简文存在一些个人的意见，欢迎大家积极讨论、修正。首先，简单聊下软件测试的历史：软件测试起初是软件开发人员在完成代码后自发的一个代码检查的过程，直至1975年《测试数据选择的原理》后，软件测试才被正式确定为一种研究方向。
软件测试从最初的经典定义：测试是为发现错误而执行的一个程序或者系统的过程。发展到现下流行的定义：测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程。
我们可以从中发现，软件测试的理论随着软件项目的规模、复杂度不断增强，而不断完善的。软件测试目前已经不再是我们10-20年前所熟知的找缺陷的过程（由于国内软件测试的环境部，大部分理论研究均来自于国外，所以相关理论的应用、推广也比较滞后），软件测试已经成长为一项与软件开发类似，同样具有生命周期的持续过程性任务。在软件测试的每个生命周期，测试工程师的职责、工作任务和产出均有明确说明，每个阶段也有对应的评审过程以保证各项产出的准确性、有效性。从软件测试的最新定义看来，软件测试目前可做为整个软件项目中的一个子项目进行实施。
再来聊下与软件测试相关的，大家比较熟悉的几个名词：
缺陷（BUG），这是大家对软件测试产出最直观的认识，也是绝大部分国内公司考察软件测试工程师KPI中最直观的指标之一。大部分人对缺陷的认知还是比较狭隘的（包括笔者从业前2年），可能在大家看来只有功能无法使用、软件崩溃、数据无法读写、软件逻辑冗乱这些与应用相关的异常才称之为缺陷。
在阐述个人观点前，我们首先来辩证地认识缺陷的常规描述：缺陷即瑕疵、缺点、欠缺、不完美，从缺陷的定义看来缺陷是一个相对定义，他需要一个比照标准以判断是否与标准匹配。然后我们回到软件测试中的缺陷认知，类似的软件测试的缺陷也需要一个参照标准，凡是与标准不一致的功能、描述、输入、输出、UI、配色、布局、入口、出口、数据格式、数据精确度、数据流向、数据一致性等都可称之为缺陷。
软件测试的意义，这个命题有点类似于罗素悖论：从公司层面而言，各位领导期望在最短的时间，使用最少的人力完成项目的各类测试（功能、性能、UI、安全、兼容、安装/卸载、易用、压力、负载、文档）提交各类文档，并保证软件不存在缺陷；从测试团队而言，工程师希望公司投入更多的人力、时间对软件进行充分测试、尽可能发现更多潜在缺陷（事实上，缺陷永远无法消除。比如：尽管微软的开发，测试从业人员比例小于1比2，但是每年仍不停的发布补丁以修复各类缺陷），在进行多次充分测试后再进行结论文档书写。通常测试团队会在项目周期内，根据项目资料尽早进行测试准确，对客户关注部分进行详细测试，其余部分与需求规格说明匹配情况即结束了项目的测试。这类处理方式看似非常中庸，实为项目管理制下满足客户、领导要求最大化的无奈之举。
回到公司的测试团队及研发的各兄弟团队上来。在我初入公司时，公司有建制的团队为：开发、项目管理、运维、部门管理。公司测试团队空缺的情况下，部分测试任务被分配到开发团队和运维团队的日常工作中。这样做的弊端如下：
对于开发人员而言，检查自己的作品是一件虐心的活动。在这种心理下，开发人员很难较多地发现自己的作品存在的缺陷；
测试方法、测试理论的缺失，导致开发人员和运维人员很难定义什么样的现象属于有效缺陷，测试的效率较低；
测试在局部展开，很难形成有效的测试报告，并将测试成果运用于其他项目；
测试、缺陷修复的随意性，导致版本发布较为随意，版本管理比较困难；
因此开发、运维团队在很长一段时间内都在频繁处理如下问题：
修复客户使用过程中发现的缺陷；
修复缺陷更改过程中引入的新缺陷；
频繁发布、维护一些不够稳定的软件；
频繁重复同类型活动带来的抱怨、吐槽等负面行为；
随着部门管理团队和组织结构调整，目前研发团队的组织构架分为：部门管理、设计部、开发部、测试部、支持部和项目管理部，各部门的职责划分也日益清楚。测试作为研发质量保证部门，需要与设计、开发、支持和项目管理部门进行密切合作：
设计部门在将用户需求转换为UI设计和原型设计之初，需要对UI效果（包括：调色、布局、Label选择、字体<颜色、大小>等）和原型（包括：用户交互、页（界）面跳转、菜单层次及定义、业务逻辑等）做评审。通过评审（或客户认可）后的UI设计和原型设计将作为开发、测试后续工作的共同执行标准；
开发部门作为与测试部门息息相关的部门，两者之间不存在制约、从属关系。两个部门有着共同的目标：实现设计部门通过审核的UI设计和原型设计描述的功能、效果，所以两个部门不像大家想象中的那么对立（至于一些公司要拿开发人员的缺陷数说事儿，那也是人为造成的隔阂）。两者之间的关系就是下面的一个简单循环：
测试团队负责高效、高质地找到（复现）缺陷；
开发团队负责高效、高质地修复缺陷及缺陷影响范围；
测试团队负责验证开发团队的修复有效、完整；
在循环过程中，不可避免的要发生一些辩论，因此双方共同遵守同一标准在解决问题的过程显得非常重要。
项目管理部门（或者负责人）作为整个项目掌控者，需要在项目周期、人员、质量、其它资源、客户满意度之间找到平衡，最终使项目盈利。因此需要追踪（考察）设计、开发、测试三个部门的项目进度与预期计划（时间、成本）之间的匹配，测试部门作为质量控制部门需要向项目管理部门展示软件测试进度、软件测试结果、软件测试遇到的问题等，这些信息将作为项目管理部门作出变更、结项等行为的部分依据。
支持部作为项目上线后的监控部门，作为产品和客户间的接口人能够直接获取客户的反馈、软件运行的状态，事实上的软件质量验证者。测试团队需要在软件上线前，将软件已知的缺陷及规避方式、软件用户指南等资料与支持部门进行交接，保证支持团队对软件基本使用不存在困难。同时测试团队还负责支持部门反馈的客户修改建议、缺陷等内容发布前的测试工作。
随着各部门工作渐入佳境，测试团队结合研发目前积极推广的敏捷开发模式对研发各兄弟部门、公司建议如下：
明确岗位职责及项目团队角色，高效完成项目组任务（每个人不可能处理所有事情，只有专注的处理自己擅长事情，团队效率才能更高效，项目角色的意义也在此）。
尽早将设计成果、解决方案进行审核，尽量避免进入测试阶段发现设计类的缺陷。
严格按照流程开展各项工作，流程的意义在于规范团队成员的行为，尽量减少冗余沟通
工作效率和准确率。虽然在初期，某些流程规范不完整，大家可以定期地提出改进建议，优化流程，不能因噎废食。
提高测试团队成员个人技能，拓宽、加深项目成员测试广度和深度。
相信大家在适应、熟悉了流程和岗位职责后，大家的工作效率越来越高，工作成果越来越丰硕，公司的研发将为公司带来更多盈利。
