一個質量cmmi0級的產品。從face到hold

爲啥寫這個呢。我也不知道。17年的發的牢騷。大家全當一樂哈。思維太幼稚，畢竟那時候作者圖樣圖森破
一個產品，對於測試來說。最糟糕的情況是什麼？是線上每天各種bug反饋不斷，這時如果在加上沒有專業客服 讓你立即清楚的知道反饋的具體問題描述。再加上一個不通明的領導，只知道線上有bug，就拿測試問罪的這樣子。即使你在是測試明星，即使你技術再高，即使你思緒再廣，處於這種環境下，怕是連最起碼的忠心都會喪失掉，更何談努力改變局面，能做的只能是請假-面試-跳槽。
線上bug爲什麼多？明明測試服已經完全ok了。所以這也是很多測試堅決不碰，不管，不負責線上的原因。因爲線上髒數據真的是讓人頭疼。如果此時 髒數據和超級不穩定的後臺接口配合起來，再加上喜歡直接動線上數據庫的領導的話。恐怕就算大羅神仙級的測試在，也只能say goodbye，順便再加上瘋狂更新迭代，既要速度又要質量又不給你增派人手，出了bug就是你背鍋。。。下面就簡單說說這幾種讓人抓狂的情況。之後再來分析如何把控，處理。也歡迎小夥伴們提出寶貴點子。（可能很多同學看到這就喊：不可能有這種公司存在吧，開玩笑麼？ 但是我告訴你，真的就有，而且很多，在一些中小型公司非常常見。）
1。髒數據問題
髒數據的特點是：難處理，隱蔽性高，危害可大可小，出現時機隨機，出現概率無法估測，品種繁多導致無法一招解決。
髒數據的產生有：版本迭代的時候沒有考慮到舊用戶數據庫表的兼容；線上數據庫直接操作；線上bug引起；弱網等極限環境產生；異常操作產生；多種特殊身份/違法/臨時身份引起； 等等。。。。
髒數據的意義：使測試成果無效化；屬於產品癌症，基本無法有萬能的藥物可以治療；最土的辦法是把所有用戶一個一個跑腳本過一遍，但這是不可能的。一旦出現，除非刮骨療毒，否則遲早是大患。；好的辦法，是花大量時間人力物力。把所有數據都在數據庫層面檢查，補全，矯正。
ps:如果髒數據的品種過多，版本過多，有多少批，有多少種，每種有多少個 都無法確定的話。這個簡直就是災難。以個人的力量是無法根治的，如果線上髒數據問題也要你背鍋的話，那趁早離開把。
2。後臺接口
後臺是一個產品的重中之重，也是根基所在。試想如果一個根莖薄弱的小樹，可能長成參天大樹麼？或者本來大樹已成。突然砍掉大部分樹根，這個樹還能正常成活麼？
很多小公司目前的最噁心的情況就是：後臺人員數量質量過少。後臺人員是無界面的英雄，操作這個複雜的linux，對着的永遠是各種代碼和數據，當公司其他同事，老闆，用戶看到產品出來後，都會去表揚前端開發，而忽略後臺的功勞。因爲大家看得見的只有界面而已，那廣闊的數據，無數的接口，噁心死人的各種複雜邏輯和算法 大家永遠看不到。這種吐槽不是我一個測試該吐的，但確確實實是我曾經的後臺技術部老大的吐槽。這種風氣，直接就導致了對後臺的不重視。前端經過測試之後，基本可以很穩定了。但是接口呢，一個即時變動的過程，前一秒ok,下一秒掛了。這種程序生命本身就決定了測試在某個時間點的測試，其實作用並沒有測試前端界面大，更無法保證下一秒的成功。面對測試這種根基不穩的軟件工作，真的是很累，很累。
如果這時候再加上髒數據問題，那麼好，線上出來個用戶反饋bug，我們甚至不知道是髒數據問題導致還是接口恰好那麼一會功夫掛了，更何談複線和修復了。
3。直接動線上數據庫
這個沒什麼好說的，本身就是違法行爲。違反行業準則行爲，違反一切流程行爲，違反社會主義初級階段的行爲。倆個字：拜拜。
4。質量or速度
這是一個歷史性疑難問題，到現在也沒有明確的答案，要速度沒質量，要質量沒速度。這永遠是兩極！ 華麗的語言總會說：我們既要質量又要速度，在我看來，就和又要馬兒跑 又要馬兒不喫草一樣可笑。如果嚴肅來說，速度和質量 是相對的。是速度快，是質量好，都是相對比較的。可能你質量是1，速度是1。然後通過招人，技術提升，流程提升，變成了質量是2，速度是2。然後就可以大喊我們既有速度又有質量？ 那麼這句話就是偷換對比對象而已。因爲這時候，你完全可以質量3 速度1 或者 質量1，速度3了。如果和這兩種情況對比，你現在的質量2 速度2，還能說是既有速度又有質量麼？是不是也可以說即沒速度又沒質量？
好了扯太遠了，不在文字上做文章了。迴歸主題，到底是速度還是質量。領導們一邊對你說：你是測試負責人，你要把關好質量，質量不行，堅決不允許上線。
這時你怎麼懟回去？因爲這裏所有的界限都是模糊的，領導怎麼說怎麼是，所以你根本就懟不回去。一旦提前上線了，到時候出現一點小問題，還是你背鍋而已。
把控把控，問題就在於這個尺度上，質量標準到底要定位在哪個水平線？相信不同的公司，不同的老闆心裏都有一個一直在變化的標準。你把控的不符合這個，就等着背鍋把。