システムテストってどう準備したらいいの？
どんな観点に気をつければいいの？
上手く進めるコツを知りたい！
と言った、疑問に答えます。
この記事を読むことで、
・システムテストの進め方の全体感を理解できます
・更に、システムテストで気を付ける観点・項目を抑えられます
・結果、システムの品質を上げ＝あなたの評価を上げる事が出来ます
本サイトでは、システムテスト＝「ベンダーが実施するテストではなく、社内SE・情シスが実施するテスト」と定義し解説しています。さらに詳しく、システム開発の様々なテストって誰がどの領域を担当すべきか？は、【システム開発のテスト全体像とは？工程・種類を分かり易く解説】の記事をご覧ください。
✔記事の信ぴょう性
SIer SE→現、一部上場企業社内SE（IT歴15年以上）。基幹システム開発、及び、グローバル１６拠点への導入やSCM・MDM等システム開発。社内SEの情報サイトIT Comp@ss運営者。「社内SE 1年目から貢献！情シス 企画・開発・運用 107のルール」著者。
✓あなたにあわせておすすめ
ITスキルを伸ばしたい方は、【システム開発が学べる本22冊】
社内SEの待遇や年収を知りたい方は【社内SE転職ナビ】
システムテストの目的とは？
システム開発で存在する、様々なテストの目的は、
【目標にしたサービス・業務をシステム化しビジネスに役立てること】です。
システムテストにおける重要なポイントは、（逆説的に聞こえますが）
【システムテストだけでこの目的を担保しない！】という点です。
システム開発では、
・単体テスト
・結合テスト
・システムテスト
・受入テスト
等々、様々なテストが存在します。これらのテストには、それぞれが目的があります。
各テストで、目的となる品質を各テストで担保し、プロジェクト全体で開発品質を担保します。
システムテストで抑えるべき目的・観点とは？
それは、シンプルに、「システムが仕様書通りに正しく実装されているか？」です。
この点を理解しないと、
・システムテストで、そもそも単体レベルで担保されている機能の洗い出しに疲弊
・業務ユーザーの視点で、そもそも要件不足で使えない、、、どうしようと焦る
等々、あなたのスコープではない課題に疲弊します。
システム要件定義で定義された仕様に基づき、
・システムテストシナリオを構築
・確認
・品質を担保
する必要があります。
この事実からも、尚更、システム要件定義で仕様をクリアにする事が重要であり、その工程でしっかりと仕様を詰める＝システムテストで正解が明確になる＝スムーズに開発工程を進められるにつながります。
あわせておすすめ記事：
システムテストの目的を正確に理解するメリット
あるべき姿は、システムテストで担保する領域をしっかりと理解し、やるべき仕事に注力します。注力すべきは、下の図の点線の領域です。
正しく、システムテストの目的を理解することにより、社内SEは自身の責任をきちんと理解し、解決すべき課題に注力できます。
図解すると以下の様になります。
・単体テストレベルの障害を検知
→ベンダーにしっかり指摘し追加のテスト促す
・業務視点で要件不足・機能不足の可能性を検知
→オペレーションでカバーするのか？それとも、追加開発を実施し納期を変更するのか？を業務と協議。
比較的冷静に何をしなければいけないのかを考えることが出来ます。
どの工程で何を担保するかを設計することにより、どのテストで何をすべきか？がりかいできるだけではなく、各テスト（システムテスト等）で注力するべきテストに集中でき、結果各テストの品質が向上し、全体のソフトウェア品質を上げることが可能になります。
システムテストで品質を上げるための観点と項目
ここまで、システムテストの工程で誰が何を目的にテストをすべきか？を解説しました。
ここからは、品質の観点からシステムテストでどんな品質を担保するべきか？を一般的なフレームワークで解説します。
ISOの定義するソフトウェアの品質評価に関する国際規格
以下は、ISOはソフトウェアの品質評価に関する国際規格「ソフトウェア品質特性：ISO/IEC 9126」を定めています。
ソフトウェアの品質は、
・「機能性」
・「信頼性」
・「使用性」
・「効率性」
・「保守性」
・「移植性」
の6つで構成されています。
各ソフトウェア品質と工程の関係は、
・システムテスト＝機能性、使用性を確認
・インフラテスト・性能テスト＝信頼性を確認
・性能テスト＝効率性を確認
・運用テスト＝保守性を確認
・全テストで移植性も併せて確認
が、一般的なシステム開発におけるテストと品質の考え方です。
システムテストでは、機能性と使用性にフォーカスして確認
システムテストを成功に導く、抜け漏れの無いシナリオの洗い出し方
ここからは、システムテストの機能性・使用性に絞り、どのようにぬけ漏れの無いテスト項目を構築し品質を担保するのか？を深堀します。
1番重要な点からお伝えします。
それは、「再現性」です。
なぜ再現性が重要か？というと、
・品質を上げるテストを単なるラッキーショットでなくする
・高い品質を担保するテストプロセスを次のテストでも利用可能
・テストプロセスを教育可能にする
・経験を積めば積むほど品質が高くなる構図を作り上げる事が可能
テストプロセスをフレームワーク化することが最も重要なポイントです。
システムテストをどのようにフレームワーク化すべきか？
方法はいくつかありますが、私の実践している1例を紹介します。
１．システムテストで利用する成果物/プロセスを体系化する
２．考え方・重要な観点をチェックリストにする
３．学んだインプットでフレームワークを改善する
この3つのサイクルをグルグルと回すことが出来れば、システムテストを実施すればするだけあなたが実施するシステム開発の品質は上がっていくことになります。
さらに、あなたが上の役職に立った際にも、このフレームワークを使い部下を育成・指導することも可能になります。
システムテストで利用する成果物/プロセスを体系化する
システムテストに必要な成果物・プロセスは主に以下です。
システムテストのプロセス
・システムテスト計画書
・システムテスト開始可否シート
・システムテストシナリオ
・システム手テストシナリオ進捗表
・システムテスト終了判定シート
↑フレームワーク化出来るようにチェックシート作成もおすすめ
システムテスト計画書
システムテストに向け、目的・範囲・期間・体制・アドミン系を決められるPPTのシートを用意します。毎回、このPPTを活用しテストの準備をします。テストの規模により不要な項目は割愛します。
PPTに記述すべき内容例
・目次
・プロジェクト背景
・全体マイルストーン
・プロジェクトでの各システムの定義
・システムテストの目的
・システムテストのスコープ
・システムテストの日程感
・システムテストの体制図
・各種アドミン系の連絡 （成果物格納先・コミニケーションルール）
システムテスト開始可否シート
私がそう呼んでいるだけのシートですが、システムテストを開始するに十分は準備が整ったかを判断するシートです。
内容は、
・前工程が全て予定通り完了したか？（例 アプリリリース・データ準備・残障害解消 等）
・テスト開始準備は完了したか？（例 シナリオ作成・人員・レポートシート作成 等）
です。
システムテスト開始判定シート記述内容例
アプリケーション
・残障害件数と対応内容
データ
・データ準備状況
環境
・システム環境設定
・ユーザー設定
・テストシナリオ準備
管理
・障害管理方法
・日々の障害
・進捗確認会の設定
シナリオ作成シート・進捗管理シート
シナリオ作成と進捗管理シートも毎回作り上げるのではなく、一度作成して、毎回それを使っている事で優れたツールに磨き上げることが出来ます
以下でお薦めのテンプレートもご紹介していますが、社内で既に使われているPPTやエクセルがあればそちらを一式そろえ使っていく方がある程度社内コンセンサスが取れているので、手っ取り早いです。
システムテストのシナリオサンプルダウンロード
OpenProcessのテンプレートが非常に使い勝手が良いと感じます。すでにDLできなくなっているのですが、上記の画像を見ながらエクセルでテンプレ作成がいいかなと思います。
良い点：
・左の軸でテスト観点を洗い出し（洗い出し方は以下で解説）
・右に関連するテストケースを書いたシートを関連図けられる
→複数人でシナリオ準備する際に誰がどこまで実施したか準備進捗が見える
全く同じテンプレートではないでいですが、以下のテンプレをDLして修正して使うのが便利です。
テスト仕様書のエクセルテンプレート(単体、結合、総合) | 無料ダウンロード
シナリオ作成のプロセスをもう少し詳細に解説（サンプル）
王道のシナリオ洗い出しのプロセスは、業務フローの理解、機能要件の一覧化、テスト項目の一覧化＋業務要件の非機能要件の洗い出しの流れです。
システムテスト計画書の作成の王道は、まずは要件定義書をしっかりと読み込み、必要な観点を地道に洗い出していく、これ一番の品質を担保するシナリオの洗い出し方です。
大体、この作業でシステムテストに必要な約80％のテスト観点を洗い出すことが出来ます。
さらに詳しくシステムテストの進め方を勉強したい方は、「システムテストを学べる書籍【ソフトウェアテストの教科書】」の記事でお薦めの参考書籍を紹介しています。
考え方・重要な観点をチェックリストにする
システムテストを通して、あなたが特に忘れやすい項目・気を付けるべき点をチェックリストにまとめておく必要があります。
ここまでの、成果物とプロセスはかなり王道の流れでした。この王道の流れの弱みはイレギュラーのケースの考慮が抜け落ちてしまう点です。
システムテスト作成時のチェックリスト例
・データ目線でパターンは全て洗い出せているか？
・業務目線で他にどんなケースが存在するか？
・ビジネスインパクト的に、何がメインでマイナーな観点は何だろう？
・時間軸を、日次、週次、月次、年次に変更した場合シナリオに漏れはないか？
・地域・法律等考慮が漏れている固有の要件・パターンはないだろうか？
こういった様々な考え方を確認するチェックリスト用意することにより、かなりイレギュラーのバグまで早期で発見することが出来ます。
学んだインプットでフレームワークを改善する
システムテストでもなんでもそうですが、学びを体系化出来る人とそうでない人では、時間を味方につけるのか？そうでないのか？の状況が変わります。
再現性のあるフレームワーク化に成功した人は、そのプロセスを繰り返すことにより一段高い基準から物事を優位に進めることができます。
ぜひ、この機会に本記事紹介した内容のいくつかを取り入れ、フレームワーク化を実施してみてください。