和一個開發的朋友聊過一個問題：
我們需要專職的QA嗎？
引發討論的是這篇文章：http://coolshell.cn/articles/6994.html
這里的“QA”指“Quality Assurance”，質量管理。放在互聯網行業，也就是通常意義上的“測試”。
這篇文章的具體在這里不做展開。值得思考的是，當我們在質疑是否需要專職測試的時候，其實是相當直白地表達：
專職的測試并不總能發現問題。
那么，測試真的并不總能發現問題嗎？如果真是這樣的話，為什么會出現這樣的局面？
剛好我們最近上線了新的后臺產品，就遇到了類似的情況。
本來，我們公司有多條產品線，包括web端和不同類型的APP，用戶只要注冊了其中任意一個產品，都會成為整個公司體系的會員，生成一個通用的ID。當然，用戶自己未必知道。
在這個前提下，有一些有意思的事情。
我們旗下某個APP的用戶以三四線用戶為主，可能是運營商覆蓋的問題，一些客戶在注冊APP時常常無法收到驗證碼。
我們用一種變通的辦法來解決這個問題：讓用戶訪問官網上，選擇非手機號的通道進行注冊，然后用注冊好的賬號在APP上登錄，從而繞過了手機驗證碼。
可能你已經猜到，在某次功能改版中，官網上非手機注冊的通道被關閉了。
這樣一來，如果客戶無法收到驗證碼，即使他去官網上注冊，依然繞不過驗證碼，這樣一來，驗證碼成了我們流失用戶的一個重要原因之一。
這件事造成的影響比我想象的大，我總結四點：
1、我們平時自己收驗證碼成功率很高，并不表示同樣的事情一定會發生在用戶那里。相反的，收不到驗證碼的情況比我們預計的要多很多。
2、溝通很重要，跨部門的協助溝通尤其重要。如果能提前知曉這樣，把我們的需求反饋給負責改版的部門，就可以避免這樣的情況。
3、盡量避免復雜的互相依賴模式。
舉個栗子，如果B模塊被很多其他模塊依賴，那么一旦出現問題，會引起很多問題。就算是考慮到這一點，改動B模塊時，兼顧了A模塊的需求，仍然可能導致聯動的E模塊產生問題。
4、歸根到底，這還是異常流程的處理。異常流程出現的頻率較低，但并不能忽視。異常流程可以操作復雜、使用成本高，但是一定要能走通流程。
在本例中，如果用戶是強需求，哪怕是給他一個比較麻煩的變通注冊方式，用戶依然愿意操作。
