算上实习，到现在为止，我已经经历了三家软件公司，其中一家小外包，两家自主研发。
现在对这三家公司的流程做一下对比，也顺便反思下我所经历的测试流程中到底什么样的测试流程才是最适合的。
Company A：记得当时是老总和Monster拿着本《敏捷测试与用户故事》的书来制定敏捷流程规范的。说是流程规范，其实也只有流程，却没有多少规范。在整个范围内测试内，测试算的上是全程介入，并且在其中做个主要协调的工作：包括需求策划、需求制定、需求文档审核、TestCase编写、测试、报告。当然，在当时的环境下，所有的需求和测试都是为了开发在服务，只要保证开发出来的东西能让客户满意就行。
在当时的情况下，印象最深的就是对需求理解的比较透彻，毕竟，很多需求都是自己定的。所以在测试的时候也比较能快速的把握需求重点，再加上开发提供的开发测试重点，基本上测试优先级什么的都一目了然。但是，毕竟是为了开发的产品而做的测试，很多情况下，我们都只是不断的验证开发的产品和修改而已。
对当时的Company A来说，流程是最适合的，因为只要做出客户不诟病并且没有发生bug的产品就可以了；然而，对当时的测试来说，却是有点无奈的，下一步该做什么都比较模糊；结束的标志也很模糊。
Company B：最初进入的时候也没看到什么流程，因为开始只有一个项目。之后项目多起来之后，开始着手制定流程。我也有幸参与了部分规范流程的过程，并且在不断的调整优化流程的时候经常与产品部的人在为需求文档该怎么写而争执。最终，经过差不多一两个月的磨合和优化，算是找到了适合无线端产品的一条比较优化的流程。在这其中，测试参与的工作有：需求逻辑初审、需求评审会、测试、测试报告（拥有通过与否的决策权）。不过，因为无线端版本太多，变更太快，这部分的TestCase却因此而简化为0了。直到最后才慢慢做起来。
对于这种流程来说，灵活性是最好的，也确实满足了互联网产品快速更新的需求，同时也尽可能的保证测试质量。从需求到产品实现，再到发布，周期只需要很短的时间就能完成。然而，这阶段的测试过程却也比较模糊，虽然引入了轮次的概念，却没有形成有效的监控，同时，测试流程也处于一种蜕变期。现在应该已经好很多了吧。
Company C：刚进公司的时候，老大们就给我了一个软件测试流程的ppt，让我看。当时也是看的迷迷糊糊的，ppt写的比较简单，具体操作的时候发现有很多的不同之处。在此，先做个总结。Company C的测试流程很严格，也算是很规范了。测试职责包括需求评审、TestCase、TestCase评审、功能测试、压力测试、安全申请、线上跟踪。主要职责都集中在测试的范围内。
然后有时候经常会发现，策划和需求的相关文档几乎为0；开发的文档也少的可怜；测试积累的文档少的可怜，测试报告倒是很多。
在这种环境下，测试就显得有些被动。因为从需求评审到测试用例评审的时间很短，简陋的策划案或需求文档让TestCase很被动，有时候评审TestCase的时候还在修改需求上的问题。不过一旦进入测试流程的话，就会规范轻松很多，当然，我的意思是没有并行项目的时候。
对比了一下，发现三家公司的流程都似乎挺适合当时的现状。不过从测试角度来说，需求明确的测试工作是最好开展的；同时，测试流程规范的工作可以避免很多因为分工和责任不同而引起的问题。
至于取舍，如果没有兼得，还是得看个人了。