H)ユーザ受け入れテスト 成果物作成要領

Home » エンタープライズアプリケーション開発 » H)ユーザ受け入れテスト 成果物作成要領

UATの成果物作成要領を記す。
UATの実施主体者は業務部門のユーザであるが、システム部門は計画から実行までの全てをサポートする。

# 成果物名 作成要領 サンプル
1  UAT仕様書  UATにおける主な検証観点は下記の5点である。 
 ・ユーザーの通常業務の遂行可否
 ・業務例外時の対応方法
 ・システムの操作性
 ・ユーザ操作マニュアルの有用性
 ・全ユーザのシステムログイン/権限設定
 以下に、それぞれの検証におけるポイントを記載する。

 ・ユーザーの通常業務の遂行可否
   要件定義、基本設計で作成した業務フローが実際にシステムを利用して
   実現できるか検証する。
   
 ・業務例外時の対応方法
   業務フローの中で問題が発生した場合に、業務の継続が可能かを検証する。
   例えば、外部システムから異常なデータが来た場合に、ユーザは
   どのようにしてそれを検知するのか、その後何をすれば修正できるのか、
   といった具体的な業務運用を作業レベルで確認する。
   
 ・システムの操作性
   画面の操作性を確認する。
    ・見やすい画面か(画面構成・色)
    ・操作しやすいか(手間が多くないか、操作ミスをしやすくないか)
    ・画面表示内容の正確さ(文言、表現)
    ・待ち時間が妥当か(ボタン押下時の待ち時間が長すぎないか)
   これらの確認は、通常業務と例外時対応の確認の中で、あわせて実施し、
   ユーザーは、「ユーザQA/要望一覧」に気になる点を記載して
   システム部門に連絡する。
   (UAT工程までプロジェクトが進むと、システムリリース日までに
    システムに変更を取り込めるものと取り込めないものに分かれる。
    そのため、リリース後の残課題として対応できるようにするためにも、
    可能な限り記録を残す)
   
 ・ユーザオペレーションマニュアルの有用性
  システムリリース後にユーザーが交代しても業務を継続できるように
  するためには、基本的なオペレーションの手順を文書に残す必要がある。
  UATを通して、ユーザオペレーションマニュアルが十分に整備できているか
  を検証する。例えば、システムの内容を把握していないユーザーに
  ユーザマニュアルを渡して業務を実施できるか確認する。
  考慮不足があれば、UAT期間中にユーザ操作マニュアルを更新する。
  この作業は業務ユーザ側で管理・推進する。
  
 ・全ユーザのシステムログイン/権限設定
  システムリリース日までにシステム権限を付与する必要がある
  ユーザを洗い出し、UAT期間中に各ユーザがシステムへログインし、
  権限に応じた機能を使用できるか確認する。

 

 (UAT計画の注意点
 業務ユーザはほとんどの場合、本業務(日々の実務)とUATを兼務で実施する。
 そのため、UATに十分な時間を当てられないことが少なくない。
 そのことを考慮して、業務繁忙期とUAT期間が重複しないように計画する、
 UAT期間を長く取る、総合テストまでに検証できるポイントは事前に実施すると
 いったような形で、ユーザーの負荷の分散を検討した方が良い。

 –
2 ユーザー
オペレーション
マニュアル

 ・マニュアルの草案作成担当者の決定
   ユーザーオペレーションマニュアルは、業務ユーザがUAT期間中に一から

  作成するのか、システム部門にて事前に初期の草案を作るのかを
  取り決める必要がある。
 ・マニュアルの品質向上(UAT期間を通して)
 いずれの場合でも、UAT期間中に業務ユーザがマニュアルをUAT期間中に

  更新する。マニュアルの修正必要箇所を把握し、修正するためには
  UAT期間中にUAT実施担当者から修正箇所の情報を集めて、管理する
  必要がある。業務部門にてマニュアルの更新プロセスを取り決めて、
  担当者を割り当てる。
 ・マニュアル作成時の注意点
 ユーザマニュアルとは、上から順に読んでいけば誰でも作業を間違いなく
  実施できるものにする必要がある。(曖昧性は排除する)
 画面キャプチャにコメントを加えて、わかりやすくする工夫が必要である。

– 
3  ユーザQA/
 要望一覧

  UAT期間を通して、システムの問い合わせ、不具合の指摘事項を記録する。
 システムリリースまでの対応要否を判断する
ために、下記の情報が必要である。
 
 ・QA/要望に関する情報(業務ユーザが記載する)
  ・QA/要望区分
   記載する内容が、質問か要望のどちらなのか選択する
  ・QA/要望の概要(簡潔に記載)
  ・QA/要望の詳細内容
  ・起票者
   調査担当者が調査結果を回答する際のユーザ側の確認者を記載する。
 
 ・調査に関する情報(システム部門が記載する)
  ・調査担当者
  ・調査結果
          システム部門による調査の結果、下記のいずれかになる。
    ・システム部門が業務部門にQAの回答をする。(解決する)
    ・ユーザがQAまたは追加要望として起票したものが、システムの不具合で
     あることが判明する。(システム部門が修正する)
    ・ユーザの追加要望であることが分かり、対応時期を業務部門と
     システム部門とで協議する。   

 ・対応方針に関する情報(システム部門が記載する)
  ・修正・対応担当者
  ・対応内容
  ・対応見積もり工数
  ・対応可能時期
   システムリリースまでに間に合うか否かを明らかにする。
  
 ・作業のステータス管理情報
  ・進捗状況
   (システム調査中、システム修正中、UAT環境へリリース済み、
    ユーザ確認完了、対応不要)

  ・作業進捗率(0%~100%)
   (例)未着手:0%
      システム調査中:10%
      システム修正中:20%~70%(作業状況に応じた割合)
      UAT環境へリリース済み:80%
      ユーザ確認完了/対応不要:100% 

– 
4  残課題と
 システム追加要望

 ユーザQA/要望一覧の対応の中で、システムリリースまでに対応できない
 ものを一覧に取りまとめる。
 システムリリース判定日までに、その後の対応予定を業務部門とシステム部門の
 間で合意する。

– 
5 設計/開発/テスト成果物 一式
(更新) 

 ユーザQA/要望一覧の対応の中で、システムの修正が必要な場合は、
 設計から総合テストまでの各成果物を更新する。
 ソースコードのみでなく、設計・テスト関連の文書の更新も合わせて実施する。

–