ソフトウェアテストはなぜやる？
ソフトウェアテストはなぜやるのか、”実装しようとしていたもの”が想定通りの挙動をしているか？を判断するために実施しています。
上手くいかないパターン
第三者検証といわれる業種柄、上手くいっていないところに呼び出されることがほとんどで、そのすべてに言えることがなぜやってるか？だと思っています。なので、おおざっぱにお客さんが困るテストパターンを紹介していこうと思います。
- テストに費やす時間を増やしているのに本番環境で発生する不具合が減らない
- テストを魔法の技術か何かと勘違いしている気がする
- テストする人が集まらない
- やっている意味を誰も説明できなくなる＆レベルの合わないテスターをアサインする
- 後半のテストフェーズがスケジュール通りにいかない
- テストの問題？マネージャーはどこに？
なぜうまくいかないかの考察
上記で上げた三つのうまくいかないパターンは共通して目的意識が薄れていることにあると思います。なので、どこに目的意識が無いか考えてみましょう！
- テストに費やす時間を増やしているのに本番環境で発生する不具合が減らない
- テストに費やす時間を増やすということはそれだけリリースを遅らせる、または保証を複雑化させるということになります。ここから発生することは保証精度が下がり、お金がかかるということです。では、なぜ僕が目的が間違いというのかというと、このケースの場合テストを何とかすれば”実装しようとしていたもの”が実現できるでしょうか？というところになります。
- テストする人が集まらない
- 作業とはは複雑で量が多いほど属人化します。属人化が起きると何がまずいか？それは引継ぎや情報伝達が大変になるということです。簡単なことを人に伝えるのと複雑なことを人に伝えることの伝言ゲームの難しさは誰もがわかると思います。（そもそも簡単なものでも失敗すると僕は思いますが！）なぜ人に依存するテストを作ってしまうのか？目的を忘れているのではないだろうか。
- 後半のテストフェーズがスケジュール通りにいかない
- 一番の問題がこれだと思います。プロジェクトやチームの目標としてテストを無事パスして世の中にリリースしてお客さんも自分たちもより良い体験をするために開発をしているはずなのに、目標が”テストを終わらせる”もしくは”リリースはする”に変わってしまい、本来出せるはずの価値が出せなくなってしまっていると思います。
逆にうまくいっている場合
基本的にうまくいってない現場がほとんどでしたが、上手くいっているところも見たことはあります。そちらを紹介します。
- テストが予定通りに完了するしインシデントが発生してもネクストアクションにつなげられて、テストチームメンバが離脱を望まない
- 結論から話すとマネージャーやリーダーと呼ばれる、管理や推進をする人が機能しているところです。目的遂行のための管理や推進をしてさえしてくれればこんなにもうまくいくのかとギャップを感じます。
どうしたら良いかの感想
基本的にトップダウン形式のところをよく見てきたので、そちら寄りの感想となってしまいます。責任者など最終的にどうなっていてほしいかを決める人が見通しをちゃんと通すのが一番の理想だと思います。ただ、計画も立てて推進もして都度確認をしてとなると規模が大きくなればなるほどに一人でやることは困難となります。なので、大規模なウォーターフォール開発は闇が深い気がする…。。