思考：测试的起点

熟悉测试流程、理论基本是每个测试职位jd的标配
测试的流程是什么？很多人能说出个大概，比较主流的认知是，流程的起点就是从了解需求开始。但是了解需求的过程中测试具体需要做什么，怎么样才算了解需求了呢？就比较玄学了

今天团队分享了公司产品某个现有功能的回看，我并没有参与过这个功能线的测试，但是这种回看对测试产品具有通用性，颇受启发。
分享回看的功能是告警功能，比如通过邮件发送了平台的告警信息，平常的测试验证基本上是：准备条件、数据，触发告警，查看告警内容与产品设计的描述相符。然后解决掉告警的问题，可以自动关闭相关告警。
乍一看，流程上并没有大毛病，问题在于细节。告警邮件中只给出了告警内容，但是没有快速方式定位到告警的平台，比如链接；然后打开告警平台后也无法快速借助于平台提供的信息确认告警引发的根本原因，甚至通过平台在定位、解决告警问题的过程中还产生了一些障碍。
我对这个事情的解读是，这个小功能分享回看的背后是大boss想传达对测试更多的期望，这期望是什么呢？我们从一个产品的大概诞生周期说起。
孕育一款产品的过程中，主要有这么几环：概念产品、产品设计、需求理解、需求实现、测试、产品交付，每一个环节核心负责的职能人会有所不同。
概念产品，做概念产品的人，可能需要对整个行业，市场容量，市场需求有比较好的认知和把握，基本就是老板、总监级别的人；
产品设计，在一般的中小公司基本就是产品经理+项目负责人，而一个大产品的拆分功能会下放到能力经验再低一层的产品设计普通员工
需求理解，就我经历的公司而言实际的落地就是开发和测试从产品相关人员那里同步对需求的理解
需求实现主要是开发人员
测试和产品交付先略过，对测试起点的思考相关性不大
3权分立大到宏观的国家层面，小到财务方面有会计就要有审计等，我觉得这种思想其实适用范围非常广，因为它背后考虑到了最本质的人性。在一个产品孕育的周期里依然可以找到它的影子。
狭义的测试，也是实际大部分测试的日常其实是，需求理解、需求实现的测试，这样在开发这一环引入了相应的独立的审计。但是概念产品和产品设计却在很多实际的产品生命周期中缺失监管。而分享告警功能，其实是leader希望在产品设计这一环开始，尝试加入测试监管。
为什么不是从概念产品开始？就我们公司而言，新出一款产品的周期比较长。当然也许领导并没有想的那么透彻，或者是概念产品其实设计者主要是他自己，也或者是觉得以测试的见识和能力去测试一个概念产品很难产生收益。但是我相信肯定有设计一个概念产品相应的思考框架，测试并不需要去创新、构思一个产品，只是去反诘这个产品存在的合理性，这是有可能做到的。
至于怎么做产品设计的测试，测试的思考框架应该仍然是适用的，这个我并没有实践过，不去纸上谈兵。
所以测试的实际起点是什么，在受leader对测试的认知和认可程度影响，但是作为一个测试人，预知不同的起点，储备相应的知识，尝试前移测试的起点会带给我们不同的视角和提升，也会对公司产生更好的收益