工作笔记：为什么总是在产品上线之后才发现问题

和一个开发的朋友聊过一个问题：

我们需要专职的QA吗？

引发讨论的是这篇文章：http://coolshell.cn/articles/6994.html

这里的“QA”指“Quality Assurance”，质量管理。放在互联网行业，也就是通常意义上的“测试”。

这篇文章的具体在这里不做展开。值得思考的是，当我们在质疑是否需要专职测试的时候，其实是相当直白地表达：

专职的测试并不总能发现问题。

那么，测试真的并不总能发现问题吗？如果真是这样的话，为什么会出现这样的局面？

刚好我们最近上线了新的后台产品，就遇到了类似的情况。

本来，我们公司有多条产品线，包括web端和不同类型的APP，用户只要注册了其中任意一个产品，都会成为整个公司体系的会员，生成一个通用的ID。当然，用户自己未必知道。

在这个前提下，有一些有意思的事情。

我们旗下某个APP的用户以三四线用户为主，可能是运营商覆盖的问题，一些客户在注册APP时常常无法收到验证码。

我们用一种变通的办法来解决这个问题：让用户访问官网上，选择非手机号的通道进行注册，然后用注册好的账号在APP上登录，从而绕过了手机验证码。

可能你已经猜到，在某次功能改版中，官网上非手机注册的通道被关闭了。

这样一来，如果客户无法收到验证码，即使他去官网上注册，依然绕不过验证码，这样一来，验证码成了我们流失用户的一个重要原因之一。

这件事造成的影响比我想象的大，我总结四点：

1、我们平时自己收验证码成功率很高，并不表示同样的事情一定会发生在用户那里。相反的，收不到验证码的情况比我们预计的要多很多。

2、沟通很重要，跨部门的协助沟通尤其重要。如果能提前知晓这样，把我们的需求反馈给负责改版的部门，就可以避免这样的情况。

3、尽量避免复杂的互相依赖模式。

举个栗子，如果B模块被很多其他模块依赖，那么一旦出现问题，会引起很多问题。就算是考虑到这一点，改动B模块时，兼顾了A模块的需求，仍然可能导致联动的E模块产生问题。

4、归根到底，这还是异常流程的处理。异常流程出现的频率较低，但并不能忽视。异常流程可以操作复杂、使用成本高，但是一定要能走通流程。

在本例中，如果用户是强需求，哪怕是给他一个比较麻烦的变通注册方式，用户依然愿意操作。