ソフトウエアテストをきちんとできないと、バグだらけのシステムになってしまう。ところが世の中には駄目なテストに陥っている現場が少なくない。実務を通じて分かったより良いソフトウエアテストの方法について、テスト専業ベンダーのプロフェッショナルが解説する。
これまでの連載はこちら
連載
駄目なテストの回避策
目次
-
ソフトウエアテストの終了報告書、明記すべき3項目
ソフトウエアテストでは、計画、設計、実行といった主要な3つのプロセスと並行して「テスト管理」を進める必要がある。テスト管理の最後に実施するのが「テストの終了報告」だ。テスト管理者にとって最後の大仕事である
-
ソフトウエアテストの管理、バグ票から把握すべき3つの情報
ソフトウエアテストは計画、設計、実行といった主要な3つのプロセスに加えて、管理も重要だ。テスト実行を管理する「テスト実行管理」では、テスト実行の進捗や不具合の規模、傾向を把握してプロジェクトマネジャーに情報を提供する。
-
決め方を知らずに生じる無駄、ソフトウエアテスト実行の順番
テスト実行フェーズでは、テスト環境でテストケースを消化していく「テスト実行」の前段階として「テスト実行準備」を実施する。テスト実行準備では、テスト実行に必要な作業を洗い出して実行順番やスケジュールを決定する。
-
ソフトウエアテスト実行前、外せない準備6項目
テスト実行の開始時に陥りがちなわながある。テスト実行の開始日にテストケースを上から順に消化しようとすることだ。テストケースに記載された実施手順をするには何から始めればいいのか、テスト実行者が分からなくて途方に暮れてしまう。テスト実行の前に、必要な作業を洗い出す「テスト実行準備」を実施しよう。
-
不具合を見逃さない、テストケースの必須5項目と作成方法
テスト設計では、テスト実行に向けてテストケースを作成する。テストケースの記載に不足や曖昧さがあると、正しいテスト条件、手順でのテスト実行が困難になる。記載内容の粒度や明確さも重要だ。分かりづらい書き方になっていると、テスト実行者が実施手順や合否判定を誤ってしまう場合がある。
-
駄目なテストを回避、範囲と観点と条件を決めるコツ
テストケースを作る前に、どのようなテストケースを、どのように作成すべきかといった「テストケース作成方針」を考える必要がある。特に複数人でテストケースを作成する場合に重要だ。指針もなく作業を開始すると、担当者ごとの認識や知識の違いがそのまま成果物のばらつきにつながってしまう。
-
漏れなく無駄なく、賢いソフトウエアテスト計画法
プロジェクトには納期があり、テスト対象すべてをあらゆる方法でテストすることはできない。効率良く漏れのないテストにするには、テスト対象を適切な粒度で区切り、各単位をどういう方法で確認するのかといった方針が必要だ。テスト計画では、「どうやって（How）」テストを行うのか、つまりテストのやり方を決める。
-
いきなり計画はNG、ソフトウエアテストの注意点
テスト計画では、限られた期間の中で何をテストするかを初めに決める。決して、スケジュールの作成が最初ではない。テストの対象や種類を決めずにテスト設計に進むと、必要なテストが実施されないままリリースを迎えるかもしれない。大きなトラブルを生むリスクを抱えたまま、製品を世に出すようなものだ。
-
作成怠り手戻り多発、ソフトウエアテストに必要な文書一覧
ソフトウエアテストの計画、設計、実行といったプロセスでは、インプットとなるドキュメントを基に作業を実施し、その結果をアウトプットとなるドキュメントに落とし込む。ドキュメントの作成をサボったり、内容が的外れだったりすると、後続プロセスの担当者に迷惑をかけてしまう。
-
ソフトウエアテストの必須作業、15項目を押さえる
ソフトウエアテストでやるべき作業を不用意に飛ばしていると、プロジェクトの終盤で影響の大きいバグが見つかったり、確認漏れでシステム障害を発生させたりする。今回はテストの準備段階から終了段階までの一連の作業を概観して、ソフトウエアテストに必須の一連の作業を明らかにする。
-
できるテスト技術者の条件、システム開発で3つの役割
テストというと、開発者が実施するデバッグを思い浮かべる人が少なくない。ただ、バグを見つけ出すのはテストの一部に過ぎない。ソフトウエアやシステムの品質を可視化して、より良い品質の実現に向け、何をなすべきか示すのもテストの重要な仕事だ。こうしたテストを担当する技術者を「テストエンジニア」と呼ぶ。
-
ひたすらバグつぶしの愚、ソフトウエア品質を巡る勘違い
なぜソフトウエアやシステムをテストするのか。すぐに思い浮かぶのは「仕様と違った動きや、動作不良につながるような欠陥を見つけ出すため」だろう。これは、バグつぶしのことだ。実はこれは正解の半分にすぎない。テストにはもう1つ重要な役割がある。
-
アジャイルで心が折れる、時間切れを防ぐテストのコツ
ウォーターフォール案件を中心に経験を積んできたテストエンジニアが、アジャイル型で進めるプロジェクトにアサインされて心が折れる――。ここ最近、そこかしこで見受けられる光景だ。アジャイルは短い期間で機能のリリースを繰り返す。少しずつテスト対象の機能が増えていき、徐々に時間不足に追い込まれていく。
-
パッケージソフトに不具合、テストと改修を効率化する術
パッケージ製品やクラウドサービスの開発では、不具合対応がいつまでも終わらない場合がある。不具合に場当たり的に対応してしまい、いつまでもクレームが収束しないといったものだ。問い合わせやクレームへの対応で、不具合改修、テスト、修正版のリリース予定の交渉に忙殺される日々がいつまでも続く。
-
品質を1段高める「テストケースのないソフトウエアテスト」
テスト担当者が直感的かつ自由な形式で検証を行うテストを「アドホックテスト」と呼ぶ。仕様書に沿って機能が正しく動作するかを確認する「単体テスト」や「結合テスト」「総合テスト」とは異なり、テストケースを作成しない。とはいえ、やみくもにテストを行えばよいということではない。
-
同じようなテストケースを繰り返し作る無駄、ありがちな理由と回避策
年に数回のシステム改修。毎回同じようなテストを実施するので、過去のテストケースを使い回して効率化したいと考えている。しかし、思うように再利用できず、毎回のように同じような内容のテストケースを作成している―――。開発現場でよくある光景だろう。
-
テスト自動化はもうこりごり、そんな現場が犯している間違い
手間のかかっていたテストを自動化したが、システムの機能更新のたびにテスト自動化用のスクリプトの変更に追われるようになった。スクリプトの変更は放置されるようになり、せっかくテスト自動化の仕組みを整備したのに役立たずの代物と化した――。テスト自動化を導入した現場でよくある失敗例だ。
-
修正したのに品質が低下、原因の多くはソフトの構成管理
バグ改修や機能追加でソフトウエアをバージョンアップすると、それまで正常に動いていた機能が動かなくなったりする。トラブルの発生タイミングは結合テストフェーズだが、問題の根本は結合テストの進め方や体制ではなく「構成管理」の不備にある場合が多い。
-
RPA導入で必ずぶち当たる、「テストはどうする？」の壁
数年前からRPA（ロボティクス・プロセス・オートメーション）がホットトピックになっている。だが企業の実業務への導入ではまだ課題が多い。特にテストでは「どこまでテストしていいか分からない」「テストのやり過ぎなのかコストが青天井にかかる」といった悩みをよく耳にする。
