ソフトウエアテストをきちんとできないと、バグだらけのシステムになってしまう。ところが世の中には駄目なテストに陥っている現場が少なくない。実務を通じて分かったより良いソフトウエアテストの方法について、テスト専業ベンダーのプロフェッショナルが解説する。

駄目なテストの回避策
目次
-
それを確認するのは単体テスト?結合テスト?混乱しがちなテストレベル
外注先から納品された単体テスト済みモジュールで、結合テストの段階でバグがたくさん発見された。本来、単体テストで摘出すべきバグなのに――。システム開発の現場では、こうした問題がよく起こる。「どこからどこまで何をテストするのかが単体テストか」という認識が、元請け企業と下請け企業の間で異なるのが原因だ。
-
テストケースの記述、システム開発現場でバラバラになる理由
設計者ごとに異なるテストケースを作成していて、記載粒度が異なっていたり、テスト対象機能やテスト条件に抜け漏れがあったりする――。システム開発現場でよくある困った光景だ。
-
後回しにするほど除去できなくなる「仕様バグ」
バグの発見と対応をテスト工程まで後回しにしている現場は少なくない。こんな現場にいるテストエンジニアと開発者は大変な目に遭う。テストとバグ修正を何度も繰り返し、リリース日に間に合わせるために残業続きになったりする。慌ただしさのあまりバグを見逃してしまい、本番リリース後に障害が発生したりもする。
-
トラブルの根はここに!?中身のないマスターテスト計画書
マスターテスト計画書はプロジェクトにおけるテストの根幹となるが、きちんとした検討プロセスを経て作成されている現場は多くない。要員が足りない、時間がないといった様々な理由により、要件定義書やプロジェクト計画書に比べると、十分な配慮のうえで作成されているとはいい難いのが実情だ。
-
テストの進捗が想定よりも遅れる理由
テストの実行は開発工程の後半になるため、スケジュールがひっ迫している場合が多い。進捗管理を丁寧にして先を見通そうとするが、だいたいうまくいかない。人によってテストの実行スピードが大きく異なるのが原因の1つだ。テストの実行を管理する立場になると、常に悩むことになる。
-
ソフト品質を高めるために作ったのに使えない、正しいバグ報告書のまとめ方
一見地味なバグ票は、ソフトウエアの品質を左右するとても重要な存在だ。バグ票の書き方ひとつで、開発担当とテスト担当のコミュニケーションが円滑になり、プロジェクト全体の生産性が向上する。ソフトウエアの品質向上にもつながる。
日経クロステック Special
What's New
経営
- 平等より特別の方がビジネスに有利な理由は
- 全方位DXを推進する意義。カバー範囲は
- 「データのサイロ化」の原因とその解決法
- 企業をまたいでERPを連携? 何が起こる
- DXを内製で実現する「3ステップ」
- 深い業務理解で顧客を支援≫キヤノンMJ
- 中小企業がDXで効果を上げるには?
- ものづくりと経営をデータでつなぐ試みとは
- 製造業DXを成功に導くための3つの勘所
- 富士通と日本IBMがローカル5Gで協業
- 少量の学習データでもAI活用が可能に!?
- コロナ禍のデジタル活用=DXではない理由
- 経営層に求められるDXの船“進水”のコツ
- つなぐポイントシステムが地域を盛り上げる
- “音の出る歯ブラシ”はなぜ生まれた?
- DX先進企業は何を考えているか?
- IT人財の真価を発揮する人を軸とした戦略
- 顧客の再来店と常連化を実現した施策を探る
- IBM、ビジネスパートナー14社を表彰