ITにおけるQA（品質保証）とは？開発を支えるソフトウェアテストの重要性やその内容についてわかりやすく解説！
QA（Quality Assurance）は、プロダクトの品質を保証するための大事な役割です。ITシステム開発においては、QAを通じ、システムが仕様を満たしているか、クライアントやユーザーの要求を満たしているかといったあらゆる角度から検証し、不具合の防止や安定したシステム運用を目指します。
QAを十分に行うためには、品質保証やテストの重要性、テストの設計から技法について、テスト担当者として必要となるスキルが求められます。最近ではアジャイル開発やテスト自動化ツールの普及により、どの立場においてもテストについての知識や技法などが必要となるケースが少なくないからです。
加えてテスト担当者以外が、テストに関する知見を深めにくいという悩みもあるのではないでしょうか。本記事ではQAにおける品質保証をはじめ、ソフトウェアテストへの取り組み方から手法・技法といった詳細について、わかりやすく解説していきます。
QA（品質保証）とは？
QAは「Quality Assurance」の頭文字で、日本語では「品質保証」と訳されています。
QA（品質保証）においては「欠陥がない」「仕様通りに動作する」だけでなく、ユーザーが満足するような製品・サービスの提供が求められます。さらにトラブルなく安定した稼働を担保するためには、常に高水準の品質を目標にしなければなりません。
製品・サービスの品質は開発段階からユーザー視点で評価する必要があり、上流工程からQA（品質保証）に関与します。良質なプロセスが正しく実行されれば、最終的に良質なプロダクトが完成する確率が高くなるのです。
歴史的に、QA部門がソフトウェアテストを担当することが多かったため、QA=テストという意味合いで使っている企業も多く存在します。ですが、QAが扱うのはそれだけでは無いため、この記事では「QA」と「テスト」を別の言葉として取り扱います。
QAとソフトウェアテストの重要性
ソフトウェアにおけるテストの重要性は、普段の日常生活においても無視できません。テレビやパソコン、電子レンジや炊飯器などほぼすべての電化製品はソフトウェア制御によって動作しています。
コンビニや飲食店のレジでは、QRコードやクレジットカードといった電子決済を利用する方も増えてきました。これらのシステムに不具合が発生すれば、日常生活に支障をきたすことになります。
これらのシステムが安定稼働するためには、開発段階でテストを実施して、問題点を事前に解消しなければなりません。実際にはテストを実施していても、テストパターンに不備があったり、想定外の事象が発生して障害が発生してしまったりするケースも多く存在しています。
【事例1】全国銀行資金決済ネットワーク（全銀ネット）
2023年10月、全国銀行データ通信システム（全銀システム）において、金融機関をつなぐ送金システムに不具合が発生。約550万件を超える振り込みの処理が遅れるなど、銀行業務において多大な影響を及ぼした。
参照：https://www.itmedia.co.jp/news/articles/2312/28/news104.html
【事例2】全日本空輸（ANA）
2023年4月、飛行機の搭乗手続き・予約・販売に関する国内線のシステムで不具合が発生。空港での各種手続きがストップしたため、多数の便で遅延や欠航が相次ぐ事態となった。
参照：https://www.itmedia.co.jp/news/articles/2304/07/news167.html
QA（品質保証）とQC（品質コントロール）との違い
現在でも多くの企業で「QA（品質保証）」と「QC（品質コントロール）」の言葉が同様に扱われることがありますが、QAとQCは同じではありません。
QC（品質コントロール）はプロダクト指向の是正アプローチ（適切な品質の達成を支援する活動）であり、一定の品質を達成するための活動にあたります。また、テストは品質コントロール（QC）のひとつです。
QA（品質保証）は、プロセス指向の予防的アプローチ（プロセスの実装と改善）が焦点です。
テスト結果は、QCでは不具合の修正に、QAでは開発とテストの進捗管理やフィードバックなどに利用されます。QAは開発とテストの両プロセスに参加して、プロジェクト全員で取り組むことが重要です。
そもそもソフトウェアにおける品質とは
ところで、そもそも「品質」とはいったい何を指すのでしょうか？ バグが少なく、期待通りに動作すれば品質が高いといえるのでしょうか？ それとも、他にも尺度があるのでしょうか？
ユーザーの要求や満足度から見た品質
アメリカの著名なコンサルタントであるPhilip B.Crosby（フィリップ.B.クロスビー）氏によると、「品質は要求を満たすこと」であると定義しています。同じくコンサルタントとして知られるG.M.Weinberg（G.M.ワインバーグ）氏は「品質は誰かにとって価値のあるもの」という定義を唱えています。
このことは、単にソフトウェアが「正しく動く」だけでは不十分です。ユーザーの仕事が楽になったり、生活が便利になったり、あるいはビジネス上の利益を生んだりといった価値を生み出すことが重要であることを表しています。仕様通り正しく動くが使いにくいソフトウェアは、ユーザーの要求を満たしておらず、価値を産まない可能性があります。
特性ごとに細分化した品質（品質特性）
上述のクロスビー氏とワインバーグ氏の定義は分かりやすいですが、同時に漠然としています。要求を満たすとはどのようなことなのか、価値を生み出すとはどのようなことなのか、もう少し踏み込んで考えたいところです。
そこで、ISO/IEC 25010 の 製品品質モデルを見てみましょう。このモデルは、製品が持つ品質を8つの特性に分類し、それらをさらにいくつかの副特性に分けたものです。
【ISO/IEC 25010の8つの品質特性とそれぞれの副特性】
1.機能適合性: 明示的、暗示的なニーズを満足させる機能の提供
・機能完全性：要求された機能がすべて実装されている
・機能正確性：求められた結果を正確に提供する
・機能適切性：目的達成に不要な手順が含まれていない
2.性能効率性: 明記された条件と資源の関係が適切である
・時間効率性：機能を実行するときの処理時間などが適切である
・資源効率性：機能を実行するときに使用される資源が適切である
・容量満足性：製品またはシステムの最大限度がニーズを満足させる
3.互換性: 同一環境であれば情報の共有ができる
・共存性：同一環境であれば他に影響を与えずに効率的に機能を実行できる
・相互運用性：2つ以上のシステムで交換した情報が使用できる
4.使用性: 明示された利用状況において有効性、効率性、満足性をもって利用できる
・適切度認識性：利用者がニーズにマッチしているか認識できる
・習得性：利用者の学習目標が達成できる
・運用操作性：システムが運用しやすい
・ユーザーエラー防止性：システムによって利用者のエラーを防げる
・ユーザーインターフェース快美性：利用者にとって満足できるインターフェースである
・アクセシビリティ：さまざまな利用者が目標達成できる
5.信頼性: 明示された時間や条件で機能を実行できる
・成熟性：信頼性と利用者のニーズが合致している
・可用性：いつでもシステムが利用できる
・障害許容性：故障が発生しても運用できる
・回復性：中断や故障の後に希望する状態に復元できる
6.セキュリティ: 製品またはシステムが情報を保護する
・機密性：アクセスコントロールできる
・インテグリティ：修正権限のない状態ではデータの修正ができない
・否認防止性：後から否認できない仕組みがある
・責任追跡性：責任の追跡が可能である
・真正性：情報の正しさが照明できる
7.保守性: 修正や仕様変更への対応ができる
・モジュール性：1つのモジュールに対する変更が他に影響しない構成になっている
・再利用性：資産の再利用ができる
・解析性：故障などが発生した場合に原因の識別ができる
・修正性：品質の低下を起こさずに修正できる
・試験性：テストの基準が明確な状態でテストができる
8.移植性: 別の利用環境に構成要素を移せる
・適応性：システムが周辺のハードウェアや利用環境の進化に適応できる
・設置性：明示された環境においてシステムの設置や削除ができる
・置換性：同一環境において同じ目的を達成する別の製品に置換できる
ここで気をつけなければいけないのは、これらは必ずしも 製品品質を構成する要素の完璧なリスト ではないことと、 これらをすべて網羅すれば製品が売れるわけではない ということです。
ユーザー満足と品質の関係
品質特性とユーザー満足の関係を探るために、「狩野モデル」と呼ばれる品質モデルを見てみましょう。
1980年代に東京理科大学名誉教授の狩野紀昭氏が提唱したこのモデルは、品質と顧客満足度の関係として海外でも広く参考にされています。狩野モデルではユーザーの要求を、「当たり前品質」「一元的品質」「魅力的品質」の3つに分類しています。（※1）
（※1:この他に、「無関心品質」と「逆品質」が加わることもあります。）
1.当たり前品質
できて当たり前（充足）と受け取られるが、ない（不充足）と不満に感じる品質。ユーザーにとってソフトウェアが正常に動くことは当然ですが、仮に不具合が発生すればユーザーは不満に感じることでしょう。
2.一元的品質
あればあるだけ嬉しいし、なければないだけ不満だと感じる品質。たとえば、自動車であれば燃費がこれに当たります。燃費が良ければ良いほど嬉しいし、悪ければ悪いほど不満だからです。ソフトウェアであれば、Webページの表示速度などが該当します。
3.魅力的品質
なくても構わないが、あると嬉しい品質。たとえば自動翻訳やAIアシスト機能といったオプション的な機能が該当します。母国語でのサービスであれば自動翻訳機能がなくても問題ありませんが、外国人や語学に興味がある人には、高い満足度を提供できることになります。
品質をこのように分類することで、どのような品質特性がどのようにユーザーの満足度に影響するのかが分かります。
たとえば、機能完全性 や セキュリティ は当たり前品質、 性能効率性 は一元的品質、信頼性 を魅力的品質として扱うプロダクトがあったとしたら、プロダクトは機能安全性とセキュリティを確実に担保するような品質保証の仕組みを整える必要があります。
同時に、ユーザーの満足度を高め競合優位性を保つためには、性能効率性と信頼性を高めることが必要です。
（参考: https://note.com/smorisaki/n/n17ff9f0a02d1）
QA（品質保証）は誰が行うのか
QA（品質保証）は誰が行うべきなのか、この議論はよく耳にすることが多いかと思います。職種ごとに業務内容や開発フローにおける役割はありますが、テスト担当者が持つべき視点はどのエンジニアにも共通であることが考えられます。
QAエンジニア
QAエンジニアとはソフトウェアを含め、サービスの品質向上を担うエンジニアです。テスト仕様書の作成からチェック作業、パフォーマンスやセキュリティなどの品質向上など、サービスに関する業務を幅広く担当します。テストだけでなく製品開発にも参加して、さまざまな角度から品質に貢献することが重要です。
開発エンジニア
事業やプロダクトのフェーズによっては、チームに専任のQAエンジニアが存在しない場合もあります。その場合でも、それぞれの開発エンジニアが品質に責任を持ち、ユーザーが満足するソフトウェアプロダクトを作るよう努力すべきです。
また、チームにQAエンジニアがいたり、QA専門の部署があったりするからといって、開発エンジニアが品質に無関心であってよいわけではありません。開発エンジニアも常に品質意識を持ち、QAエンジニアと同様の視点を持つことが望ましいです。
QAに関わる人が持つべき視点
ソフトウェア品質の概要について理解した上で、QAについてエンジニアが持つべき視点についても確認しておかなければなりません。テスト工程における2つの視点について触れておきます。
Verification & Validation
「Verification & Validation」は検証と妥当性確認という意味で、V&Vと略されることもあります。
Verification（検証）は実際にソフトウェアを動かしながら、仕様書通りに作られているかを確認します。開発に関する仕様書は工程ごとに作成されることから、Verificationも同様に開発工程ごとに実施しなければなりません。
Validation（妥当性確認）はソフトウェアを動かすだけでなく、仕様書自体の妥当性もチェックします。ユーザーの要求に沿ったソフトウェアを確認するためには、仕様書の時点でぶれていないかを見直すことも重要です。
仕様書通りに実装することももちろん大事なのですが、同時に仕様書が妥当である=ユーザーの要求を満たすかどうかも大事です。QAに関わる人は常に「Verification & Validation」の視点を持ち、自分たちが正しいものを正しく作っているのかを考えるようにしましょう。
Never, Must, Want
Never、 Must、 Wantの3つは、テスト対象となるソフトウェアに対して、それぞれの視点から分析することが大切です。
Naver（あってはならないこと）は、生命や財産に影響を及ぼすリスクにあたります。病院の電子カルテや銀行の決済システムでは、不具合による障害が致命的になってしまうケースも想定されます。テスト工程ではこのような事態を起こさない、発生しないことを徹底して確認しなければなりません。
Must（できなければならないこと）は、ユーザーが思い通りの要求を達成できるかを検証します。仕様として明記されていることはもちろんのこと、狩野モデルの「当たり前品質」が担保できているかが焦点です。注目される機能のリリース時においては、Mustに該当するものをテストすることが多いでしょう。
Want（できたらよいこと）は、ソフトウェアに求められる要望とも言い換えられます。仕様書通りの動作でも、テスト工程で改善すべき点や、ユーザビリティの改善点に気づくこともあります。
このような情報は次の開発フェーズに役立つ情報となるので、プロダクトマネージャーなど製品に対する要求を管理する役割の人に、エスカレーションすることが重要です。
QAの方法、主なテスト工程の流れ
テストとして一言で表現されるケースもありますが、実際はいくつかの工程ごとに分けられます。工程ごとにQAの方法やテスト手法が異なるため、テストの目線や目的を知ることが、要件に沿ったプロダクトを開発する上では重要です。例として、ウォーターフォール型の開発モデルを例に各テスト工程を解説します。
単体テスト
単体テストの工程では、プログラムの最小単位である「モジュール」ごとにテストを実施します。詳細設計書と同じであることを確認しながら、正常に動作することをテストします。この工程ではコーディング作業に最も近いこともあり、多くの現場では作成したプログラマー自身が担当することが多いでしょう。
結合テスト・機能テスト
単体テストが一通り終了すると、次は結合テストを実施します。この工程では複数のモジュールをつなぎ、モジュール間の連携が正常に動作するかをテストします。
たとえば計算するモジュールAと、処理結果を表示するモジュールBがある場合、それらを連携させて正常に計算結果が表示されるかを確認しなければなりません。データの受け渡しだけでなく、動作する順番やタイミングもテストの対象となるでしょう。
複数モジュールをつなぐ機能テストでは、連携した上で1つの機能としてテストします。内部的な構造というより、役割として果たしているかが重要です。本来の機能として動作するかがポイントになるため、機能テストの一部として結合テストが行われることもめずらしくありません。
システムテスト
結合テスト・機能テストが終了すると、次はシステムテストを実施します。システムテストではそれぞれのモジュールおよび機能を統合して、要件定義に基づいた状態としてリリースできる状態に近づけることがミッションです。システム要件や機能間の連携はもとより、リリース後の運用や保守が可能であるかといった目線も、重要なポイントとなります。
QAの主な業務内容
QAの主な業務内容はテスト工程によって異なりますが、機能テストとシステムテストでは主に「テスト計画」「テスト設計」「テストケース作成」「テスト実施」「テスト報告」の5つの工程に分けられます。
テスト計画
テスト計画では工程ごとにテストの目的と役割を明確にして、どのようなテストを実施すればよいのかを検討します。必要となる環境や人員といったリソースやスケジュールについても決めなければなりません。
1.テスト目的の確認
最初に計画されたテスト全体を見て、重点的に確認する品質や、特定の目的を確認します。その上で計画や設計を行うために、テストのアプローチを決めましょう。
テストの範囲（対象や機能）、テストの概要、テストの方法（技法）を定義します。「テスト対象となるプログラムが追加機能であっても、連携する機能についてはすべてテストを実施する」といった目的を明確にしておきましょう。
2.機能一覧表の作成
テスト計画書の定められた範囲で、テストの対象となる機能をすべて洗い出して機能一覧表を作成します。漏れがないようにすべての機能を洗い出すことが重要です。テストの対象になるかといった判断はこの時点では決めず、各機能の動きをおおまかに把握して理解することに努めましょう。
3.テスト観点の抽出
テスト観点の抽出では、テストの切り口を決めておきましょう。「表示される処理結果が正確かを確認する」「入力チェックのルールを確認する」「処理のレスポンスタイムを確認する」といった観点が当てはまります。
この切り口で確認する際、1つの機能だけでは確認できないので、ソフトウェア全体に対してテストしなければなりません。たとえばテストの目的が「商品を購入しやすいかを確認する」であれば、処理結果を確認するのではなく、商品一覧が見やすいか、カートに入っている商品が確認しやすいかといった観点を抽出します。
テスト設計
テスト設計では各工程で実施すべきテストの種類、目的、対象となる機能、技法、入出力をするデータを決めます。必要になるツールやテスト結果の判断基準についても、より具体的にしておきましょう。
1.テスト観点の機能への割り当て
先に洗い出したさまざまな機能に対して、どのような観点でテストを実施するべきかを検討します。すべての機能で確認すべき観点はもちろん、特定の機能でのみ確認しなければならない観点もあるかもしれません。
そこで機能と観点を明記した「テストマップ」を作成して、対象となる機能で確認すべきテストの観点を確認していきます。テストマップで可視化することは、「テスト観点の漏れを防止する」「テスト観点を具体的にイメージできる」「テストの規模や重要度を把握できる」といった多くのメリットがあります。
2.テスト技法の検討と適用
テストマップを作成したら、それぞれの組み合わせごとにテストを設計します。テスト設計ではさまざまなテスト技法の中から、効果的かつ効率的にバグや不具合を検出する方法を選びましょう。
パスワードが8文字以上かつ16文字以下といったポリシーであれば、7文字以下・8から16文字・17文字以上の同値分割法、7・8・9文字目と15・16・17文字目の境界値分析などが挙げられます。
その他の検討事項
理想的なテストのアプローチが実行できればよいのですが、人員や予算が限られていたり、スケジュールに余裕がなかったりと、リソースに問題を抱えているケースが少なくありません。「最低限のリソース」「現実的なスケジュール」「テストの体制と役割」「テストに必要な環境」を考慮した、実現可能なテストのアプローチといった柔軟な対応も大切です。
テストケース作成
テスト開始前の状態から、テストを実施した際の期待値、テストの判定結果を記入するためのドキュメントを準備します。テストを効率的に実施するためにも手順化にしておき、「この機能を実行すると結果はこうなる」といった動作結果を明確にしておきましょう。
テスト実施
作成したテストケースを参照しながら、実際にソフトウェアを動作させてテストを実施します。期待値と異なった結果になった場合は、判定結果に「×」や「NG」などを記入して不具合に関する報告書を作成します。報告書には期待値と異なる結果、不具合の再現手順や再現率、発生条件などを詳しく記載しましょう。
テスト報告
テストケースの結果を集約して、合否判定の基準を満たしているかを判断しなければなりません。主にテストの実施数や消化率、不具合の件数や割合といったデータが評価基準となります。リリース後の懸念事項やリスク、プロジェクトで推奨される事項といった提案などにも役立つ情報です。
QAを行う上で必要なスキル
QAを実施する上で必要となるスキルには、知識や適性だけでなく、実践的な経験なども含めてミッションを達成する能力が求められます。優れたテスト担当者を目指すには、チームにおいてさまざまな視点を持つプレーヤーとしての立ち回りが必要です。複数の技法を用いながら、テストを実行できるスキルは身につけておきましょう。
テストに関する知識
広く用いられている主なテスト技法としては、「同値分割テスト・境界値テスト」「デシジョンテーブルリスト」「状態遷移テスト」「組み合わせテスト」が挙げられます。
・同値分割テスト・境界値テスト
同値分割テストは入力値をグループごとに分割し、グループ内で代表的な入力値を用いてテストをする技法です。このグループは「同値クラス」と呼ばれ、有効同値クラス（システムに受け入れられるデータ）と無効同値クラス（システムに拒否されるデータ）に分類されます。
境界値テストでは、境界となる値とその前後の値に対してテストをする技法です。境界値（最小値や最大値）で多くのバグが発見されれば、境界値の隣（-1や+1）にもバグが存在するケースが少なくありません。
・デシジョンテーブルリスト
デシジョンテーブルリストは、テストの条件と結果の組み合わせをデシジョンテーブルを使って整理し、組み合わせからテストケースを導き出すテスト技法です。
条件によって動作が変わるシステムの場合、複雑な条件と動作を把握して網羅的に実施することは困難ですが、デシジョンテーブルで整理することで、網羅されたテストケースの設計が容易になります。あり得ない組み合わせであれば、不要なテストケースを削除することにも有効です。デシジョンテーブルテストはすべてのテスト工程に適用できます。
・状態遷移テスト
状態遷移テストとは、ある状態から異なる状態に遷移して、ソフトウェアが正しく動作するかを確認するテスト手法です。同一のテストデータを利用した場合、基本的には同じ動作をしますが、システムによっては状態によってまったく違う動作をするものがあります。
たとえば誤ったパスワードを入力すると認証に失敗する画面が表示されますが、一定数を越えるとアカウントがロックされてしまうといったケースです。このようなシステムテストを「状態遷移テスト」といい、状態遷移図や状態遷移表を用いてテストします。
・組み合わせテスト
複数の条件をいくつも組み合わせながら、動作を確認するテスト技法です。1つの条件では発生しないが、とある条件が組み合わさった場合には不具合が発生する、というケースにおいて有効なテストです。
たとえばパソコンのブラウザでは正常に表示されるが、スマートフォンのブラウザでは表示されない不具合があるとします。この場合はデバイスとブラウザの条件を組み合わせたことで判明した事象であり、組み合わせテストが有効であるといえます。
これらを体系的に学習する目的として、テスト技術者を認定する資格の取得も有効です。一般的に広く知られている「JSTQB認定テスト技術者資格」は、世界的なテスト技術者認定組織であるISTQB（International Software Testing Qualifications Board）の日本版であり、テストエンジニア向けとしてメジャーな認定資格です。
基礎となる「Foundation Level」から、応用を問われる「Advanced Level」に分かれています。Advanced Levelではさらにマネジメントを問われるテストマネージャと、分析スキルを問われるテストアナリストの2種類が存在しています。
Foundation Level試験
・出題範囲：「ISTQBテスト技術者資格制度Foundation Levelシラバス」に準拠する。
・試験時間：60分
・合格率：約50%〜70%
Advanced Level試験
・出題範囲：「ISTQBテスト技術者資格制度Advanced Levelシラバス」および
「ISTQBテスト技術者資格制度Foundation Levelシラバス」に準拠する。
・試験時間：180分（テストマネージャ試験）
120分（テストアナリスト試験）
・合格率：いずれも約16%～18%
プロダクト理解やドメイン知識
テストを行いながらも、「機能としてどうあるべきか」「ユーザーにどのような価値を提供するべきか」を理解するためには、プロダクトへの理解やドメイン（業界や事業について）の知識が必要になります。
「検索結果に表示されている項目には、業務で必要な情報が表示されているか」「検索項目にないが運用では必要か」といった目線も大切です。
仕様書通りの動作であったとしても、ユーザーにとって使いにくい機能であれば、リリース後に不満が出ることも予想されます。このような視点があるのとないのでは、テスト工程における期待値が大きく変わることでしょう。
細部にこだわる意識
不具合や欠陥を見逃さないためには、システムの細部まで徹底してテストする意識を持ちましょう。テストケースに記載されていなくても、「別の手順で操作した場合も正常に動作するだろうか」という経験値からの予測や、「ユーザーが操作するときは別の手順になるのではないか」という意識を持ちながらテストに取り組まなければなりません。
優れたコミュニケーションスキル
ステークホルダーと効果的にやりとりできる、優れたコミュニケーションスキルもQAには求められます。テストケースの確認や不具合が発生した際は、メンバーのQAエンジニアやプロジェクトマネージャへの相談、報告が必要です。事象を理解してもらったり、議論したりするためにも、テストにおけるコミュニケーションスキルは必須です。
分析的思考・批判的思考・創造性
テストケースやテスト結果に対する、分析的思考や批判的思考といった創造性を持つことも大切です。テスト対象となる機能の前提条件から疑うことは、テストケースの手順誤りやテスト設計の漏れを防止します。致命的な不具合を検出するためのテストを、抜けや漏れなく実施するためも必要なスキルです。
エンジニアリングに関する知識
エンジニアリング知識を必要としないテスト自動化ツールが普及しつつありますが、ツールを使いこなすためにはある程度のエンジニアリング知識が必要とされる場合があります。
条件によってツールの動きを変えたい、ケースによってツールの確認項目を振り分けたい、一定回数で繰り返しテストをしたいなど、細かい自動テストする際はプログラミングと同じロジックで設定しなければなりません。
アジャイル開発におけるQAの変化
アジャイル開発の流れ
多くの開発現場で導入されているアジャイル開発では、イテレーション（反復）と呼ばれる用語が重要なキーワードです。短期間で要求分析からリリース可能の成果物を作成するまでを、以下の流れで何度も繰り返して精度や機能の向上を図ります。
1．リリース計画の立案
開発全体のプロセスにおいて、どのように進めていくかリリース計画の立案を定めます。イテレーションの期間や作成する機能、イテレーション自体のタイミング、最終リリースの時期などを決めておきます。
2．ユーザーストーリーの基準作成
次にユーザーストーリー（ユーザーの要求事項）と、受け入れ基準（合格基準や品質目標）をあらかじめ検討します。これらはイテレーションが走り出す前に、可能な限り洗い出しておきましょう。また、イテレーションの合間であっても、機能の追加や変更、ユーザーストーリーを深く掘り下げることがあります。
3．イテレーション計画の立案と実行
ユーザーストーリーを洗い出したら、さっそくイテレーションを実行します。1回のイテレーションにおいて、どのユーザーストーリーに対応してリリースするかを決めておきます。
2回目以降であれば、残課題や仕様変更にも対応するかを判断しておきましょう。イテレーション計画が策定されたら、受入れ基準をクリアできるように開発を進めます。
イテレーション1回あたりが数週間など短い期間で、リリース可能の状態まで進めることが重要です。開発途中であったとしても、動作する機能としてユーザーテストまで完了すれば、ひとつのイテレーションが終了したことになります。
4．イテレーションの繰り返し
イテレーションを繰り返すことで少しずつ機能が拡張され、ユーザーストーリーをすべて網羅した時点で最終的に完成となります。状況次第ではありますが、アジャイル開発においてもウォーターフォールモデルで利用されるシステムテストや受入れテストを用いるケースもあることを覚えておきましょう。
アジャイルとウォーターフォールの違い
ウォーターフォールモデルでは、要件定義の後に外部設計から詳細設計へと各フェーズをすべて終了させてから次に進みます。一方のアジャイル開発ではイテレーションごとに開発を進め、プロダクトを作り上げていく点が大きな違いです。
このように要求のまとめ方や開発の進め方は異なりますが、テスト計画やテスト設計に大きな違いはありません。ユーザーの立場で考えたときに、どのような進め方であっても要求を満たしたシステムを利用できることが大切です。どちらにおいてもテスト設計は不可欠であり、漏れなく確認することが重要になります。
テストの自動化による工数削減
アジャイル開発においてはイテレーションの期間が短いこともあり、テスト仕様などをドキュメントに残さないケースがほとんどです。不要なテストケースを何度も繰り返さないためにも、単体テストではテスト自動化ツールを活用しましょう。
先に述べた同値分割や境界値分割はもちろん、回帰テストについてもテスト自動化ツールは有効的です。イテレーションを繰り返すと手動での回帰テストは困難になりますが、同じ手順を繰り返し実施する点は自動化に最適といえるでしょう。アジャイル開発においてはテスト自動化ツールの導入がもはや必須となり、多くの開発現場で急速に普及しています。
Autifyではテスト自動化の価値を最大限に発揮するケースをまとめた「テスト自動化が真価を発揮するケース3選」という資料もご用意しておりますので、是非こちらもご確認ください。
まとめ
システムでのQAにおける品質管理の概念や取り組み方、テスト技法から求められるスキル、開発現場におけるテスト事情について解説しました。
アジャイル開発の普及が進むにつれて、テスト工程においても品質レベルの担保と工数の短縮化が求められるようになりました。一定の品質レベルを担保しながらも迅速なテストを実施するためには、テスト自動化ツールの活用が最も効率的といえます。
どの立場においても、テスト担当者としての視点や知識が必要不可欠です。エンジニアのポジションに問わず、常にユーザーファーストのQAを追及することが、ユーザー満足度の向上に貢献することでしょう。
.jpg)
.jpg)
