how review srs document
これは私たちの2番目のチュートリアルです 「ライブプロジェクトでの無料のオンラインソフトウェアテストトレーニング」 シリーズ。ここが初めての場合は、最初の紹介チュートリアルを確認してください。 ライブプロジェクトでのエンドツーエンドのソフトウェアテストトレーニング。
ここで、SRSウォークスルーがどのように発生するか、このステップから何を特定する必要があるか、開始する前にどのような事前ステップを実行する必要があるか、どのような課題に直面する可能性があるかなどの詳細な分析に取り掛かりましょう。詳細な方法。
SDLCの設計フェーズ:
SDLCの次のフェーズは「設計」です。これは、機能要件が技術的な詳細に変換される場所です。このステップには、開発、設計、環境、およびデータの各チームが関与します。このステップの結果は、通常、技術設計ドキュメント-TDDです。
入力は、TDDの作成とQAチームがプロジェクトのQAの側面に取り組み始めるためのSRSドキュメントです。これは、SRSを確認し、テストの目的を特定することです。
学習内容:
SRSレビューとは何ですか?
SRSは、開発チームがビジネスアナリストおよび環境/データチームと協力して作成するドキュメントです。通常、完成したこのドキュメントは、詳細なウォークスルーが手配される会議を通じてQAチームと共有されます。
場合によっては、既存のアプリケーションの場合、正式な会議やこのドキュメントを案内してくれる人が必要ないことがあります。これを自分で行うために必要な情報があるかもしれません。
SRSレビューは、機能要件仕様書を調べて、ターゲットアプリケーションがどのようになるかを理解しようとすることに他なりません。
正式なフォーマットとサンプルは、前回の記事で皆さんと共有されました。すべてのSRSがそのように正確に文書化されることを必ずしも意味するわけではありません。常に、 フォームはコンテンツの二次的なものです 。
箇条書きを作成することを選択するチームもあれば、ユースケースを含めるチームもあれば、サンプルのスクリーンショット(私たちが持っていたドキュメントなど)を含めるチームもあれば、段落で詳細を説明するチームもあります。
ソフトウェア要件仕様レビューの前段階
ステップ1) ドキュメントは複数の改訂を経ているため、参照されているドキュメントの正しいバージョンであるSRSがあることを確認してください。
ステップ2) 各チームメンバーからのレビューの最後に何が期待されるかについてのガイドラインを確立します。言い換えると、このステップから期待される成果物を決定します。通常、このステップの出力は、テストシナリオを特定することです。テストシナリオは、特定の機能について「何をテストするか」を示す1行のポインタにすぎません。
ステップ3) また、この成果物をどのように提示するかについてのガイドラインを確立します。つまり、テンプレートです。
ステップ4) チームの各メンバーがドキュメント全体を処理するのか、それともドキュメントを分割するのかを決定します。特定のチームメンバーに知識が集中するのを防ぐため、全員がすべてを読むことを強くお勧めします。
しかし、SRSドキュメントが1000ページ近く実行されている大規模なプロジェクトの場合、ドキュメントモジュールを賢く分割し、個々のチームメンバーに割り当てるというアプローチが最も実用的です。
ステップ5) SRSレビューは、ソフトウェアのテストに必要な特定の前提条件があるかどうかをよりよく理解するのにも役立ちます。
ステップ#6) 副産物として、一部の機能を理解するのが難しい場合、機能要件にさらに情報を組み込む必要がある場合、またはSRSで間違いがあった場合のクエリのリストが識別されます。
何を始める必要がありますか?
- SRSドキュメントの正しいバージョン
- 誰が何にどれだけの時間を費やすかについての明確な指示。
- テストシナリオを作成するためのテンプレート。
- 質問の場合に誰に連絡するか、または文書の不一致の場合に誰に報告するかに関するその他の情報
誰がこの情報を提供しますか?
チームリーダーは通常、上記のセクションにリストされているすべてのアイテムを提供する責任があります。ただし、この取り組み全体を成功させるには、チームメンバーの意見が常に重要です。
チームリーダーはよく尋ねます-どのような入力ですか?特定のモジュールを、興味のないチームメンバーよりも、興味のある人に割り当てる方がよいのではないでしょうか。チームの意見に基づいて目標日を決めるのは、チームに決定を下すよりもいいのではないでしょうか。また、プロジェクトを成功させるには、テンプレートが重要です。
原則として、テンプレートは、特定のチームの利便性と快適さに合わせて調整すると、効率が高くなります。したがって、チームリーダーは何よりもチームメンバーであることに注意する必要があります。プロジェクトを円滑に実行するには、チームを日々の意思決定に参加させることが重要です。
テストシナリオにはテンプレートが必要ですか?
テストシナリオのテンプレートを作成する理由–リストを作成するだけでは不十分ですか?
確かにそうです。ただし、ソフトウェアプロジェクトは「ワンマン」ショーではありません。彼らは関与します チームワーク 。
4人のチームを想像してみてください。各チームが、ソフトウェア要件仕様の1つのモジュールをそれぞれレビューすることにした場合。チームメンバーAが1枚の紙にリストを作成しました。チームメンバー2はExcelシートを使用しました。チームメンバー3はメモ帳を使用しました。チームメンバー4は単語docを使用しました。 1日の終わりに、プロジェクトで行われたすべての作業をどのように統合しますか?
また、最初に、どちらが標準であるかをどのように判断し、ルールを作成しなかった場合に何が正しく、何が正しくないかをどのように判断できるでしょうか。
それがテンプレートです。 チーム全体の統一性と同意のための一連のガイドラインと合意された形式。
QAテストシナリオのテンプレートを作成するにはどうすればよいですか?
テンプレート 複雑で柔軟性がない必要はありません。
必要なのは、有用なテスト成果物を作成するための効率的なメカニズムだけです。 以下に示すような単純なもの:
このテンプレートのヘッダーには、プロジェクト、現在のドキュメント、および参照されているドキュメントに関する基本情報をキャプチャするために必要なスペースが含まれています。
以下の表では、テストシナリオを作成できます。含まれている列は次のとおりです。
列#1)テストシナリオID
テストプロセスのすべてのエンティティは、一意に識別できる必要があります。したがって、すべてのテストシナリオにIDを割り当てる必要があります。このIDを割り当てる際に従うべきルールを定義する必要があります。
この記事のために、次のように命名規則に従います。 TS (テストシナリオを表すプレフィックス)の後に「_」、モジュール名が続く ME (Orange HRMプロジェクトのMy Infoモジュール)、「_」、サブセクション( 例えば、 ME 私の情報モジュールの場合、 P 写真などの場合)シリアル番号が続きます。例:「TS_MI_MIM_01」。
列#2)要件
テストシナリオを作成するときに、それを選択したSRSドキュメントのセクションにマップして戻すことができるはずです。要件にIDがある場合は、それを使用できます。そうでない場合は、テスト可能な要件を特定したSRSドキュメントのセクション番号またはページ番号で十分です。
列#3)テストシナリオの説明
「何をテストするか」を指定するワンライナー。これをテスト目標とも呼びます。
列#4)重要性
これは、特定の機能がAUTにとってどれほど重要であるかについてのアイデアを提供するためです。このフィールドには、高、中、低などの値を割り当てることができます。 1-5のようなポイントシステムを選択することもできます。5が最も重要で、1はそれほど重要ではありません。このフィールドが取ることができる値が何であれ、それは事前に決定されなければなりません。
列#5)テストケースの数
その1つのテストシナリオを作成することになる可能性のある個々のテストケースの数の概算。 例えば、 ログインをテストするために、次の状況が含まれます。正しいユーザー名とパスワード。正しいユーザー名と間違ったパスワード。正しいパスワードと間違ったユーザー名。したがって、ログイン機能を検証すると、3つのテストケースが発生します。
注意: このテンプレートを展開するか、必要に応じてフィールドを削除できます。
例えば 、ヘッダーに「Reviewed by」を追加したり、作成日などを削除したりできます。また、テーブルに「Created by」フィールドを含めて、特定のテストシナリオを担当するテスターを指定したり、「No。テストケースの」列。選択はあなた次第です。チーム全体に最適なものを選択してください。
Orange HRM SRSドキュメントを確認して、テストシナリオを作成しましょう。
プロのヒント: 最初のチュートリアルで提供したSRSサンプルの目次を確認して、ドキュメントがどのように流れるか、およびドキュメントに含まれる可能性のある作業量を把握してください。セクション1 ドキュメントの目的です。テスト可能な要件はありません。
セクション2.1 :プロジェクトの概要-対象者-テスト可能な要件もありません。
無料のアニメはどこで見られますか
セクション2.2 :ハードウェアとホスティング-このセクションでは、OrangeHRMサイトがどのようにホストされるかについて説明します。さて、この情報は私たちテスターにとって重要ですか?答えは「はい」と「いいえ」です。テストするときは、リアルタイム環境に似た環境が必要だからです。
これにより、それがどのように必要であるかがわかります。いいえ、それはテスト可能な要件ではないためです。テストを行うための一種の前提条件です。
セクション3: ここにログイン画面があり、サイトに入るのに必要なアカウントの種類の詳細があります。これはテスト可能な要件です。したがって、テストシナリオの一部である必要があります。
SRSのいくつかのセクションのテストシナリオが追加されているテストシナリオドキュメントを参照してください。練習のために、同様の方法で残りのシナリオを追加してください。ただし、ドキュメントのセクション4に進みます。
セクション4: 美的/ HTML要件とガイドライン-このセクションでは、SRSレビューの時点で一部の要件がテストチームにとって意味をなさない可能性があることを最もよく説明していますが、チームはそれらをすべて同じようにテスト可能な要件としてメモする必要があります。
それらをテストする方法と、それを検証するために特定のセットアップ/チームの支援が必要な場合は、現時点ではわからない可能性のある詳細です。しかし、それらをテストスコープの一部にすることは、それらを見逃さないようにするための最初のステップです。
OrangeHRMアプリケーションのサンプルテストシナリオ: (クリックすると画像が拡大します)
=> 参照してください テストシナリオドキュメントをダウンロードする 詳細については。
SRSレビューに関するいくつかの重要な所見
#1) 情報を隠さないでください。
#二) 特定の要件が正しいかどうか、またテストできるかどうかについて、実現可能性分析を実行します。
#3) 個別のパフォーマンス/セキュリティまたは他の形式のテストチームが存在しない限り、すべての非機能要件を考慮に入れる必要があることを確認するのが私たちの仕事です。
#4) すべての情報がテスターを対象としているわけではないため、注意すべき点と注意すべきでない点を理解することが重要です。
#5) 重要性といいえ。テストシナリオのテストケースの数は正確である必要はなく、おおよその値を入力することも、空のままにすることもできます。
要約すると、SRSレビューの結果は次のとおりです。
- テストシナリオリスト
- 結果のレビュー–SRSドキュメントを静的に確認/検証することで見つかったドキュメント/要件エラー
- 理解を深めるための質問のリスト-もしあれば
- テスト環境がどのようになるかについての予備的な考え
- テストスコープの特定と、最終的にいくつのテストケースが発生する可能性があるかについての大まかなアイデア、つまり、ドキュメント化と最終的な実行に必要な時間。
注意すべき重要なポイント:
#1) テストシナリオは外部の成果物ではありませんが(ビジネスアナリストや開発チームと共有されていません)、内部のQA消費にとって重要です。これらは、100%のテストカバレッジ目標に向けた最初のステップです。テストシナリオは、完了するとピアレビューを受け、それが完了すると、すべて統合されます。
QAドキュメントのレビュー方法の詳細については、次の記事を確認してください。 6つの簡単なステップでテストドキュメントのレビューを実行する方法。
#二) 次のようなテスト管理ツールを使用できます HP ALM または qTest テストシナリオを作成します。ただし、リアルタイムでのテストシナリオの作成は手動のアクティビティです。私の意見では、手動の方が便利です。ステップ1なので、まだ大きな銃を持ち出す必要はありません。シンプルなExcelシートがそれを実行するための最良の方法です。
このシリーズの次のステップは –テストケースの作成に取り組み、テスト設計フェーズに進みます。その前に、私たちも入ります– テスト計画とは何ですか?QAプロジェクト全体のどこに当てはまりますか?いつものように、最良の結果を得るために私たちと協力してください。
QAトレーニング3日目: SRSドキュメントを最初から作成する方法。
ご質問やご意見をお待ちしております。読者の皆様に感謝いたします。