解决“测试流程”问题的底层逻辑

你好，我是刚哥。
这周技术群有3个讨论激烈的问题，①进到一个完全没有规则流程的新公司，怎么接手安排让自己尽可能舒服点？②需求一个接一个，测都测不过来，哪还有时间写用例？③如果一个需求开发测试1天内进行，你还有其他测试任务，会怎么安排？
这3个问题本质上都是测试流程问题，解决的底层逻辑是建立自己的流程并灵活调整。
我们先来分析下问题的关键点是什么？缺少时间。然后看看是为什么没有时间？第1个问题是因为公司要抢占市场，还没有时间来建设流程。第2个问题是需求任务太多，才没有时间写用例。第3个问题是多个测试任务并行，没时间走测试流程。
部分观点是，在小公司哪管得了那么多，快速交付，抢占市场，能活下来才是最重要的。这个观点没有问题，这是我们无法改变的客观事实，要想推动建设公司流程，很难。但我们希望能找到一种方式，能够让“自己”的工作更顺畅点。
聚焦到自己的工作，建立自己的流程，形成闭环。测试流程最核心的4个节点是用例设计、测试执行、缺陷管理、测试报告。按照这4个核心节点去顺序执行测试流程。一定要顺序执行，并灵活调整形式。
比如说，研发提测了，时间还够就用XMind设计用例，时间不够就用文本写测试点，完全没时间，你自己也要先分析要测哪些内容，怎么测。把用例设计这一步做完以后，再去做测试执行。缺陷管理没有平台就聊天交流，你本地还是要做好记录，有哪些缺陷，哪些解决了，哪些没解决，写清楚。最后测完了要上线了，有时间就写份测试报告发个邮件，没时间也要评估上线风险，定测试结论，同步遗留问题。
认知提升以后，针对第2个问题，就不会提出“哪还有时间写用例”这种经典问题了，因为用例设计这一步我是花时间做了的，只是形式可能不同，如果需要某种特定产物，就可以说“我现在只简单列了测试点，还没写成XMind用例”，这是可以理解的。
按照测试流程有序进行工作，有助于构建软件测试知识体系。