ソフトウエアテストをきちんとできないと、バグだらけのシステムになってしまう。ところが世の中には駄目なテストに陥っている現場が少なくない。実務を通じて分かったより良いソフトウエアテストの方法について、テスト専業ベンダーのプロフェッショナルが解説する。
連載
駄目なテストの回避策
目次
-
それを確認するのは単体テスト？結合テスト？混乱しがちなテストレベル
外注先から納品された単体テスト済みモジュールで、結合テストの段階でバグがたくさん発見された。本来、単体テストで摘出すべきバグなのに――。システム開発の現場では、こうした問題がよく起こる。「どこからどこまで何をテストするのかが単体テストか」という認識が、元請け企業と下請け企業の間で異なるのが原因だ。
-
テストケースの記述、システム開発現場でバラバラになる理由
設計者ごとに異なるテストケースを作成していて、記載粒度が異なっていたり、テスト対象機能やテスト条件に抜け漏れがあったりする――。システム開発現場でよくある困った光景だ。
-
後回しにするほど除去できなくなる「仕様バグ」
バグの発見と対応をテスト工程まで後回しにしている現場は少なくない。こんな現場にいるテストエンジニアと開発者は大変な目に遭う。テストとバグ修正を何度も繰り返し、リリース日に間に合わせるために残業続きになったりする。慌ただしさのあまりバグを見逃してしまい、本番リリース後に障害が発生したりもする。
-
トラブルの根はここに！？中身のないマスターテスト計画書
マスターテスト計画書はプロジェクトにおけるテストの根幹となるが、きちんとした検討プロセスを経て作成されている現場は多くない。要員が足りない、時間がないといった様々な理由により、要件定義書やプロジェクト計画書に比べると、十分な配慮のうえで作成されているとはいい難いのが実情だ。
-
テストの進捗が想定よりも遅れる理由
テストの実行は開発工程の後半になるため、スケジュールがひっ迫している場合が多い。進捗管理を丁寧にして先を見通そうとするが、だいたいうまくいかない。人によってテストの実行スピードが大きく異なるのが原因の1つだ。テストの実行を管理する立場になると、常に悩むことになる。
-
ソフト品質を高めるために作ったのに使えない、正しいバグ報告書のまとめ方
一見地味なバグ票は、ソフトウエアの品質を左右するとても重要な存在だ。バグ票の書き方ひとつで、開発担当とテスト担当のコミュニケーションが円滑になり、プロジェクト全体の生産性が向上する。ソフトウエアの品質向上にもつながる。
