総合テストと受入テストの違いとは
総合テストと受入テストでの位置づけとタスク
総合テストはシステムテストとも呼ばれます。
総合テストはそこまでに作られていたソフトウェア群をシステム全体としてテストし、システムの稼働に備えることになります。
受入テストと混同しているケースもありますが、本来別物です。
混同する理由は、少しユーザ側・利用側の要素が出ているからです。ユーザ要素が少しでもあると、ITベンダーがユーザに責任を押し付ける理由になります。
総合テストぐらいの段階になると、プログラムを作成していた下請けが離脱していることも多く、元請の力量が少ないと、総合テストはあなたが考えてくださいと言い出します。
総合テストは、システムを作る側の最終的な確認段階ですので、話をすり替えられないよう気を付けましょう。
そして、受入テストは、利用側がシステムを作る側のテストが終わっているかを確認するものです。
受入テストの次にあるものは運用テストです。運用テストは利用シーンに合わせて運用を確認していくものです。
よって、受入テストは運用できる状態になっているかが完了の視点になります。
総合テストの前提
総合テストが実施できる前提は、結合テストが終わっていることです。
それは当然のことということになりますが、曖昧になりがちな部分があるので、気を付けないといけません。
それは、結合テストの最終段階はシステム全体を結合するテストにより、品質が確保されている必要があるということです。
開発しているＩＴシステムの規模や範囲にもよります。あまり大きくない規模であれば、結合テストの最終段階と総合テストは同じになることもあります。
いずれにしても総合テストを始められる状態になっていないといけませんので、これより説明する総合テストのタスクを確認の上、開始条件を満たしているかをよく確認しましょう。
総合テストのタスク
総合テスト計画策定
全体的なタスク順序としては、計画、手順化、実施、評価となります。
まずは、計画を策定することとなります。
総合テストの内容は外部設計の裏返しとなります。
よって、外部から見たシステムの状態を確認することになります。
外部と言っても外部設計の説明でもしましたが、見えない部分もあります。それらも含めてテストを網羅的に実行していくことになります。
要件網羅のためテスト
テスト観点によりいくつかテストパターンを挙げていきます。
まずは、要件網羅するためのテストです。
要件は設計として現れているため、その設計どおり動くのかテストします。
機能の単位で確認していくことになります。
システム結合観点でのテスト
機能の塊のつながりを中心にテストしていきます。
今回構築しているＩＴシステムとは別のシステムを繋げる要件もあり得ます。その場合、連携テストを組み込むことになります。
いくつかの機能単位を作っている比較的大きなシステムであれば、繋げるための準備もそれ相応に労力を要します。
実施は必須となりますが、計画は期間も含めて無理のないものにする必要があります。
性能面のテスト
ＩＴシステムの性能が出ないと、一発で使えないものとなりアウトとなります。
よって、システム基盤設計時によく検討されるものです。しかしプログラムとネットワーク、基盤といった全体で性能が確保できるかは、組み上がっていないと確認できない点も多いです。
現行データテスト
新システムを構築した場合、既存システムが存在することも多いでしょう。
新システムで処理されるべき現行システムデータを加工して、データ量やデータパターンを正しく処理できるかをテストします。
データ発生のパターンは利用者が多い場合、どのように利用されているかわからず、想定していないデータケースがあるかもしれません。
マックス値・負荷テスト
ＩＴシステムの耐性を確認するには、マックス値をテストしてみることが最も分かり易いです。
システムが処理できる値や件数がマックスを超えていると、動作しなくなることもありますが、桁落ちなどで誤ったデータが正しく処理されることもあります。
また負荷による耐性を見るテストも実施します。
負荷は多数の人が同時に利用するなどにより発生しますが、実際に参加できる人や環境を用意できない可能性が高いです。
シミュレータなどにより実施することが多いです。
セキュリティテスト
セキュリティについては、正しく使えることと不正に侵入するという2つの観点から、問題ないかを確認します。
正しく使えるのは、正当なIDでシステムに入りますが、正しい権限範囲となっているかという点が重要となります。
正当なIDではあっても、パスワード管理が緩ければ、不正に正当なＩＤが使われてしまいますので、この点も確認が必要です。
不正な侵入は技術的な要素が大きいです。ネットワークからの侵入ができない、もしくは攻撃されないかを確認します。技術的なテストは第3者の専門家に頼まないとできないこともあります。
総合テストのテスト結果評価
各テストは結果を評価した上で、次に進みます。
テスト結果の評価方法は、テスト計画時に決めておくべきではありますが、実施してみないと想定外の状況になっていることもあります。
定量的な観点と完了していることといった定性観点は事前に決めることができます。
また開始前からわかっていた課題を潰すためのタスクが完了しているということも評価観点に入るでしょう。
テストを実施している最中に、思ってもいなかった点で障害が発生してしまうことがあります。その際は、その障害が潰れることが完了条件になります。
一定規模のプロジェクトであれば、定量的な評価も一定水準に収束する可能性が高いですが、そうでなければ水準がバラバラになり、評価にならないこともあります。
よって、最初に定量評価基準を決めたとしても、障害発生の中味や件数、残課題収束傾向により、状況を評価しましょう。
テストで発生した課題への対策実施タスク
テストが完了した時点で、テストで発覚した課題が残っているかと思います。
軽微なものしかなく、すぐに対処が終わっていればいいですが、何らか期間が必要なものが残る可能性が高いです。
残課題を対処するタスクはテスト評価の後に予め計画しておきたいところです。
つまり、テスト実施と評価がテスト期間ギリギリまで予定されていることは、既に遅れを意味していることになります。
また、この際注意すべきは、修正を施すにしても、既にテスト済みの部分も含めてまた正しく動くかを確認するテストが必要ということです。
一部の修正を施したことで、別なところが間違ってしまう可能性があります。
このリグレッションと呼ばれるテストは広範囲になることもありますので、十分な期間をもって計画しておきましょう。
受入テストのタスク
受入テスト計画策定
受入テストは、要件定義で決められたものが実現されているかを確認します。
ここへきて、要件定義の重要さが初めてわかってしまう発注者も多くいます。
要件定義の段階は、まだものができていないため頭で考えながら作っていくわけですが、これはあまり経験がない人にとってはとんでもなく疲れるものです。よって、考えることを一定レベルまできて辞めてしまうことがあります。
出来上がって受入テストする段階となって、最初に決めたことを思いだすわけです。
大抵は実現できているはずです。しかし、要件定義の言葉が足りなかった部分などで評価が分かれます。
テスト計画においては、要件定義からより具体的になっている状態を踏まえ、また、実運用を想定し、当初実現しようとしたことができるかどうかを確認していきます。
受入テストにおける現行新規比較
新しいITシステムを作成した場合に、現行システムとの比較を行います。
現行システムといった形のものがないケースもあります。
Ｅｘｃｅｌなどで業務しているケースがあるからです。その場合においても現行新規の比較はできます。
現行Ｅｘｃｅｌで作成している請求書を、そのままに近い形でシステムに発行するということもあります。
現行システムを更新し、一部機能追加しているようなケースは厄介です。
現行システムのそのままの機能はそのままの結果にならないといけません。よってそのままとなる確認を行います。
ところが、そのままとするのは、実は簡単ではありません。というのは、一部機能追加していることが、そのままにすることが難しくしていることがあるからです。
あるいは、ＳａａＳに入れ替えることもあるでしょう。サービス提供されている機能を利用しているので、そのままとなりません。しかし、そのままとならないなりに要求を満たすよう要件定義しているはずです。その差異を認識したうえで、同じことができるかを確認します。
業務サイクルシナリオテスト
ＩＴシステムは入力から出力まで一連の流れがあります。また、日中やること、夜間にやること、月一回やることなど、サイクルが存在します。
業務サイクルテストでは、これらのサイクルを一通りテストします。
あくまでもテストですので、全く同じことはできないかもしれません。ただし、少なくとも通常発生する業務のケースを網羅することと、当初要求を満たしているかのテストは実行しておきたいです。
サイクルですので、いくつかのITでの処理が実行されています。その間、データの流れや値が正しくなっているかという観点で確認することが肝要です。
また、テストする値やコードは、通常利用するものに加えて、上限・下限とそれを超えたエラー値を実行してみることをお勧めします。
実データテスト
総合テスト時に現行データテストというものを説明しました。それと似ているように思えますが、少し違います。
現行データテストは現行発生しているデータをテストデータのパターンとして利用します。そして、実データテストは、実運用に則ったテストをするためにデータを使います。
実際ＩＴシステムを使って、問題ないことを検証するために、今の実データを利用するということになります。
実データを新しいＩＴシステムとして置き換えて、一から登録する場合もあれば、データ変換して一括処理する場合もあります。
受入テストのテスト結果評価
受入テストは最終的に結果評価を行います。
この結果は、稼働できるかどうかという判断にも直結します。
総合テストが完了し、基本的にはＩＴシステムとしては完成しているという位置づけで、最終確認を行うというタイミングですので、基本的には問題は発生していては困る状況です。
しかしながら、このタイミングでも障害は発生します。
障害は当初要求を満たしていないという、大きな問題となる可能性があります。
その理由は、要求に対して要件定義を行った段階で、既に漏れていたということが多いです。
要件定義段階で、漏れがない状態まで分析と定義ができていればいいですが、すべてを漏れなくというほうが難しいかもしれません。
なので、全工程にて目的に合致しているかを確認していくことが重要なのですが、それでも最終段階でも発覚しないこともあります。
発覚した障害、課題、問題について、解決しているのか、解決していない場合どうするのかを含めて評価します。
受入テスト結果による対策実施
受入テストの結果評価を行った際に、残課題への対策が必要となります。
総合テスト同様に、結果評価の後に、その対策を実行する計画を予め立てておきます。
もし何もなければ、それに越したことはありません。
この段階での課題対策は、要求そのものへの対応に関係する可能性がありますので、場合によってはかなり大掛かりな対策になる可能性もあります。
発注側としては受注側と揉める場面も出てきます。
対策の実施可否および実施の場合の費用負担と計画についても、整理されたうえで、実行します。
また、実行にあたっては、既にほぼ完成しているＩＴシステムのため、デグレードが発生しないよう、留意の上進めることとなります。
テスト計画策定のコツ
総合テスト、受入テストに限らず、すべてのテストにおいて言えることですが、テストケースを策定するにあたってコツがあります。
ＩＴシステムは構造的にできています。機能は、詳細な機能に分解されていて、各機能が有機的に結びついてシステムとなっています。
システムを全体として大きく見た場合でも、一機能単位で小さく見た場合でも同じで、テストとしてのコツがあります。
それはデータの入出力に着目することです。
データのインプットとアウトプット、そして処理ロジックが存在します。
まず、データのインプットとアウトプットのそれぞれ、正常なケースと異常のケースを網羅します。
正常なケースは、パターンを網羅します。
データの値や、コードのケースについて、上限・下限とそれをぎりぎり超えたところをテストケースとします。
品質が悪いと、最低限の上述ケースを行っただけでも、かなりエラーが出ます。
特に受け入れ時には、同じ意味合いのデータで繰り返しテストするより、上述のケースを網羅するだけで、効果的に品質確認が可能となります。
総合テスト・受入テストのマネジメント方法
統合テストと受入テストとでは、もちろん別な目的で別な主体で実施されることになりますが、マネジメントという観点では似たようなケースとなるため、一度に説明します。
テストでの目的マネジメント
合目的性のマネジメントは、プロジェクトでは最初から最後まで一貫して必要、ということは説明してきました。
総合テストや受入テストの段階では、特に最初に決めた要求との合致を確認する意味合いが強くなります。
従って、テストにおいて設定したケースで問題ないかという観点もありますが、その背景にある元々達成したいことの目的と合致しているか、という観点を持って取り組みたいです。
目的合致の考え方により、意思決定が明確になるケースが増えます。
仕様がはっきり決まっていなくて、どうするべきか迷うときに、どの方法が目的に合っているか、という観点が加わるということです。
期間が優先であれば、少し機能実装に漏れがあっても進む場合もあるでしょうし、目的がコスト重視であれば、コストのかからない選択肢が優先となります。
目の前の課題・問題をその場その場で解決しなくてはならないのは確かですが、行き詰った時は、目的から考えてみることがお勧めです。
テストのタスク順序
テストのタスクとしては、テスト計画、テスト仕様、テスト準備、テスト実施、評価、評価後の対策実施となります。
工程の計画としては、テスト実施に大きな制約があるという前提で組んでいきます。
つまり、システム全体を扱うため、他の作業が基本的にはできない、クリティカルパス上のタスクになるということです。
逆に言うと、他の作業は他と重ねて実行することもできるということになります。
テスト計画は特に、結合テストを待たずにもできるはずです。よって外部設計が終わった段階から計画策定を始めることも多いです。
また、テストは何種類かありますが、全体として動かす必要があるケースと局所的でも大丈夫なケースがあります。
従って、重なってくるタスクも含めて、実際のタスクが、効率を考慮したうえで組まれるということになります。
テストとして実行すべきケースと実行タイミングが別になることもあります。
システム全体を動かすので、サイクルを回していく間に、それぞれのテストケースを仕込んでいくほうが実行としては効率的だからです。
テスト進捗のマネジメント
上述のようにテストのタスクが組まれ、タスク毎の進捗を定期進捗会議などで確認していくことになります。
進捗を計る上で、重要なのは、結果評価を考慮することです。
すべてのテストケースにおいて、すべてサイクルを回してから、最終的に結果評価するということでは、問題が最後にならないとわからないことになります。つまり、途中経過においては、タスクが問題なく進んでいるようにしか見えないということです。
従って、テスト結果評価と対策のスケジュールをしかるべきタイミングで計画しておく必要があります。
テストにはテスト準備工程が必要であり、準備にそれ相応に工数・期間が必要なことが多いです。そのことも踏まえ、テスト実施のサイクルと評価を予め組み込みます。
そして、不具合が発生することを想定して、不具合解消結果を入れ込むサイクルを計画しておきます。
それらタスクが組まれたうえで、進捗を計っていくことで、品質面での実態に近い進捗の把握になってきます。
品質の曲線と課題トレンド
品質目標を定めて、そのトレンドを追うという手法が品質曲線です。
品質目標を設定するのがそもそも難しいのですが、一定規模であれば収束していきますので、目標設定は可能です。
またテストケースが期間を通じて、有効に設定されていれば、曲線もそれなりに正しくなります。
もう一つは、課題トレンドです。
課題は、障害とは別です。何らかタスクを進めるのに弊害となっているものが課題です。
課題は障害として対応することもありますし、他のタスクに反映して完了のこともあります。
いずれにしろ、テスト段階で課題が出ることはありますので、課題の発生と対応、残課題状況について日々状況を追っていくことで、トレンドを見ることができます。
まずいプロジェクトは課題の積み上がり方が極端です。
しかし課題を管理できていないことのほうが、より問題ですので、地道に管理し監視していきたいです。
テストでの問題発生時のテコ入れ
進捗を見ていく上で、問題が発生したらテコ入れしていきます。
問題と認識されたということは、今後の進捗に多大な阻害要因となるか、もしくは要求そのものへの影響ということなりそうです。
まずは、実態は現物を見て判断します。
誰かのバイアスの掛かった報告だと、実態が違っているということがあります。
つめり、なんとか進めたくて、甘い見込みでそのまま進めてしまうということになりかねません。
現物を見て、どこに問題の原因があり、原因を潰すための新たなタスク、大抵はこれまで本当はやらなければならなかったタスク、を見積り、タスク全体を計画し直すということになります。
予め評価結果を受けた対策実行のタスクは入れていたとしても、想定より大きくなっていることもありますので、早期発見と真の原因にたどり着けるよう、監視できるようにしておきたいです。
総合テスト・受入テストでありがちな問題
結合テストと総合テストの切り分けが実は曖昧になっていた
結合テストは、ソフトウェアを繋ぎ合わせたテストで、最終的には全体的に繋げますので、総合テストと同じようなイメージになります。
総合テストは、すべて完成した状態で最終的なシステム観点のテストを網羅的に実施します。
よって、似てはいるのですが、位置づけは異なります。
異なるのですが似ているので、誤魔化される可能性があります。
しかし、それぞれの工程で実施すべきレベルがありますので、期間がないので合わせてやります、などということは、本来通じないということを前提に対処してもらいたいです。
総合テストと受入テストの切り分けが曖昧になっていた
総合テストはシステム観点での最終確認ですので、システム側のテストとなります。
受入テストは最終的なテストが終わった段階で、発注者が受け入れるためのテストとなります。
よって位置づけは明らかに違いますが、大きなプロジェクトでなければ総合テストにユーザが参加して兼ねることもあり得なくはないです。
ただし、テストで最終的な品質を保証する行為と、その品質を確認する行為が同時に行われていることを認識して実行しないといけません。
結果的に非効率となる可能性がありますので、責任を明確にするには受入テストを明確に別に実施したほうが良いでしょう。
テストの最後のほうで、終わらないことが発覚
テストは障害や不具合が発生したら、対応をしていくことになります。
品質の状況にもよりますが、それらの対応が多く発生した場合は、テストも遅れがちとなり、問題が先送りされることがあります。
テストでその後どのくらい障害が発生するかわからないにも関わらず、これまであまり発生していないから大丈夫、という考えに陥ってしまうことがあります。
そういう時に限って、テスト終盤で問題が発覚することになり、終わらなくなります。
そもそもそれ以前の品質とテスト計画に問題があったと思われます。
テストだからバグがあって当たり前？
テストを行う以上バグを検出したいからであり、あるのは当たり前なのかもしれません。
ただし、今このテストで見つかるべきものか、というとそれは別問題となります。
本来プログラムレベルで検出すべきバグが総合テストで見つかった場合は、遡ってプログラムレベルのテストが妥当であったか確認すべきです。人によって差異があるかもしれないため、その点でも調査すべきです。
要件レベルの不具合なので、総合テストで発覚して当然である、という言い訳を聞くこともあるかもしれませんが、当然であれば、リカバリする計画が予め立っておくべきですし、あくまでも本来は要件定義での不具合であったはずです。
いまから時間を遡ることはできないため、やる直すことはできませんが、要件定義時に何が問題であったかという観点で分析・調査をしてリカバリ計画を立てるべきです。
そもそも元々やりたかったことができない
受入テスト時によくあることですが、そもそもやりたかったことができていないという問題が発生します。
目的に合致しているかという観点は最も重要であるということは言ってきましたが、まさに目的を果たしていないことになります。
目的を果たせない理由は実は明確です。
それは、目的を果たすための手段を実現することに傾注したため、目的を見失ったということです。
決算への転記を効率化するために、データ出力できるようにする、という要件があったとします。
データ出力が実はかなり困難なＩＴシステムであった場合、苦労してデータ出力をできるようにしているうちに、決算転記の要求が忘れられていました。結果、データ形式を考慮せずにデータを取り出せることだけができている機能になってしまった、ということです。
他のタスクができない
総合テストと受入テストを実施している間、他のタスクが実施されていることもあります。
よくあるのは移行、教育のタスクです。
終盤に入っているため、リリース・稼働後に向けたタスクが実行されています。
移行の計画や、教育準備はリソース面を考慮して計画をしていかないとタスクが進められません。
それ以外にもっと考慮しないといけないことが、ＩＴシステムのリソースです。
総合テストや受入テストは、他の作業に大きな制約が出ます。基本他のことはできないことが多いです。
いかし、データ移行や移行リハーサルといったタスクやイベントはＩＴシステム上で実施するタスクになります。
テストの遅延によりスケジュールがずれると、他のタスクもすれることになります。
それにより、計画が大幅に崩れます。
遅れていたので、テスト期間を圧縮しました
結合テストまでで課題が発覚し遅れてきた場合、総合テストや受入テストはもともと余裕を持っていたので、期間を圧縮します、という判断はよくあることです。
しかしこれは大丈夫でしょうか。
大丈夫な場合もあればやっぱり圧縮してもダメという場合もあるでしょう。
ダメな場合が実際はほとんどなのではないかと思われます。
途中経過で遅れていたのですから、次の工程は圧縮できるなどという保証はありません。普通に考えれば、後の工程も同じくらい遅れます。
しかし、稼働時期が決まっているため、苦肉の策でそのような判断がなされてしまいます。
テスト計画が詳細になっていない場合であれば、なおさら大丈夫という判断に寄ってしまうと思います。
テストの進行は制約が多く発生するのは先述のとおりです。なので、圧縮は安易には想定しない方がよいです。
総合テストと受入テストで本当にやるべきこと
総合テストは、ＩＴシステムとして最終段階で、総合的なテストを行う。また、ＩＴシステムが外との連携を行っている場合は、それも含めて総合的なテストを行うことになります。
受入テストは時に混同されていることがありますが、ＩＴシステムとしてのテストが完了し、受入検収のためのテストとなります。
受入テストは発注側が主体となってやるべきものです。しかし、発注側がテストケースを考えることができずに、受注側に依存してしまうこともあります。
依存してもいいですが、最終的な判断は自ら行わないといけません。
そうでないと、ここまで説明したありがちな問題が発生しても、解決を依存していることになり、遅延を始めとして当初目的が果たせなくなることは間違いありません。
要件定義をした段階や、さらに言うと要求をまとめている段階から、どのようにテストを行って確認するかを考えてもいいでしょう。
テストが外部も含んでいると大掛かりになります。テスト準備や実行に入念な計画が必要ということになります。
まだＩＴシステムができてもいない段階から考えるのは、実際は困難なことですが、主体的に考えることは少なくとも手放さないようにしていきたいです。
コメント