QA ドキュメントとは何ですか?その作成と保守のコストを削減するにはどうすればよいですか?

公開: 2023-08-01

ITRex の QA チームリードである Andrii Hilov は、ソフトウェアプロジェクトにおける品質保証の課題と落とし穴について論じた別の記事を執筆しました。今回、Andrii は、QA ドキュメントと、予定どおり、予算内で、ビジネス目標に沿った高性能ソフトウェアの開発において QA ドキュメントが果たす役割について詳しく掘り下げます。

これについて彼は次のように述べています。

エンタープライズソフトウェア開発会社 ITRex の QA チームリードとして、私はソフトウェア開発コストを削減しながら、完全に機能する製品を予定どおりに最大の価値でリリースしたいというクライアントの願望をよく理解しています。

これらの目標は理解できますが、たとえ毎日バグが見つからなかったとしても、プロジェクトの早い段階で QA チームを解雇しないことをお勧めします。ただし、これは給与を削減し、ソフトウェアのリリースサイクルを早めるための簡単な選択肢のように思えるかもしれません。

また、プロジェクト全体を通じて品質保証のベストプラクティスに従って、ソリューションとそのすべての機能が期待どおりに機能し、サイバーセキュリティを侵害しないことを検証することをお勧めします。

そのような実践の 1 つは、適切な QA ドキュメントを作成して維持することです。

品質保証文書とは正確には何ですか? QA およびテストサービスを利用することで最大限のメリットを得るにはどうすればよいでしょうか? また、設計が不十分でバグだらけのアプリケーションを開発し、全体をゼロから再構築する必要があるリスクを最小限に抑えながら、QA ドキュメントの準備に関連するコストと労力を最適化する方法はあるのでしょうか?

確認してみましょう！

QAドキュメントの紹介

QA ドキュメントは、ソフトウェアの開発およびテストのプロセス中に品質保証チームによって作成および維持されるドキュメントと成果物のコレクションです。

これには、テスト戦略、テスト計画、テストケース、テストスクリプト、テストデータ、テストログ、バグレポート、および QA 活動に関連するその他の文書の概要を説明するさまざまな文書が含まれる場合があります。これらのドキュメントは、QA チームのメンバー間のコミュニケーションを促進し、テストのガイドラインを提供し、問題を効率的に特定して解決するのに役立ちます。

したがって、QA ドキュメントはソフトウェア製品の品質と信頼性を確保する上で重要な役割を果たしており、それが当社のクライアントが追求する主要な目的です。

ソフトウェアプロジェクトで使用される QA ドキュメント

この記事の目的として、ソフトウェア開発プロジェクトにおけるテスト文書の根幹をなす品質保証文書の概要を説明します。

テスト計画は、ソフトウェアテスト活動の全体的なアプローチ、目標、範囲、リソース、スケジュールの概要を説明する QA 文書です。簡単に言うと、以下の内容がカバーされます。

プロジェクトの名前と説明（テスト中のアプリの種類とそのコア機能を含む）
推奨されるテスト方法 (手動、自動、混合) とテストの種類 (新機能、統合、互換性、回帰など)
テストする必要がある機能と、各テスト活動のおおよそのスケジュール
最適なチーム構成
テストプロセス中に発生する可能性のあるリスクと問題の概要
プロジェクト中に QA チームが使用するテスト文書のリスト

経験則では、IT チームがソフトウェアソリューションの機能要件と非機能要件を定義し、適切なテクノロジスタックとプロジェクト管理手法を選択し、プロジェクトロードマップを作成するときに、ソフトウェアプロジェクトの開始時にテスト計画を作成します。

テストケースのない単純なテスト計画を作成してレビューするには、通常、最大 3 日かかります。

テストケースは、入力データ、期待される結果、実行手順など、特定のテストシナリオを記述します。テストケースは、ソフトウェア製品の機能、パフォーマンス、またはその他の側面を検証するために設計されています。テストケースは、手動テストサービスと QA 自動化サービスチームの両方で使用されることに注意してください。こうすることで、テストカバレッジを最大限に確保でき、運用コードにバグが現れなくなります。

たとえ熟練した QA エンジニアが高レベルのテストケースをわずか 10 分で作成できたとしても、中規模のプロジェクトのテストケースの数は 4,000 を軽く超える可能性があります (そしてさらに増え続けています)。 この数字に中級 QA エンジニアの平均時給(北米市場では人時あたり 65 ドル) を掛けると、素晴らしい数字が得られます。

チェックリストは、テストプロセス中に完了または検証する必要があるアクションまたはタスクを項目別にまとめた簡潔なリストです。したがって、QA ドキュメントのチェックリストには通常、QA チームの注意を必要とするアプリまたはサイバー物理システムの機能モジュール、セクション、ページ、その他の要素の完全な概要が含まれています。

小規模なプロジェクトでは、チェックリストを詳細なテストケースに置き換えることができます (これについては後で詳しく説明します)。

テストスクリプトは、 Selenium、Appium、Cucumber などの特定のテストツールまたはフレームワークを使用して記述されたコードの塊です。これらのスクリプトはテストケースの実行を自動化し、テストプロセスをより効率的にします。特に、頻繁に更新され、小さなバグでもユーザーエクスペリエンスに悪影響を与える可能性がある、マルチテナント SaaS システムや人気のある B2C アプリなどの大規模で複雑なソフトウェアプロジェクトの場合に当てはまります。。
テストデータは、 QA エンジニアがさまざまな条件下でソフトウェアソリューションのパフォーマンス、機能、信頼性、セキュリティを評価するために使用するデータです。これには、サンプル入力値、境界条件、およびさまざまなシナリオが含まれる場合があります。たとえば、QA チームは、ソフトウェアシステムへのアクセスに正しいログイン資格情報のみが使用できることを検証するために、肯定的なテストデータと否定的なテストデータを使用する場合があります。同様に、テストデータは、特定の種類のアプリに年齢制限を実装したり、増加したワークロードをアプリケーションがどのように処理するかを調査したりするために使用できます。
テストログには、テスト実行の日時、実行されたテストケースの概要、QA チームが達成した結果、スクリーンショット、テスト中に指摘された問題や観察結果など、テスト実行プロセスが記録されます。テストログは、テストの進行状況を追跡し、テスト結果のパターンや傾向を特定し、テスト活動の履歴記録を提供するための重要な情報源です。これは問題を効率的に特定して解決するのに役立ち、将来のテスト作業や監査の参考として役立ちます。
欠陥またはバグレポートは、 QA 活動中に見つかった欠陥や問題を詳しく説明するテスト文書です。具体的には、検出されたバグ、その重大度と優先度、欠陥が発生する条件について説明します。 QA マネージャーはバグレポートを使用して、ソフトウェアテストのスペシャリストにタスクを割り当て、そのステータスを追跡します。
トレーサビリティマトリックスは、テストケースと要件またはその他の成果物との関係をマッピングします。これにより、すべての要件がテストケースで適切にカバーされていることを確認し、プロジェクト全体でテストカバレッジを追跡できるようになり、冗長なテストアクティビティが排除されます。
テスト完了レポートには、テストの実行ステータス、実行されたテストケースの数、見つかった欠陥、保留中のタスクなど、プロジェクトで実行されたテストアクティビティが要約されます。

QA ドキュメントが重要なのはなぜですか?

品質保証ドキュメントがあれば、顧客とソフトウェアエンジニアリングチームが期待する正確な結果を達成するのに役立ちます。

これは、次のような要因の組み合わせによって実現されます。

QA ドキュメントは、ソフトウェアテストのスペシャリストがタスクを一貫して実行するために従うことができる明確な指示とガイドラインを提供し、ばらつきを減らし、製品やサービスの全体的な品質を向上させます。
品質保証文書は、開発プロセスの後半でソフトウェアソリューションの重大な欠陥やエラーが検出される可能性を低減するため、予算管理において極めて重要な役割を果たします。 QA の専門家は、バグ修正のコストはプロジェクトの各段階で指数関数的に増加し、設計/アーキテクチャ段階の 3 倍から展開段階の 30 倍以上に及ぶと示唆しています。
品質保証文書は、監査を簡素化し、確立されたプロセス、手順、および品質管理の証拠を提供することで、組織が満たさなければならない規制要件と基準への準拠を保証するのに役立ちます。
ソフトウェアテストの文書化は、手順、制御、リスク評価プロセスを文書化することで、組織が潜在的なリスクを特定し、ビジネスや顧客満足度への影響を最小限に抑えるための予防措置を講じるのに役立ちます。
新入社員は QA ドキュメントを参照してソフトウェアプロジェクトの品質プロセスと手順を理解できるため、学習曲線が短縮され、組織全体で一貫したトレーニングが確保されます。
不適合、是正措置、学んだ教訓を文書化することで、企業は改善領域を特定し、変更を実施して効率と品質を向上させることができます。
十分に文書化された QA プロセスと手順を用意することで、会社の製品やサービスに対する顧客の信頼を高めることができます。広範なソフトウェアテストに関する文書は、品質への取り組みを実証し、組織が一貫した信頼性の高い結果を提供するための堅牢なシステムを導入していることを保証します。
法的紛争や製品リコールが発生した場合、QA 文書は重要な証拠として役立ちます。これにより、組織が確立された品質プロセスに従い、必要な予防措置を講じ、義務を果たしたことを証明できます。

QAドキュメントの作成にはどのくらい時間がかかりますか?

この質問に対する正直な答えは、「それは状況による」です。

具体的には、期間と関連コストは、組織の規模とそのプロセスの複雑さ、所属する業界、構築しているソフトウェアの種類など、いくつかの要因によって異なります。

以前にソフトウェア開発プロジェクトに着手しており、社内に QA チームがいる場合は、既存の QA ドキュメントを新しいプロジェクトに再利用できる可能性があります。プロジェクト管理や Wiki ソフトウェアなど、ソフトウェアテストのドキュメントを作成および維持するためのテンプレートや専用ツールを使用することも役立ちます。

QA ドキュメントは常に必要ですか?また、その作成とメンテナンスのコストを削減することは可能ですか?

品質保証ドキュメントがどれほど有用であっても、その作成と保守に追加の労力と人員が必要となるため、ソフトウェアプロジェクトのコストが増加する可能性があります。

これは、限られた資金で事業を展開しているスタートアップ企業や、不況下でデジタル変革を進めている企業にとっては問題となる可能性があります。

では、あらゆる種類のソフトウェアプロジェクトに非常に詳細な QA ドキュメントが必要なのでしょうか。また、それに関連するコストを削減することは可能でしょうか?

QA ドキュメント作成の最適なアプローチを決定するには、次の要素を考慮してください。

プロジェクトの規模と予算。低予算の短期プロジェクトの場合 (大規模な IT チームによって実行される非常に革新的で技術的なプロジェクトについて話している場合を除く)、文書化プロセスを過度に複雑にする必要がないため、QA チームは詳細な文書の代わりにチェックリストを選択できます。テストケース。テスト全体の戦略を決めるテスト計画書については、予算がない場合や、最先端の技術を使わない短期プロジェクトの場合は、作成を省略することもできます。
QA チームの規模と経験。プロジェクトに参加する QA エンジニアが増え、品質保証の経験が少なくなるほど、テストプロセスの管理が難しくなります。したがって、チームメンバーが同じ認識を保つためには、広範な品質保証文書が必要です。このような場合、チェックリストではなくテストケースを重視し、経験と知識に基づいてエンジニア間でタスクをより効果的に分散し、通常は時給が高い経験豊富な QA スペシャリストをテストケースの作成に参加させることをお勧めします。
プロジェクト管理に対するアジャイルアプローチとウォーターフォールアプローチ。 ITRex チームはこのブログ投稿でアジャイル手法とウォーターフォール手法の主な違いをまとめていますが、品質保証の点で 2 つのアプローチの違いについても触れておく価値があります。ウォーターフォールでは、ソフトウェアテストは最後に保存されます。つまり、QA チームはコーディング部分が 100% 完了した場合にのみテストを実施します。明らかな理由から、適切な品質保証文書がなければそれを行うことはできません。文書は要件の抽出段階で準備する必要があります。アジャイルでは、IT チームが小さなソフトウェアを繰り返し構築し、各サイクルの最後にコードをテストする傾向があるため、事前に創造的な包括的な QA 文書を作成することは好まれません。それでも、現在の状況を顧客やソフトウェアエンジニアの期待とよりよく一致させるために、テスト計画を作成することをお勧めします。

全体として、QA ドキュメントを用意することは、複雑さや規模に関係なく、あらゆるソフトウェア開発プロジェクトに利益をもたらす可能性があります。

ただし、クライアント志向の企業として、当社はいつでもお客様の目的と予算を考慮した回避策を提案する準備ができています。

プロジェクトに広範な品質保証ドキュメントを準備する必要があるかどうかが不明で、そのタスクを任せられる熟練した QA エンジニアを探している場合は、ITRex にお問い合わせください。私たちは、高性能でバグのないソフトウェアソリューションを予定どおり、予算内で、仕様に沿って確実にリリースできるようにします。

オリジナルは 2023 年 6 月 30 日に https://itrexgroup.com で公開されました。