仕事上、Webサービスの機能追加、改善修正実施時に対象機能の受入テストを実施しますが、担当者の異動して、新規参画者が受入テストを担当するときに、どうしてもノウハウが引き継がれず、失敗するというパターンが多いです。

テストケースのテンプレート等の問題ではなくて、全体の進め方、ノウハウの共有がなかったりすることが原因な気がしたので、個人的な脳内の整理も含めてWebサービスの受入テストの進め方についてまとめてみます。

前提

以下のような状況を前提で受入テスト進め方について記載しています。

  • 受入テストはSIerが作成した成果物に対する受入の場合、自社の社員が開発した小規模な改修の場合がある。
  • QAチームのテスト、第3者検証視点のテストではない。

受入テストの目的

受入テストの目的は以下の2点です。

  • サービスが実現されていることを検証する
  • SIerの成果物を検収する

受入テスト実施前に知っておいた方が良さそうな情報

受入テスト実施前に以下の情報は一読しておくべきだと思います。

受入テストの作業フェーズについて

受入テストの作業フェーズに以下に別れます。

  1. テスト計画&テスト仕様書 作成フェーズ
  2. テスト実施フェーズ
  3. テスト終結フェーズ

それぞれのフェーズを詳細に説明します。

1. テスト計画&テスト仕様書 作成フェーズ

テスト計画をし、テスト仕様書を作成するフェーズです。
テスト計画、テスト仕様書の作成には以下の資料がインプットになります。

  • インプット資料

    テスト実施以前に作成されたプロジェクトの成果物全てがインプット資料になりますが、特に以下が重要なインプット資料になります。

    • 要件定義書
    • 設計書
    • 単体テスト結果、結合テスト結果
    • 議事録

    • 成果物作成の流れ 1. テスト計画書に含める記載項目を決める

      テスト計画書に含める項目を決めます。これは会社の標準で決まっているケースと定まっていないケースがあるかと思います。JSTQBのシラバスには項目の例として以下が記載されています。

      • テストの範囲、目的、リスクを決定する。
      • テストに対する包括的なアプローチを定義する。
      • テスト活動をソフトウェアライフサイクルでの活動に統合し、協調させる。
      • 何をテストするか、さまざまなテスト活動でどのような人的リソースとその他のリソースが必要であるか、どのようにテスト活動を進めるかを決める。
      • テスト分析、設計、実装、実行、評価の活動を、特定の日付（例えば、シーケンシャル開発）または各イテレーションの状況（例えば、イテレーティブ開発）でスケジューリングする。
      • テストのモニタリングとコントロールのためのメトリクスを選ぶ。
      • テスト活動の予算を決定する。
      • テストドキュメントの詳細レベルと構造を決定する（例えば、テンプレートやサンプルドキュメントを提供する）。

      会社や、参画プロジェクトで記載するポイントは様々で、1度作ってしまえば使い回しが効くポイント、毎回決定が必要なことがあります。

      • テスト計画毎に決定する必要があること
        • テストの範囲
        • テストの目的
        • リスク
        • テストのアプローチの定義
        • 人的リソース
        • テストスケジュール
        • 予算
      • 1度決めれば使い回しが効きそうなこと
        • テストのメトリクス
        • テストドキュメント

    1. テスト計画を作成する
      決定した記載内容に基づいてテスト計画を作成します。

    2. テスト仕様書を作成する
      テスト計画に基づいてテスト仕様書を作成します。

      1. テスト観点を洗い出す
        自然言語でテスト観点を洗い出します。テスト観点はユースケースごと、業務フローごとにまとめます。
      2. テスト因子、水準を洗い出す
        テスト因子と、水準を洗い出します。
      3. テストケースを作成する
        テスト因子、テスト水準のバリエーションをもち、テスト観点の確認ができるテストケースを作成します。
      4. テストケースを元にテスト実施見積もりを作成する
        テストケースが作成できると、テスト実施の見積もりが作成でき、この段階で精度が比較的高いテストスケジュールが作成可能です。

    2. テスト実施フェーズ

    テスト計画、テストケースをインプットに実施していきます。
    テスト実施フェーズでは以下が成果物となります。

    • バグ表 (バグチケット)
    • 進捗の推移 (日次でのバグ集計結果)
    • 修正されたプログラム、ドキュメント

    3. テスト終了フェーズ

    テスト実施が完了後にテストを終了します。テスト終了フェーズでは以下が成果物となります。

    • テスト結果報告書
    • テスト終了判断結果
      テストを続けるか、終了してリリースするかを判断します。 (リリースしなければならないことが多いです)

    受入テストの各作業フェーズでの留意事項

    各作業フェーズで個人的に気をつけている点を記載します。

    1. テスト計画&テスト仕様書 作成フェーズ

    • 時間がない場合はテスト実施を優先する
      テスト計画をして、テスト仕様書を作成しても実施までできなければ意味がありません。 スケジュールが厳しい場合は、実施をできるだけ優先しましょう。

    • テスト仕様書作成作業は、設計書の妥当性の検証作業でもある
      テスト仕様書作成作業は、設計書の妥当性の検証作業でもあります。 質問により事前にバグが検知できます。設計書作成者とテスト担当者が異なる場合は積極的に質問をしましょう。

    • 他のチーム、他の企業が関わる場合はコミュニケーションの取り方を事前にすり合わせしておく。
      他のチームや、他の企業が関わるテストの場合はバグ発生時のバグチケット のやりとりが自チームだけの場合とは異なる可能性があります。コミュニケーションの取り方を事前にする合わせましょう。

    • テスト優先度を設定する
      何が重要なテストで何が重要ではないのかを把握して、優先度を設定しステークホルダと実施優先度の合意をとりましょう。

    • 前フェーズでのテスト内容を把握する
      単体テスト、結合テストで実施済のテストケースを受入テストで実施しても観点によっては意味がないテストになります。確認の観点を変える。もしくは思いきってテスト対象外にしましょう。

    • テスト実施の環境を事前に把握する
      テスト計画に記載すれば良いですが、記載されないこともあります。
      テスト実施環境をテスト実施フェーズではなくテスト実施前に把握しましょう。

    • テストの開始条件とテストの完了条件を定める
      これもテスト計画に盛り込む内容です。
      テストの開始条件とテストの完了条件を定めましょう。

    2. テスト実施フェーズ

    テスト実施時の留意事項としては、以下が浮かびました。

    • バグの優先度付けをする
      プロジェクト視点でテストケースをブロックするブロッキングバグが最も修正優先度が高いです。
      バグがブロッキングバグなのかどうか判断してブロッキングバグの場合実施不可能になるテストケースを把握し、時間を無駄にすることがないようテスト実施者に共有しましょう。

    • ブロッキングバグ（ぶろっきんぐばぐ） - ITmedia エンタープライズ

    • バグから学習しテストケースを修正、追加する
      バグからシステムの挙動が学べます。学んだ結果を基にテストケースを修正、追加しましょう。

    • バグチケットをテンプレート化しておく
      テスト計画として決めておくことですが、決めていなくてもバグチケット はテンプレートを作成しそれを基に起票しましょう。開発者との無駄なコミュニケーション を削減できます。

    • バグは日次で集計する
      バグは日次で集計することで時系列データが得られます。日次での進捗が見えるようになると後で振り返った際に得られる情報が格段に増えるので、日次で記録するようにしましょう。

    3. テスト終了フェーズ

    • 実施した結果を次に活かす
      実施結果は次のテストのインプットになります。同一プロジェクト以外でも使いまわせるように、問題点を少し抽象化したべし集、べからず集を残すのが良いかと思います。

    • 報告に時間をかけなくても情報が集まるように、実施フェーズのドキュメント のフォーマットを作り、記載内容を意識する
      報告のための再集計ではなく、報告に必要な情報が記録できるフォーマットを作りましょう。
      次のプロジェクトにいかせない情報の記録は記録する意味が半減します。

    受入テストの進め方について思いついた事項を記載してみました。
    個人的にテスト計画と日次でのトラッキングは疎かになることが多いように思います。
    以上です。

コメント

カテゴリー

最近の投稿