最近看了一些文章，关于测试是否有必要存在，不同的人或者不同的环境有不同的说法。
整体来说，测试这个角色是需要的，但这个角色是否专职，存在一定的争议。
大多数还是认为：不懂开发的产品，不是一个好的测试。
部分认为 开发就可以做为测试，不需要有专职人员进行担任测试的角色，进行独立的测试，这样不清楚内部的实现逻辑，也不能进行完全的测试。
有人提出，自己写的功能，自己测本来就不合理，随即就有人提出，开发交叉测试，避免自开自测的情形。
我个人认为，测试是有必要的。测试这个角色是需要独立存在的，毕竟专业的事还是要有专业的人去做。
但也同意上面的看法，开发进行自测，因为这样可以减少测试的工作量。
往往，开发进行测试大多是从接口层面进行测试，对于测试同学来说，还是先从ui层面进行测试；开发注重代码实现逻辑，但测试更注重业务逻辑；对于测试来说，更多的感知首先是系统是否“好用”。
且开发并不一定会清楚全部的业务逻辑，可能只是对自己的业务比较清楚，但对于整体业务逻辑并不明确。
同时角度不一样，思考的角度也不一样，对于测试来说，目的是为了交付一个高质量的系统，需要尽可能发现多的问题，避免客户使用时的遇到问题；而且测试需要站在客户角度来进行测试，从使用方面来看是否需要进行优化，以及当前的操作是否有意义。
最近，在项目中也有类似的情况，遇到开发直接和我说，感觉现在测试在公司没有地位，有时会有可有可无的状态，没有起到应有的作用。
说实话，个人也有这种感觉，有时也觉得是挺无力的，说到测试的地位，我倾向于测试自己去争取，不是说给予，但这样对测试要求同样比较高。
测试人员需要有一定的脾气，或者说在一定情况下需要一些强势，不妥协，对于不合理的事情需要有自己的坚持，学会说no。
但是有些情况，可能现实并不是这么理想。say no 又怎样？ 达不到效果，怎么都没用。
比如：对于交付类型的项目，客户指定了上线时间，而开发延时了提测，且提测不达标，这时测试拒绝？拒绝测试只能是浪费更多的测试时间，大多数情况测试同学是被动接受，最终都是带着已知的bug去上线。
但也不是所有的都是这样，造成这种情形的因素有很多，首先需要项目组对质量的要求有个明确的定位，这个大家目标一致，才能不会感到心力交瘁。
现状描述：
项目没有规范：
1、没有对应的负责人，负责人没有起到负责人的作用；
期望负责人应该做到：
制定开发计划、分配组员工作；
组内分工，团队整体配合；
跟进组内工作进度；
质量把控，对应的自测人员，以及明确对应的责任；
工作完成确认，确认组员的工作完成，而不是他说完成就是完成；
2、没有明确的流程规范：
期望的流程规范：
需求评审；
用例评审；
提测前开发自测；
提测规范；
发版规范；
3、测试找不到对应的责任人
比如 发现的bug被相互推脱
产品人员多的时候，确认需求不知道找谁确认，互相说不知道
4、没有明确的需求，测试较被动；
需求变更未通知到测试
变更未留文档
5、项目计划不明确。
忽然说要上线
上线前临时加需求--这个不可避免，但次数不要太多
上线节点说变就变，未曾提前通知。
最后，感觉先不用想太多，重要的是提升自己，能力在那摆着，还担心什么。
