完成した品質保証テスト–ユーザーフローチュートリアル

製品とサービスの展開がますます速くなるにつれて、品質保証（QA）は進化する環境に適応する必要があり、場合によっては短期間で同じレベルのカバレッジを達成する必要があります。 品質よりも量の間違いをどのように回避しますか？ どうすればより多くのことをカバーし、効率を高め、それでも私たちの仕事に効果的でしょうか？

テストケースの作成には長い時間がかかることは誰もが知っています。 さまざまな手法、テストタイプを適用し、前提条件、手順、および期待される結果を文書化する必要があります。 さらに、テスト計画を作成する必要があります。

品質保証スペシャリストは、特にQAプロセスのすべてのフェーズを実行しようとすると、時間切れになることがよくあります。 最大の頭痛の種は、テストの計画と設計の段階であり、テストケースの作成とテストのドキュメントを中心に展開します。 すべての作業を完了するには数時間、場合によっては数日かかる場合があり、通常、特定の成果物をスキップして要約し、テストを忘れる可能性のある重要な情報を除外することを選択します。 その結果、知識共有のメリットも失われます。

従来のQAテストがユーザーフローに適合

私は従来のテストケースとテストプランの大ファンです。 それらは、大量のテストケースを特定するのに役立つだけでなく、製品を非常によく文書化するのにも役立ちます。 トレーニングで使用でき、チームの誰もがそれらを理解します。 誰かがテストを開始するために、経験に過度に依存する必要はありません。 テスト計画には、範囲、テスト項目、テストしている機能、およびテストしていない機能の詳細などの詳細情報が含まれています。 テスト計画に含まれるリスク分析もあります。 これらは利点のほんの一部ですが、多くの場合、全体的な時間が長すぎます。

テスト計画の目的は、プロジェクトの利害関係者間のコミュニケーションと合意の方法です。 これは、製品をテストするための目的、必要なリソース、およびアプローチや戦略を詳しく説明するのに役立ちます。 この計画は、すべてが考えられていることを確認するのに役立ち、品質保証プロセスが戦略的に投資されているという自信を利害関係者に提供します。 この計画は10ページの長さでなければならないという具体的な規則はありません。 ペースの速いチームに合うように再定義できます。

別の方法は、従来のテストケースとテスト計画を合理化して、必要な時間の投資を削減する一方で、すべての利害関係者にとって意味のあるカバレッジとドキュメントを提供することです。 これには、信頼できる唯一の情報源、ひねりを加えたユーザーフローが含まれます。 ユーザーフローを構造化して維持することにより、テストケースの設計の大部分がすでに完了していることになります。 これは、あらゆる製品やチームに適用でき、詳細と構造の点で用途が広いです。

フロー方式を使用すると、テストドキュメントを使用して所要時間を短縮できます。 これは、手動QAだけでなく、自動化にも使用できます。 フローは、テスト計画の一部のセクションにも寄与する可能性があります。

流れに乗る

さらに遅れることなく、簡単なメッセージングWebサイトのユーザーフローの構築に飛び込みましょう。

まず、フリーマインドマッピングツールが必要になります。 私は個人的にXMindを使用しています。 使い慣れたツールをダウンロードしてください。フロー図の描画、一部のトピックへの「メモ」の追加、さまざまな条件の色付け、ラベルの使用などの基本的な機能のみを使用します。

私たちの最初のステップは、製品を理解することです。 通常、モックアップ画像またはワイヤーフレームを参照します。 これらのいずれも利用できない場合は、開発者との迅速なキャッチアップコールにより、期待する画面が正確に得られます。 進んでいくにつれて、気軽にフォローして練習してください。 フローはユーザーインターフェイスに限定されるだけでなく、APIからAPIへの呼び出し、データベースダイアグラム、依存関係構造などをマップするためにも使用できます。 同じ原則が適用されます。

条件、状態、アクション

3人のアクターのみを使用してフローを制限します。 条件があります。これは、特定の役割を持つユーザー、クリアされたキャッシュ、または初めてログインするユーザーのようなものです。 次に、ホームページやサインインウィンドウなどの実際のGUIコンポーネントであるState/Pageがあります。 次はアクションです。これは、状態を変化させる物理的なユーザー操作です。 これを実際に見てみましょう。

要件の分析

これが私たちのホームページであり、州です。 2つの可能なアクションがあります：登録とログイン。

次に、別の状態である[サインイン]ウィンドウがあります。 ここでのアクションは、戻るとログインです。 入力フィールドをアクションとして分類しないことに注意してください。 これを行うことは大歓迎です。 私の経験では、10分の数の深さで動作する複雑なシステムで作業する場合、保守が少し難しくなることがわかりましたが、単純なアプリケーションの場合は最適です。

最後に、ユーザーが正常にサインインしたときに表示されるダッシュボードに移動します。ここでは、メッセージの作成、編集、または削除の3つのアクションがあります。

これで、ユーザーフローを開始するのに十分な情報が得られました。 私たちが持っているものを要約しましょう。 製品の状態を書き留めます。 私たちが見ることができるものから、4つのページがあります：

1. ホームページ
2. ログインウィンドウ
3. レジスタウィンドウ
4. ダッシュボード

以下と「相互作用」できる各ページ/状態のアクションを書き留めます。

1. ホームページ
   1. ログイン
   2. 登録
2. ログインウィンドウ
   1. サインイン
   2. キャンセル
3. レジスタウィンドウ
   1. 未定（製品によって異なります）
4. ダッシュボード
   1. 作成
   2. 編集
   3. 消去

まず、環境に合わせて変更できる製品名から始めますが、これはほとんどのチームとその製品に適合し、出発点としても適しています。 以下に、 Registerの横に疑問符があります。

多くの場合、まだスコープに含まれていないか、将来のリリースが計画されていないアジャイルのコンポーネントに出くわします。 その存在に注意してください、しかし私達がより多くの情報を得るまでそれを未知のままにしておいてください。

フロー図の作成

XMindで上記を次のように引き出します。

状態とは何か、アクションとは何かを単に色分けしていることに気付くでしょう。 また、そのフローを正確に表すために、キャンセルアクションからホームページに行を追加しました。 また、ユーザーが「ログイン」を選択すると、2つの条件が表示されます。 両方ともダッシュボードに移動しますが、それでも両方の可能な条件をテストする必要があります。

XMindの優れた点は、大規模で複雑なアプリケーションで作業する場合、ダイアグラムのさまざまなレベルを作成できることです。したがって、フローを複数のフローに分割し、それらをリンクしたままにしたい場合は、リンクを使用すると非常に簡単です。シートを分けるためのトピック。 ハイパーリンクの挿入を選択でき、ウィザードのポップアップから、アクションがつながる「状態」を選択できます。 つまり、XMindで[ログイン]を選択し、[ダッシュボード]にハイパーリンクすると、別のシートにある場合でも、マウスカーソルが[ダッシュボード]にジャンプします。 かなりクール。

フローに欠けているのはラベルです。 フローのルートである0のラベルを製品に付けます。 次に、状態（青）ごとにS＃ラベルを追加し、アクション（緑）ごとにA＃ラベルを追加し、最後に条件（シアン）ごとにC＃ラベルを追加します。 各ラベルは一意である必要があります。 最終的には次のようになります。

最後に使用した番号を追跡するために（製品が大きくなるにつれて、最大の番号を見つけるのは難しい場合があるため）、以下のように、これをフローのルートトピックに保存します。

ここで、テストケースの作成の部分に行き着きます。 期待される結果に焦点を当てます。これは、テストケースでおそらく最も重要な情報であり、機能の受け入れ基準の一部です。 各セクションまたはテストにタイトルを追加し、その下に期待される結果をリストします。 この記事を簡潔にするために、サブセットに対してのみこれを行います。

次に、ログインウィンドウ：

次に、サインインアクション：

それは本当に形になっています。 追加された境界テストとセキュリティテストに注意してください。 タグを付けるのが最も簡単な方で、好きなようにタイトルを付けることができます。 タイトルにセキュリティ– JSインジェクト–メールフィールドなどのテストタイプのタグを付けて、期待される結果を以下にリストすることがあります。

ほとんどのチームでは、要件の変更を維持するのが面倒です。 もういや。 すべての初めてのユーザーにはTsおよびCsウィンドウが表示され、ダッシュボードに進む前に受け入れる必要があることを学習したとしましょう。問題ありません。 以下のように、状態とアクションを比較的簡単に追加できます。

これで、新しい状態を追加した場合の影響がわかります。 番号付けは最初は奇妙かもしれませんが、私たちが覚えている限り、番号はデータベースの主キーのように、各アクターを一意に識別するためだけのものであることに注意してください。 使用した番号を追跡するために、「最後に使用した」メモを更新することを忘れないでください。

フローからのテストケースの作成

このすべての進歩の後、私たちは今、より簡単な部分、つまりテストケースの作成に取り掛かります。 重要なポイントをいくつか強調しておきます。 すべての俳優のラベルがあり、すべてのテストのタイトルがあり、フローの一部として条件が埋め込まれているすべてのテストの結果を期待しています。 これはテストケースのレシピのように聞こえますが、同意しませんか？

現在行っているのは、フローにあるものをコピーして、テストケース管理ツール、Confluenceサイト、またはExcelドキュメントに貼り付けることだけです。 私は今でも古き良き信頼できるExcelを使用しています。 私はすべてのテストケースの記録を「ベースライン」と呼ばれる1つのファイルに保存しています。これは非常に独創的です。 コピー貼り付けが完了すると、次のようになります。

必要に応じて、テストタイプ、テストステータス、およびテスト構成の列を自由に追加してください。 条件は「サインイン」アクションの前に配置する方が適切な場合がありますが、それを行う正しい方法も間違った方法もありません。個人的な好みと、自分自身を整理する方法に依存します。

強調すべきことがいくつかあります。 1つは、同じ情報を共有するセルをマージしたことです。繰り返しコピーアンドペーストする必要がなく、時間が無駄になり、保守がより困難になります。 もう1つの項目はステップです。 2つのテストには、状態番号とアクション番号を組み込んだステップがあることに気付くでしょう。 これは、チームにSDLCの一部としてフローがある場合に使用できます。 その後、すべての利害関係者は、情報の提供、モックアップ、リスクの引き上げなどによってフローに貢献します。つまり、フロー番号を記載することで、チームの誰もが何をすべきかを知ることができ、新しいチームメンバーがいる場合も同様に簡単です。 「トレイルをたどり、メモを参照してください。」

これは自動化にも役立ちます。 各ステップまたはアクションに一意の参照を与えることができます。 フローのように構造化された自動化パックを作成することで、構築できる自動化フレームワークが、アプリ全体で非常に堅牢で、モジュール式で、互換性がある可能性があることがわかります。 より大規模なページングオブジェクトを利用するため、メンテナンス時間が短縮され、テスト機能を新しいものに交換できます。

フローは、技術仕様、機能仕様、テストケース、状態遷移、データフローなど、すべての製品ドキュメントの信頼できる唯一の情報源になります。

合理化されたテスト計画アプローチ

では、テスト計画についてはどうでしょうか？、あなたは考えているに違いありません。 これは簡単です。 テストプランには、次のようなセクションが含まれています。

1. はじめにと範囲
2. テスト項目
3. テストする機能
4. テストされない機能
5. 仮定
6. エントリー基準
7. 終了基準
8. WBS
9. リスク
10. 環境要件

イントロダクションとスコープは、JIRAストーリー、または別のツールのタスクまたはストーリーになります。 テスト項目は、環境に現在デプロイされているソフトウェアバージョンまたはコミット番号であり、JIRAチケットにリンクしたり、Confluenceまたはテスト管理ツールでテストを実行したりできます。

テストする機能とテストしない機能は、実際にはテストケースです。 このJIRAストーリーで実行するために選択されたテストケースは「テストされる機能」であり、リストされていないものはすべて「テストされない機能」です。 簡単に言うと、ストーリーチケットでテストする状態とアクションをリストします。

前提条件、リスク、さらには環境要件をドキュメントにまとめたり、JIRAのコメントに追加したり、Confluenceに配置してストーリーにリンクしたりすることもできます。

WBSは、プロジェクトに応じて、ストーリーポイントまたは時間の観点からストーリーに割り当てる見積もりです。 入場と退場の基準はすでにストーリーの一部になっています。

「従来の」テスト計画に近づきたい場合は、開発者またはその他の利害関係者に、QA計画に同意するかどうかを確認するために、「はい」または「いいえ」でストーリーにコメントするよう依頼できます。 これは技術的にはデジタル署名として機能します。 これらすべてをQAプロセスに簡単に含めることができ、QAドキュメントを合理化するのに役立ちます。

私たちは何を学びましたか？

上記のアプローチと今日利用可能なツールを使用するために合理化されたテスト計画によるユーザーフローは、反復作業を減らし、品質を犠牲にすることなくQAがより速いターンアラウンドタイムを達成するのに役立ちます。

このアプローチは、組織を維持し、すべての基礎をカバーし、チーム全体が理解できるドキュメントを作成するために役立ちました。 アジャイルでは、これは本当に便利です。その最良の部分は、アジャイルアプローチの1つである「ドキュメントの簡素化」を引き続き順守していることです。

この情報がお役に立てば幸いです。 読者はあなた次第です。 これは従うべき具体的なルールのセットではありません。これらは、成長して効率を向上させるためのアイデアを提供するためのガイドラインにすぎません。 すべてのプロジェクト、チーム、または製品に適合する技術はありませんが、別の革新的なアイデアへの道を開く可能性があります。