Risk and RBT(風險及基於需求的測試)

 I think we need to break out of the mythology that testing is some kind of robotic process.
我想我們需要粉碎這種測試觀點:測試是一種機械的過程.
 
需求開發不是在項目啓動時一次搞定的。實際上，需求是貫穿在項目生命週期中的兩方談判。一方在問：我們需要什麼？而另一方則在問：我們能構建什麼？
 
這兩方對話的質量幫助決定產品的最終質量。
 
我把需求理解成衆多想法的集合，它們共同爲特定產品定義質量。我把測試定義成開發一套評估系統的過程，用於對產品質量進行評估。
 
RISK AND REQUIREMENTS TESTING 風險與需求測試
至少有四種關於需求與測試的腐朽觀點：
1.除非有穩定的需求，否則測試不可能進行。
2.一個軟件產品必須滿足它的特定的需求。
3.所有測試用例必須可追蹤到一個或多個特定的需求項，反之亦然。
4.需求必須以可測的方式描述。
 
然而，當我們考慮到風險，我相信有更豐富的概念出現。
 
Testing without stated requirements 沒有特定需求下的測試
滿足需求是非常重要的，測試員的工作之一就是確認產品滿足需求，所以明顯測試人員需要清楚需求。所以上面說的不無道理，並且在大部分情況下是對的。
 
但是，由於不完整性和不清晰性，測試不能僅僅認爲是一個確認過程。測試同時還是探索需求和實現的過程。因此，測試不僅可以沒有特定需求，而且在需求不確定的情況下特別有用。我想我們需要粉碎這種測試觀點:測試是一種機械的過程.通過測試和開發的合作會產生巨大的價值。有經驗的測試員通過他們對未定需求的理解評價產品，並且通過觀察來挑戰或提問項目成員對質量的共同理解。
 
一個好的測試員會對特定需求的差距始終保持警惕，並且解決這些差距到一定的程度：滿足特定情況下的風險。
 
Satisfying stated requirements 滿足特定需求
如果每一個特定的需求項都是產品的真實聲明，然後我們把產品質量定義爲這一前提的延伸。那麼軟件產品必須滿足它的特定需求這一觀點是成立的。但是那有賴於我們有非常清晰和完整的需求集合。否則，你將被鎖定在一個很窄的質量範圍內。
 
關於滿足需求的更廣泛的思考範圍是把我們的思維轉變到考慮不滿足特定需求的風險。好的測試員會努力地回答這個問題：什麼是這個產品的重要問題？
 
Tracing test cases to requirements 把測試用例跟蹤到需求
需求如果要發揮作用，則測試與需求之間應該有所關聯。談到可追蹤性，通常摘要爲：
爲每個需求項ID，列舉關聯的測試用例的ID；爲每個測試ID，列舉關聯的需求ID。
測試的完整性被大概地通過“對於每個需求項，至少有一個測試關聯”來估計。這是一個很理想的觀點。
如果可追蹤性的目的是用於證明測試策略已經驗證了產品的需求，那麼我們應該進一步。我們應該隨時準備回答客戶的問題。“你怎麼知道它證明了？”我們應該能解釋我們的測試與需求之間的關係。重要的是需求和測試是如何關聯的，並且隨着產品風險越高越重要。
 
Stating requirements in testable terms 在可測性方面衡量需求
需求有意義是非常重要的。然而，“可測性”通常定義爲“有利於完全可靠，一致性和可觀測性的度量，從而決定是否順從需求”。這個觀點強調除非我們能夠度量是否成功，否則我們永遠不能知道我們是否完成測試。
 
首先我們應該重新認識一下測試員，他們不是懶漢，他們擁有普通人的洞察能力和推理能力。一個典型的測試員應該能夠探索需求的含義和潛在意義，而不一定需要這些信息，就像一個瀕臨絕種的小禿鷹被滴入眼藥水一樣。事實上，嘗試通過簡化需求說明從而達到可測試程度，進而減少測試人員的麻煩，這種做法有可能造成更大的麻煩。
 
看一下一個真實的例子：顯示控制器應該在300毫秒內響應用戶的輸入。
當一名測試員看到這個需求的時候，他以爲要買一臺特定的儀器來測量產品的毫秒級性能。後來他意識到：一個正常人能辨別正負50毫秒的分辨率，也許這已經足夠精確了。再後來他意識到：也許這個需求項指定到毫秒級不是爲了使需求更有意義，而是爲了使需求更具衡量性。當他問到設計者時，發現真正的需求是：響應時間“在這個版本的產品中不要慢得煩人”。
 
因此我們看到實際的測試不一定需要精確的需求說明，測試是通過有效的和有意義的溝通進行的。
 
REQUIREMENTS, TESTING,AND CHALLENGING SOFTWARE 需求，測試與挑戰軟件
1.我們認識產品的問題的能力是受限於我們對問題可能產生的地方的理解。需求規格說明書是一個問題信息的潛在來源。
 
2.我們招致風險取決於發佈產品中包含的重要問題的程度和範圍。測試的真正任務是把這些風險暴露出來。而不僅僅是展現特定需求的不一致性。
 
3.特別是在高風險的情況下，如果我們能證明測試策略與定義的質量之間的關聯，測試過程應該會更具說服力。這超出了至少一個測試對應一個需求項的範疇。
 
4.如果需求說明更多地關注什麼纔是關鍵的要求，關注風險、益處和每個需求項的重要程度，則測試過程會更有效。目標可度量性在某些情況下是需要的，但是它不足以產生健壯的測試。
 
如果把這些規則應用到高風險或複雜的軟件會發生什麼事情呢？
隨着風險和複雜度的增加，如果測試過程要想完成任務，測試參與到需求的對話中就顯得尤爲重要了。需要更多的測試技巧，作爲與開發更好的配合，與用戶更好的溝通。在這個關於我們要什麼的對話中，測試員應該尋找溝通的更多渠道：更多文檔的原材料，圖表，演示，談話和用例。在關於我們能構建什麼的對話中，測試員應該熟悉採用了什麼技術，並且與開發人員一起爲產品構建可增強可測試性的特性。
 
在整個過程中，測試員應該注意項目的風險和複雜性是否超過了測試的能力。
 

本文並不是要改變關於需求必須清晰準確的指導方針。本文強調管理風險和關於項目的質量共識之間的關係重要性。