前幾天會上，有人提出在開發完成前，QA這邊沒時間提供用例，這可能會是一個風險。另一個人站出來說，開發完成的時間不應該受QA提供用例時間的制約。
在我看來，這兩者並不衝突，開發人員基於自己的理解做實現，當然不會收到QA提供用例的影響。這裏邊其實有個核心問題，爲什麼QA要在開發完成之前提供用例？
從業務QA的角度來考慮，說白了就要保證提測質量。再往上走一層，其實是要提前暴露質量風險，識別風險也是QA的日常工作之一。
爲什麼QA要在開發完成之前提供用例？
1. 產品、開發、測試三方，需要一個機會再去對齊需求內容、確定最終期望，避免gap。
也許你會說，那就再開會對齊，如果再開會對齊，是以什麼爲基準？這裏有3種可能性：
（1）修訂後的需求文檔
（2）開發的設計文檔
（3）QA的測試用例
一個最基本的理論，問題越早發現，成本越小。
對於消除需求理解的gap，有些公司嘗試做需求反串講，也就是說PM做完需求評審之後，由非PM（QA、RD）基於對需求的理解做需求串講，三方參與，就反串講發現的gap做及時補充與修正。
反串講，可以在開發/設計之前暴露需求問題，成本最小。它也有劣勢，即RD和QA都未開始做設計，細節問題暴露不足，在做設計時，再遇到問題，還是要進行討論和修正。所以在設計後，再進行一輪評審勢在必行。
若以開發的設計文檔作爲基準去評審，在評審過程中，很容易陷入技術的漩渦，越走越深，以技術的設計的角度去解釋需求，會使需求不聚焦，不利於需求的梳理和理解。
熱知識： QA用例來源於兩方=》一個將產品需求拆解，一個是根據開發的設計。
從這三者來看，需求文檔更偏向於用戶角度，開發設計文檔更偏向於技術角度，只有QA的用例，介於兩者之間，可以從用戶角度出發覆蓋技術變更，也可以從設計角度反推用戶的行爲。所以，以QA用例爲基準的對齊會比直接對齊需求文檔或者技術文檔更加全面，更好着手。
用例評審給了第三方一個機會去說明自己對需求和技術的理解，這個環節PM、RD、QA都要參加，三方可共同探討就需求、技術而產生的gap，有利於三方統一對齊，從而減少各方的理解差異。
此時你會說，QA用例評審時，可能開發已經開始了，如果需求有問題，那麼成本會更高。是的，沒錯，如果可以，反串講之後，再做用例評審固然好，一切都不是一成不變的，一定要不斷的迭代。
2. 開發需要在測試開始前保證基本流程走通
開發往往更關注單元測試，但產品是一個整體，從入口到出口，最基本的流程是否能走通？交付給QA之後是否會block？
這裏需要討論：QA如何做質量保障？開發在質量保障中需要做些什麼？
從比較狹隘的觀點出發，QA就是測試，根據產品需求和開發文檔，產出測試用例，提測之後執行測試，測試用例全部通過後，上線，再做線上測試。
大多數時候，QA確實在做這些事。但是QA能做的和要做的不僅如此。
QA要從全流程，每個環節去發現質量風險，提出質量風險，進而推動各環節人員、流程、測試方法等做改進，最終確保項目保質保量的交付以及產品整體的可靠。覺醒的前輩們也提出了測試左移與測試右移。這些high level的觀點，需要不斷的輸出，才能對QA形成有益的循環，希望你的leader們可以經常輸出 What is QA doing? Why we do that? 我相信你的日子會更加好過。
從全流程角度保證質量，要比單純的把質量風險集中在測試周期內更加可靠、高效。調動全員參與質量保證也是QA人員工作的一部分，使每個人都能對質量負責。
所以開發該不該在開發週期內，保證主流程走通？
當然了！首先，他分散了風險。其次，單元測試、開發做簡單的集成測試也是質量保證的一個環節。再者，做產品需求，開發需要對產品有一個整體的概念，執行一些P0級別的case，有益於理解產品需求。
但我相信，就算再花言巧語，其他人也不會全部認可。
這時候有些RD會說，沒有時間！那麼QA在確定排期時，需要提出增加這部分自測的時間。如果大家都擠不出時間，那顯而易見，這次交付的質量風險會比較高，QA需要提前周知到質量風險。
還有人說，我們又不是QA，不是專業的測試，執行case幹嘛？測試是你們的事情。看到了麼，普及質量保障意識是多麼重要的一件事，但我真的無法保證用什麼方法論或者說什麼話做什麼事，可以輕而易舉的使對方認同你，對於不同的人，我們要做不同的事，用不同的方法，想扭轉一個人的觀點很難。有些人的觀點裏，開發就是要做開發，最多做個單元測試。但是QA可以從很多角度去影響他們，比如新人培訓時，增設質量保障相關課程，在開發一入職就培養質量思維；比如瞭解開發leader們的想法，看看他們對此的態度，再決定下一步你該做什麼；比如定期向外界輸出 What are we doing? How can we test best?；比如瞭解別人的困難，適時提供幫助，不要讓人以爲你總是找麻煩的那個；比如找一些容易的切入點，以點帶面，讓大家看到全員質量保障的優勢；比如做一些數據統計，以實際數據支持理論開展；比如硬性的定一些規則，必須執行，等等等等，做你能想到的任何事。
還有一部分開發質量意識極棒，做爲QA你可能又感到壓力，如果每個開發都具有非常好的質量意識，代碼質量極高，QA又能夠多做哪些事呢？說到這，我們又聊到了職業自信，哈哈，QA大概是最不自信的那一類人，有兩種說法，角度不同，其實是一個意思，我們比開發更懂產品、比產品更懂開發；我們沒有開發技術好，也沒有產品的產品思維那麼敏銳。一種是積極向，一種是消極向。講真，我一直是消極向。但是不可避免的，我們要在職業發展中找到自己的優勢所在，比如在同工種中，你的優勢是什麼？比如在不同工種間你的優勢是什麼？以後單開一個小作文，聊一聊職業優勢吧。
假如質量引導做的不好，並且流程還沒建立起來，如果有人challenge說，我們不要做冒煙測試，不要執行用例，希望大家不要生氣，也不要撕x，強勢的推廣只存在於開發領導們的大力支持下，有時候我們需要一些縱容，並記錄這個過程中的艱辛，最後形成總結報告，提交給項目經理或開發經理，通過真實的數據共同探討下一步我們如何優化流程。一次兩次，不斷的總結，不斷地探討，堅定不移我們的決心，相信最終會影響到其他人。萬事開頭難，做QA更難。
還有一個點需要討論：什麼時間提供測試用例最好？
在我看來，一定是詳細的需求評審結束，開發的技術評審結束，QA就可以開始着手設計測試用例，完成之後立即做用例評審。
其實大部分互聯網公司也都是這麼做的，還有些公司技術設計評審做的不夠好，這點也許會需要一些時間去溝通。
爲什麼說這個時間最好呢？這個時間相當於開發纔剛剛着手開始，改動成本相對不高，在用例評審時發現的問題，比如需求不合理，需求遺漏，設計不合理等都可以迅速的改正。越到項目的後期，修復的成本越高。
題外話
做了很久測試之後，發現很多時候，觀點的對齊花費的時間、精力要比執行起來難得多，當大家各執一詞，你如何說服對方？對方有很多，比如你的其他QA同事，與你合作的RD、PM，你思維內覺得一定要這樣做的事，並非所有人都會同意，在推廣一個流程或者工具之前，你準備好會遇到的各種難題了麼？有獲取到老大們的支持麼？是否有提前調研到QA和RD同事的接受度？
講一個在某公司（大廠）的真實故事，longlongago，some QA定了一個rule，冒煙用例不超過3條，後面我們有機會一起討論一下，那些年你遇到過的奇葩規則以及如何去打破這些規則。
測試發展至今，大家都在談自動化，每個QA似乎都要寫的一手好代碼，RD也不再向早前幾年，覺得QA只會點點點。業務QA的日子越來越好過了。測試工具開發也逐漸向成熟的方向發展。當前有些公司將測試工具開發與業務QA徹底分開，業務QA不再需要承擔工具開發的任務，只需要專注於業務測試，深入業務，挖掘業務的質量風險，從全流程做質量保障。需要工具給工具開發提需求，工具開發做純開發任務以及給業務QA提供技術支持，做提效工具，以及從技術角度做質量監控與風險暴露。下一回，想和大家談一談職業發展。
雖然遺留了許多工具建設的坑，但我想認清前面的路更重要，認識自己，找準自己的路。
歡迎留言～