介紹
哈布羅夫斯克居民,下午好。 剛才我正在解決一家金融科技公司的 QA 主管職缺的測試任務。 第一個任務是建立一個測試計劃,其中包含用於測試電熱水壺的完整清單和測試案例範例,可以輕鬆解決:
GOST 7400-81。 家用電熱水壺、電茶炊。 規格(修訂號:1-8) GOST IEC 60335-1-2015 家用及類似電器。 安全。 第 1 部分:一般要求
很難想出一個有完整清單的更好的測試計劃。
但第二部分變成了一個問題:“是否存在所有測試人員共有的問題,導致他們無法更有效地工作?”
我首先想到的就是列出我在測試過程中遇到的或多或少值得注意的問題,剔除小問題,然後總結剩下的。 但我很快就意識到,歸納法所回答的問題並不適用於「所有」測試人員,最多只適用於「大多數」測試人員。 因此,我決定從另一個角度來演繹,結果就是這樣。
確定
解決新問題時,我通常做的第一件事就是嘗試理解問題的全部內容,為此,我需要理解提出問題的單字的意思。 需要理解的關鍵字如下:
- 一個問題
- 測試員
- 測試員工作
- 測試儀效率
讓我們轉向維基百科和常識:
這沒有多大意義,事實上,「問題」=「任何需要處理的事情」。
就像「問題」一樣,它沒有什麼意義:是工作的結果。
現金(收入)是再生資源;
能源(生命力)是一種部分可再生資源;
時間是一種固定的、基本上是不可再生的資源;
知識(資訊)是一種可再生資源,它是人力資本的一部分,可以成長,也可以被破壞
我想指出的是,在我們的例子中,效率的定義並不完全正確,因為我們使用的知識越多,效率就越低。 因此,我將效率重新定義為「所取得的成果與所花費的資源之間的比率」。 那麼一切都是正確的:知識在工作中不會被浪費,但它減少了測試人員唯一根本上不可再生的資源——他的時間的成本。
解決方法
因此,我們正在尋找測試人員的全局問題,這些問題會損害他們的工作效率。
測試人員的工作中花費的最重要的資源是他的時間(其餘的可以透過某種方式減少到它),為了讓我們談論正確的效率計算,結果也必須減少到時間。
為此,請考慮一個測試人員透過其工作確保其可行性的系統。 這樣的系統是一個項目,其團隊包括測試人員。 專案生命週期可以粗略地用以下演算法表示:
- 處理需求
- 技術規範的形成
- 設計
- 測試
- 發佈到生產環境
- 支援(轉到第 1 項)
在這種情況下,整個專案可以遞歸地劃分為具有相同生命週期的子專案(功能)。
從專案的角度來看,花費的時間越少,其實施就越有效。
因此,我們從專案的角度來定義測試人員的最大可能效率—這是測試時間為零時專案的狀態。 所有測試人員的共同問題是無法達到這個時間。
這該如何處理呢?
結論非常明顯,並且已經被許多人使用了很長時間:
- 開發和測試應該幾乎同時開始和結束(這通常由部門完成)
QA )。 理想的選擇是,當所有正在開發的功能在準備就緒時已經被自動測試覆蓋時,使用某種類型的回歸(如果可能的話,預先提交)測試CI . - 專案擁有的功能越多(越複雜),就需要花費更多的時間來檢查新功能是否會破壞舊功能。 因此,專案越複雜,就越需要自動化
回歸測試 . - 每當我們錯過生產中的錯誤並且用戶發現它時,我們就必須花費額外的時間從第 1 點(處理需求,在本例中為用戶)開始經歷專案生命週期。 由於錯過錯誤的原因通常是未知的,因此我們只剩下一條優化路徑——用戶發現的每個錯誤都必須包含在回歸測試中,以確保它不會再次出現。
來源: www.habr.com