測試的基本問題

介紹

哈布羅夫斯克居民,下午好。 剛才我正在解決一家金融科技公司的 QA 主管職缺的測試任務。 第一個任務是建立一個測試計劃,其中包含用於測試電熱水壺的完整清單和測試案例範例,可以輕鬆解決:

但第二部分變成了一個問題:“是否存在所有測試人員共有的問題,導致他們無法更有效地工作?”

我首先想到的就是列出我在測試過程中遇到的或多或少值得注意的問題,剔除小問題,然後總結剩下的。 但我很快就意識到,歸納法所回答的問題並不適用於「所有」測試人員,最多只適用於「大多數」測試人員。 因此,我決定從另一個角度來演繹,結果就是這樣。

確定

解決新問題時,我通常做的第一件事就是嘗試理解問題的全部內容,為此,我需要理解提出問題的單字的意思。 需要理解的關鍵字如下:

  • 一個問題
  • 測試員
  • 測試員工作
  • 測試儀效率

讓我們轉向維基百科和常識:
問題 (古希臘文 πρόβλημα)廣義上 - 需要研究解決的複雜理論或實務問題; 在科學中-在解釋任何現象、物體、過程時以對立立場的形式出現的矛盾情況,需要適當的理論來解決; 在生活中,問題以人們可以理解的形式表達:“我知道什麼,我不知道如何”,即知道需要獲得什麼,但不知道如何做。 來自較晚。 緯度問題,源自希臘文。 πρόβλημα「向前拋出,置於前面」; 源自 προβάλλω 「向前扔,放在你面前; 責備」。

這沒有多大意義,事實上,「問題」=「任何需要處理的事情」。
測試員 - 參與測試組件或系統的專家(我們不會劃分類型,因為我們對所有測試人員都感興趣),其結果是:
測試員的工作 — 一組與測驗相關的活動。
效率 (lat.effectivus) - 所獲得的結果與所使用的資源之間的關係(品質政策 ISO 9000:2015)。
結果 - 一系列(系列)行動(結果)或事件的結果,以定性或定量的方式表達。 可能的結果包括優勢、劣勢、增益、損失、價值和勝利。
就像「問題」一樣,它沒有什麼意義:是工作的結果。
資源 - 一個人或一群人進行任何活動的可定量測量的可能性; 使使用某些變換獲得所需結果成為可能的條件。 測試者是一個人,根據重要資源理論,每個人都是四項經濟資產的所有者:
現金(收入)是再生資源;
能源(生命力)是一種部分可再生資源;
時間是一種固定的、基本上是不可再生的資源;
知識(資訊)是一種可再生資源,它是人力資本的一部分,可以成長,也可以被破壞[1].

我想指出的是,在我們的例子中,效率的定義並不完全正確,因為我們使用的知識越多,效率就越低。 因此,我將效率重新定義為「所取得的成果與所花費的資源之間的比率」。 那麼一切都是正確的:知識在工作中不會被浪費,但它減少了測試人員唯一根本上不可再生的資源——他的時間的成本。

解決方法

因此,我們正在尋找測試人員的全局問題,這些問題會損害他們的工作效率。
測試人員的工作中花費的最重要的資源是他的時間(其餘的可以透過某種方式減少到它),為了讓我們談論正確的效率計算,結果也必須減少到時間。
為此,請考慮一個測試人員透過其工作確保其可行性的系統。 這樣的系統是一個項目,其團隊包括測試人員。 專案生命週期可以粗略地用以下演算法表示:

  1. 處理需求
  2. 技術規範的形成
  3. 設計
  4. 測試
  5. 發佈到生產環境
  6. 支援(轉到第 1 項)

在這種情況下,整個專案可以遞歸地劃分為具有相同生命週期的子專案(功能)。
從專案的角度來看,花費的時間越少,其實施就越有效。
因此,我們從專案的角度來定義測試人員的最大可能效率—這是測試時間為零時專案的狀態。 所有測試人員的共同問題是無法達到這個時間。

這該如何處理呢?

結論非常明顯,並且已經被許多人使用了很長時間:

  1. 開發和測試應該幾乎同時開始和結束(這通常由部門完成) QA)。 理想的選擇是,當所有正在開發的功能在準備就緒時已經被自動測試覆蓋時,使用某種類型的回歸(如果可能的話,預先提交)測試 CI.
  2. 專案擁有的功能越多(越複雜),就需要花費更多的時間來檢查新功能是否會破壞舊功能。 因此,專案越複雜,就越需要自動化 回歸測試.
  3. 每當我們錯過生產中的錯誤並且用戶發現它時,我們就必須花費額外的時間從第 1 點(處理需求,在本例中為用戶)開始經歷專案生命週期。 由於錯過錯誤的原因通常是未知的,因此我們只剩下一條優化路徑——用戶發現的每個錯誤都必須包含在回歸測試中,以確保它不會再次出現。

來源: www.habr.com

添加評論