qileilove

在我們的團隊中，QA角色身兼兩職：測試和過程改進。以往我們對新進來的員工的期望值是先承擔測試任務，在能較好地完成測試任務之后，才考慮讓他參與一些SQA的工作。因此，有些已經進來大半年的同事，感覺對SQA還是沒有什么概念，更沒有機會去實踐。或者有的同事想參與一些SQA的工作，卻感到沒有頭緒，不知如何下手。而實際工作中我發現，QA的能力可以在每日工作中從點滴、從最開始就培養，這個與以往有沒有SQA的知識和經驗沒有關系。因為簡而言之，QA的工作主要圍繞持續改進展開。而無論你是否有經驗，每天的工作中你都在以自己獨特的視角看問題，并可能看到改進的空間。那么，測試人員如何在日常工作中去逐步培養自己的QA能力呢？

1.找到問題

感受到一個問題，有時是出于關懷，你發現有人/自己正因為某件事情而痛苦；有時是出于懷疑，你發現有件事情和你想象/預計的不一樣；還可能是出于直覺。但感受到問題其實并不是一件容易的事情。

如果感受不到問題，我們可以試圖通過多種方法積極尋找。

如果你剛到一個項目組,提不出問題，可以先去聽聽別人（項目組成員、用戶等等）的抱怨，或者想想自己痛苦的地方（比如找不到文檔，系統操作不直觀學習起來困難等等），這些就可能是問題。另外，為了培養自己找問題的習慣，可以給自己一個定量目標，每周去總結一個“疑似問題”。經過實踐，這個帶點自我強迫的方法對于找問題很有幫助。比如，雖然你的測試用例經過了和開發人員的評審，但是測試時你卻發現幾個重要的分支或者邏輯還是在代碼中忘記實現了。除了報告缺陷，是否還有什么有共性的問題存在，并值得改進呢？

如果你在一個項目組大家合作得不錯，似乎沒有什么問題，但一個看 似不錯的結果其實可能隱藏了問題。比如，完成工作，交付高質量的軟件產品可以通過多種渠道實現，而非一定體現了高質量。可能是犧牲了時間進行好幾輪的測試 和修復和全面的回歸測試，又或者某一塊有一個英雄人物能夠以一己之力確保這塊沒有問題。又如，雖然大規模代碼重構的時候，內部測試能找到大部分重要的缺 陷，但是否測試人員心理還是很抗拒和沒底的？雖然這些問題不是單靠測試人員就能改善或者達到，但找到影響質量的問題確實需要測試人員的獨立視角和貢獻。如 果一個測試人員、一個測試團隊能夠跳開測試的圈圈，從更廣闊的角度看到影響質量的其他環節，幫助開發人員克服一些老的制約生產力和質量的毛病或者習慣，從而提高開發團隊的水平，而更高開發水平的開發團隊又對測試團隊會提出更高的要求，那么這樣的良性互動是我們都想看到的。現在被大家所廣泛追捧的敏捷開發就提倡忽略角色的分工，大家一起為質量貢獻自己的一份力量。

前面說的是流程方面的問題，其實即使是被測程序的問題也存在于在整個軟件開發周期。雖然傳統對測試的理解是測試找問題更多集中在執行階段，但借用QA的預防為主的思路，程序的問題也可以通過對需求和設計的評審及時發現和糾正，避免后期更大的浪費。

2.探究問題

感 受到問題之后，需要一種探尋真相的精神去一探究竟。很多人能感受到問題，但是很遺憾地是當有更具體的任務在手頭的時候，往往就忽略了這個問題。或者知道問 題很大，也知道有各種原因的阻礙，因此采取放任自流的態度。這里要介紹一個好的習慣，就是把你當前沒有時間去細想的問題先記錄下來，以后再找機會去跟蹤執行。類似outlook的任務或者一些桌面電子便簽等工具可以幫助你設定任務及提醒執行。除了記錄，還有一個好習慣就是去外部尋找一些同行的交流。如果看到同樣/類似的話題，相信會驅使你有更大的興趣去看自己碰到的問題，也啟發你從不同角度看問題。

QA的工作更多的針對的是有共性的問題，所以對這類問題的探究往往需要多個樣本。換言之，在報告每一個缺陷的時候我們是在做測試，而對測試結果進行總結、歸類、抽象出背后共性的問題則向QA靠近了一步。

3.判斷問題

3.1判斷一個問題是否真的是問題

測 試人員通常看到實際執行結果后就能馬上判斷出其與預期結果之間的差異，從而判斷是否存在問題。但過程改進相關的問題就沒有那么一目了然了。比如，我們收到 一個來自生產環境的缺陷，是因為一個需求變更的影響點大家都沒有想到，直到生產環境暴露出來。開會的時候有人提出我們的開發流程不完善，如果能夠建立起需 求、設計和測試用例的跟蹤矩陣，那么在做影響分析的時候就能順藤摸瓜，避免此類問題了。聽起來不錯，是么？可是，如果我們細想，這種類似問題在生產環境對 用戶的影響大么？可以繞過去么？此類問題出現的次數多么？如果我們建立這個跟蹤矩陣，維護代價有多高？前提還是我們首先要想到所有的內在聯系（而這個本身 就是無法確保的）。兩相權衡，“沒有這個跟蹤矩陣”是我們現在的問題么？

“判斷一個問題是否真的是問題”最好能廣泛聽取不同的意見，并找到根源。

3.2判斷一個問題是否需要被馬上解決

“判斷問題是否需要馬上解決”在某種程度上這有點象測試人員去設定缺陷的優先級。雖然所有被發現的缺陷都被記錄，但是當前版本需要修復的或者可能只是其中一部分，而這一部分中還有需要盡快修復的和可以稍后修復的差別。過程改進的問題也是一樣，有個主次和優先級之分。

4.解決問題

對于確實是問題的，我們應該去積極地尋找解決方案。但是新到一個公司或者項目組，發現了問題之后，不要急著去提出自己的解決方案，而應該先試圖了解它的來龍去脈和曾經進行過的改進嘗試，以及執行中實際的一些阻礙。

解決問題通常牽涉到開發團隊中各個角色，除了明確負責的一方，還要對參與的其他方也進行充分的溝通。

確認開始執行之后，為了確保執行的正確性和力度，一定要跟蹤執行。一個沒有跟蹤執行的方案如同瞎子射箭。這樣的話，無論射多少回，都是沒有目的性和方向性的，也無法在以前的基礎上持續改進的。質量理論中常提到的PDCA循環講的也是這個道理。

在解決問題方面，有很多和測試、質量無關，但和思維、管理類相關的書和文章。例如：《第五項修煉》中就提出對解決問題很有幫助的五大方面：系統思考、自我超越、心智模式、建立共同愿景、團隊學習。《金字塔原理》中提出的界定問題、結構化思考、演繹與歸納等多種模式也能幫助我們剝繭抽絲，抓到問題的本質和可行的方案。

6.QA能力進階

從上面我們看到，QA能力的培養貫穿于每日工作的點滴。其進階可以大致分為以下級別。

(1)發現的問題級別:

       初級:問題已經發生,而且大家都感受到了(項目組中大家都覺得有問題的問題)

       中級:問題已經發生,但只有少量人感受到了(問題已經發生,但是其危害還沒有擴散)

       高級:問題還沒有發生,很多人沒有意識到(一個解決方案在不同的實施環境中會有的問題)

(2)解決問題的能力的級別：

       初級：可以提出方案，但不能提出很合理的、可以實施的方案

       中級：可以提出合理的可以實施的方案，但是實施效果不太好（方案中存在著一些重要的影響執行的因素沒有考慮到）

       高級：可以提出合理的方案，且實施效果好，整個團隊受益