こんにちは、システムチームのKです。
先月は「テスト」についてブログを書きました。
https://syde.jp/w/archives/12620.html
今月は引き続き、「テスト」について、
今起こっている問題を分析して、
解決方法を考えてみようと思います。
テストの流れについて
テストの流れは
計画・概要の作成
↓
環境の用意
↓
テストの種類を設定
↓
テスト手順を作成
↓
テストを実施
↓
検証
ですが、テストミスを起こす人は
次のようになっていると思います。
計画・概要の作成
↓
環境の用意
↓
テストの種類を設定
↓
テスト手順を作成
↓
テストを実施
↓
検証
つまり、
「無計画に、自己流のテストを思いついた順に行っている。」
状態ですね。
これでは、
・不具合の見逃し
・満たしている要件の過不足
などの問題が発生してしまいます。
ではなぜ、「無計画に、自己流のテストを思いついた順に行って」しまうのか
これについて考えてみようと思います。
作るものに対して、適切なテスト時間を設定できていない
第一の問題は
「作るものに対して、適切なテスト時間を設定できていない」
ことです。
つまり開発スケジュール、見積もりから
誤っているということなんですね。
20h ~ 30hかけて作ったもののテストが
0.5h なんてのは明らかに少ないです。
世の中の平均時間を調べてみると、
テストにかける時間は、開発全体の、
38.3% という統計が出ています。
【参考】ソフトウェア開発データ白書P183 図表 7-1-21より
思っていたよりも多いですよね。
上記のデータでは、
実装時間の平均は開発全体にかかる時間の 29.7% なので、
実は実装よりもテストの方が長い
ことがわかります。
タスクにはそれぞれ予算を設定しますが、
実装内容にあったテスト時間を設定しないといけません。
何も考えず、
全タスク同じ時間テストを確保（たとえば各タスク1.5hずつ…）
なんて見積りをすると
失敗します。
テスト方法を決めるタイミングが遅い
第二の問題は
「テスト方法を決めるタイミングが遅い」
ということです。
なんとなくユーザー目線で、
なんとなく目についたところから、
なんとなくの
自己流のテストをするため、
「不具合の見逃し」「満たしている要件の過不足」が発生します。
まずシステムテストの方法は、
ちゃんと種類が定義されています。
・機能テスト
・性能テスト
・負荷テスト
・ロングランテスト
・セキュリティテスト
・ユーザビリティテスト
・回帰テスト
etc…
それぞれの説明は長くなる、解説されているページはいくつもあるので
こちらから
これらの方法から
適切なテストを選択して実施する、というのが定石です。
どのテストが必要かどうかは、
仕様作成段階で決めるべきことです。
実装が済んでから考えているようでは遅いです。
仕様が明確であれば、
どういうテストが必要になるか、
ということも当然明確になります。
もしそれができない状態なら、
そもそも仕様がちゃんと作れていない証拠なので、
仕様の見直しを先にしないといけません。
経験が少ないと、
自分の中の優先順位が
実装＞仕様作成（設計）＞テスト
になりがちですが、
正しくは
仕様作成（設計）≧テスト＞＞＞（超えられない壁）＞＞＞実装
（極端に言えば）これぐらいじゃないかなと、
システムチームに移って1年以上たった今思います。
テストに割く時間の見直しと、テスト方法を決めるタイミング、
この2つを改善すると、
不具合の見逃しや、
仕様の漏れは防げるようになるかなと思います。
