ソフトウエアテストをきちんとできないと、バグだらけのシステムになってしまう。ところが世の中には駄目なテストに陥っている現場が少なくない。実務を通じて分かったより良いソフトウエアテストの方法について、テスト専業ベンダーのプロフェッショナルが解説する。
駄目なテストの回避策
目次
-
それを確認するのは単体テスト?結合テスト?混乱しがちなテストレベル
外注先から納品された単体テスト済みモジュールで、結合テストの段階でバグがたくさん発見された。本来、単体テストで摘出すべきバグなのに――。システム開発の現場では、こうした問題がよく起こる。「どこからどこまで何をテストするのかが単体テストか」という認識が、元請け企業と下請け企業の間で異なるのが原因だ。
-
テストケースの記述、システム開発現場でバラバラになる理由
設計者ごとに異なるテストケースを作成していて、記載粒度が異なっていたり、テスト対象機能やテスト条件に抜け漏れがあったりする――。システム開発現場でよくある困った光景だ。
-
後回しにするほど除去できなくなる「仕様バグ」
バグの発見と対応をテスト工程まで後回しにしている現場は少なくない。こんな現場にいるテストエンジニアと開発者は大変な目に遭う。テストとバグ修正を何度も繰り返し、リリース日に間に合わせるために残業続きになったりする。慌ただしさのあまりバグを見逃してしまい、本番リリース後に障害が発生したりもする。
-
トラブルの根はここに!?中身のないマスターテスト計画書
マスターテスト計画書はプロジェクトにおけるテストの根幹となるが、きちんとした検討プロセスを経て作成されている現場は多くない。要員が足りない、時間がないといった様々な理由により、要件定義書やプロジェクト計画書に比べると、十分な配慮のうえで作成されているとはいい難いのが実情だ。
-
テストの進捗が想定よりも遅れる理由
テストの実行は開発工程の後半になるため、スケジュールがひっ迫している場合が多い。進捗管理を丁寧にして先を見通そうとするが、だいたいうまくいかない。人によってテストの実行スピードが大きく異なるのが原因の1つだ。テストの実行を管理する立場になると、常に悩むことになる。
-
ソフト品質を高めるために作ったのに使えない、正しいバグ報告書のまとめ方
一見地味なバグ票は、ソフトウエアの品質を左右するとても重要な存在だ。バグ票の書き方ひとつで、開発担当とテスト担当のコミュニケーションが円滑になり、プロジェクト全体の生産性が向上する。ソフトウエアの品質向上にもつながる。
日経クロステック Special
What's New
経営
- 経営の見える化を目指すマイナビの挑戦
- 「クラウド時代のあるべき運用」を熱く議論
- 大企業にもキントーンの導入が進む理由
- 製造業DX「データドリブン経営成功のシナリオとは」
- NTTドコモ支援の実践型教育プログラム
- ジェイテクトエレクトロニクスのDX事例
- NTTデータに優秀なデジタル人財が集まる理由
- オリックス銀行×富士通時田社長 特別鼎談
- 脱レガシー案件≫SIerに必要な人財像は
- 3段階で考える、DXで企業力を高める方法
- イノベーションの起爆剤
- 大規模プロジェクトでPMが注意すべき点は
- 大阪・名古屋エリアのDXが注目される理由
- 力点は「未来予測」へ:データ利活用の勘所
- 生成AI活用でSAP BTPの価値が進化
- ServiceNowでDXを加速≫方法は
- SAPプロジェクトの全体像をいかに描くか
- DX時代、IT人財/組織の“理想像”は?