1. 要不要寫測試用例？

 　　實際上，我在Thoughtworks的這幾年工作中，幾乎很少使用過測試用例去測試，在手工測試中，大多數(shù)時間都是在做探索性測試。

　　這三年中，也會偶爾會碰到一些特別復雜的流程需要寫一個測試用例做指導，測試過程中雖然依照步驟去測試，但是當我看到系統(tǒng)的反饋有特殊地方后，往往會讓我立刻聯(lián)想到新的測試途徑去嘗試，直到嘗試完了，可能才會返回到剛才的用例步驟中。

　　實際上，IT系統(tǒng)實際上是非常復雜的系統(tǒng)，有很多細節(jié)點需要注意，如果這些點都用文字寫成測試用例，那工作量及其龐大，很難全部寫完。所以對于復雜的業(yè)務場景，我們可以先構(gòu)思一些主流程的測試腳本，然后在每個步驟中，根據(jù)IT系統(tǒng)給你的反饋，去判斷和選擇下一步該如何測試，而不是死死依據(jù)測試用例去測試。如果需要完全依據(jù)測試用例去測試，這時候我們可以讓自動化腳本去做。而QA更應該發(fā)揮人的主觀能動性，根據(jù)系統(tǒng)的不同去做不同的判斷。

　　這里的前提是QA應該對IT系統(tǒng)的各類細節(jié)知識了解的非常豐富。

2. 誰寫自動化腳本？

 　　基本上絕大多數(shù)的自動化測試腳本都是開發(fā)寫的，包括UI自動化測試。有比較高的單元測試覆蓋率，和包含主要業(yè)務流程的UI自動化測試，以及對微服務的集成測試等。如果我在測試中發(fā)現(xiàn)了一個Bug，通常會看是否需要開發(fā)去補充對應的自動化測試。有了高覆蓋率的各種自動化測試，我可以投入更多數(shù)時間去做探索性測試，去發(fā)現(xiàn)那些單元測試、UI自動化測試和集成測試沒有發(fā)現(xiàn)的Bug。

　　有時候我也會去寫UI自動化測試，例如，當程序員開發(fā)一些微服務時，為了隔離微服務并讓單元測試運行的更快，團隊使用了mock方法，但這種方法會有一些弊端，例如測試多個微服務之間的調(diào)用時，邊界處如果有Bug往往會出現(xiàn)漏測，因此我補充寫了一些E2E腳本跨多個服務之間，去測試完整的流程，避免漏測的現(xiàn)象。

3. 當開發(fā)說這不是個bug怎么處理?

 　　首先我會去分析開發(fā)人員認為個bug不用修復的原因是什么，可能會是以下這幾種之一：

　　A. 界面和UI設計稿不同，或者大部分地方和設計稿相同，有些細節(jié)地方不同。這種情況下，一幫我們會認為UI的審美意識更好一些，如果開發(fā)仍然不愿意修復，那最好引入UI設計人員一起討論。通常討論后，UI認為有些細小bug不影響整體風格的可能就不需要修復了，另外一部分對用戶體驗會造成影響，是需要修復的?！　?/span>

　　B. Bug只出現(xiàn)在特定瀏覽器上，例如bug只出現(xiàn)在IE10或者手機瀏覽器chrome28上。這時候，我會根據(jù)統(tǒng)計真實用戶行為的軟件，例如Adobe 的Omniture分析結(jié)果，去確定現(xiàn)在需要支持的瀏覽器類型。通常，一個產(chǎn)品有大量的用戶，需要支持的瀏覽器類型就比較多，但是由于開發(fā)人員有限，往往優(yōu)先支持Top10的瀏覽器類型。如果IE10或者chrome28還在Top10，那就以此和開發(fā)人員溝通說bug需要修復。如果不在Top10的瀏覽器列表，那就不用修復。有些特定Bug可能還會引入PM，BA等人一起確定是否需要在特定瀏覽器上修復。

　　C.有的Bug是易用性問題。開發(fā)人員作為技術(shù)工作者，熟悉電腦和各種快捷鍵等，因此可能使用起來覺得沒問題，但產(chǎn)品的真實用戶中各種類型人都有，例如有年紀大對IT不熟悉的，甚至有色盲、或者其他障礙的，那么從這些用戶的角度去說服Dev這個bug是否需要修復。

 　　D. 有些Bug修復的effect過大，開發(fā)說不值得去修復。這類通常也要和PM， tech lead，BA一起討論一下?？赡艹霈F(xiàn)三種情況：

　　　　情況1. 如果這個bug的投入產(chǎn)出比大家都認為不合適，而且影響比較小，可能就不修了，但是最好有個文檔去記錄已知的不需要修復的bug。

　　　　情況2. 第二種是大家覺得需要修復，但是因為工作量太大，現(xiàn)在沒有時間修復，那么建卡，放在Jira的backlog里，等團隊有時間了，由PM決定什么時候開始做這個卡。

　　　　情況3. 第三種是大家覺得雖然工作量大，但是因為對用戶影響較大，現(xiàn)在就修復。那么需要現(xiàn)在建卡，并安排高優(yōu)先級立刻著手修復。

 　　最后，如果當QA和開發(fā)有分歧的時候，可以適當?shù)囊?span id="opkdopnojk" class="s1">PM，BA，Teach lead，UX等來共同做一個決策。

4. QA的日常工作是否包含大量文檔、產(chǎn)品部署的雜事？

　　沒有。我們產(chǎn)品部署到無論是測試環(huán)境、類產(chǎn)品環(huán)境還是產(chǎn)品環(huán)境，都是全自動化部署的。所以每當開發(fā)提交代碼后，會自動部署到測試環(huán)境中。這里不需要QA手工參與，節(jié)省了很多時間。

　　由于不需要寫測試用例，也節(jié)省很不少時間。有些公司要寫測試日報或者每周測試報告，這里都不需要。也不用寫性能測試報告，我把性能測試結(jié)果記錄在Jira卡中，和團隊分享就可以了。我記得今年就寫過幾個概要的產(chǎn)品測試策略文檔，以及十多篇測試經(jīng)驗分享的Blog。此外，其他文檔寫的很少。