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