テストの秘孔

ソフトウェアのテストって、その気になれば、いくらでも工数をかけることが出来る。


例えば、スマートフォンのアプリで、10項目しか無いテストケースが合ったとしても、その気になれば

  • iOS,Androidともに直近の3バージョンで場合分け
  • 各OSともキャリアによって場合分け
  • メーカによって場合分け(仮に5メーカとする)
  • 電波の強弱によって場合分け

と言った具合に、ぱっと思いつく限りでも、上記のパターンで分類することができ、たったの10項目のテストケースが、10x6x3x5x3x2と5400のケースになってしまうわけです。


そのため、テストは「やるべきこと(=バグが流失した時のリスクがでかい機能のテスト)」と「やったほうが良いこと(=今まで問題がなかったけど、バグるとちょっとまずい。or バグると少しリスクがある機能のテスト)」に分けることが出来ると僕は考えています。「やるべきこと」は、必ずやるとして、「やったほうが良いこと」をどれだけ効率よく効果的にカバーするのかというのが、テスト組織にとっての、常に考えなければいけない課題だし、そして、それが出来る人が、良いテスト技術者だと思うのです。


僕が見てきたテスト組織の中には、「やったほうが良いこと」が多すぎて、テスト実施者が疲弊してしまっていることも、よくありました。いたずらにテストの項目を増やし、しかし人員は増えることなく、結局今いるスタッフがひたすら残業して項目を消化していく状況です。

もし、テスト組織が残業ありきになっているとしたら、その組織は、テスト項目の重み付けが出来ていないわけで、すなわち、テストやテスト対象に対する「ノウハウ」や「知識」が存在していない状況になっていると思います(良いテスト技術者が存在していないとこうなる)。
「それは、本当に、限られたリソースを使ってやるべきことなのか?」というのは、常に自問するべきだし、仮にやらなければいけないことだったとしても、それは本当に自分たちがやるべきなのか、他の誰か(たとえば開発者やデザイナや企画者が責任を持つべき部分というのもある)がやるべきなのか、外部のベンダーにアウトソーシングするほうが良いのか、などなど、テストをする内容によって、最適な手段は変わると思うのです。


テストを実施するときは、つねに、そのソフトウェアサービスにとって、どこが秘孔となるのかを見極める努力が必要だと思うのでした。