テスト自動化パターン言語プロジェクト

ヤブ医者とブラックジャック

文脈

[ダッシュボード]により結果も整備されるようになった。 ある日から「ソースコードもテストも修正していないのに、NGになった」「テストされていなかっただけで、デグレは起きていた」と頻繁に報告されるようになった。

問題

テスト自動化の信頼性が低い ( = 「テストのしかけ」の信頼性が低く、テスト結果に間違いがある。または、テスト結果は正しいがデグレード検知に向いたテストになっていない)

フォース

  • テストの結果をもって品質を判断するとした場合、その判断は「テストのしかけ」の品質に依存する。が、「テストのしかけ」の品質を評価することは導入時点では難しい。
  • 人は、判断の際、定性的な報告・事実であるかどうかを確認する必要がある情報よりも、定量的な報告・機械的な情報のほうを信じたくなる。
  • 回帰テストが十分であるかどうかは、テスト自動化とは直接は関係ない。が、自動的なシステムが動き出すと、そのシステムという箱で信じてしまう。

解決

テストのしかけの信頼性が低いことによる損失と、修理する費用とで天秤をかけよう。回帰テストが十分かどうかについて、気になった時点でテスト設計を確認しよう。ただし、そういったことを確認できる人は自動化環境を前提としたプロジェクトでは維持できていないことが多く、その場合かなりの費用を支払うことを覚悟しておきたい。

結果

  • 直した分だけテストの結果を信用できるようになる。(ただし、老化とともに再発するが)
  • 辛抱強く「テストのしかけ」を回収することで、自動化を導入した環境においても人材が成長し、全員がブラックジャックになれるかもしれない。