長い記事を読むのは難しい...複雑な製品のテストは簡単

現代のIT業界では、多くの人がまだ驚いています。「なぜ別のテスト部門が必要なのですか？」

叙情的な紹介

ピーターズバーグの秋とは何ですか？ 雨、ローゼンバウム、憂鬱...それだけですか？！ いいえ、これはまだ新しい学年度であり、わが国の多くの地域で正確にDiary.ruで始まりました。 夏の間、私たちは一定の成功を収めることができました：プロジェクトのユーザー数は700万人を超え、 2014年の世界経済フォーラムテクノロジーパイオニアのリストに含まれる唯一のロシア企業となり、北オセチアアラニア共和国は日記から電子ジャーナルに完全に切り替わりました。る 。 この叙情的な紹介で、私たちはこのポストの本質に終わり、次に進みます。

トピックの紹介

現代のIT業界では、多くの人がまだ驚いています。「なぜ別のテスト部門が必要なのですか？」 私たちのプロジェクトのテストチームの参加者の一人として、私は責任を持って宣言します。これは間違った意見です。 QA部門の編成は簡単ではありませんが、それだけの価値はあります。
この場合、次のことを明確に理解する必要があります。
-品質基準とは何ですか？
-使用するメトリック
-テストするツールは何ですか？
-開発者/アナリストなどとの相互作用を構築する方法

概して、車輪を再発明する価値はありません。これらのプラクティスは何百万ものWebページで説明されており、経験を取り入れることができる多くの企業でうまく使用されています。 しかし、単純な真実を忘れてはなりません-どこにでも特異性があります。 たとえば、Diary.ruでは、これらは強力に相互接続されたコンポーネントとCI（継続的統合）であり、単に関連領域の高レベルの統合です。 この場合の最良のテストは何ですか？
簡単なものから始めましょう。どんな情報でも、あなたの（紛れもなく非常に賢い）頭の中に100％自動的に「ポップアップ」することは決してありません。 まず、QA-shnikovはテストシナリオを記憶して実行する必要があります。テストシナリオは、リリースごとにチェックされますが、「何かが壊れていますか？」 ご存知のとおり-回帰テスト。 しかし、これは種についてではなく、種についてです-protesting.ru（ところで、良いリソース）へようこそ。

そのため、テストケースの作成と保存には（「テストケースとは、テスト対象の機能またはその一部の実装を検証するために必要な一連のステップ、特定の条件、およびパラメーターを記述するアーティファクトです」）、Excel、notepad、google-docs 、結局のところ、紙のシート。 しかし、それは効果的で便利ですか？ 一人用-多分。 プロジェクトのステータスが「昨日わかっているべきだ」というチームにとっては間違いありません。

準備作業

長い間、テストプロセスの完全な管理を可能にする多くの重いテスト管理プログラムがあります。テスト計画、テストサイクル、必要条件、テストケースなどの作業です。 私はさまざまなユーティリティを使用しました-有料、無料、自己作成-お金を浪費しない方が長年の間、高品質のツールを購入するか、チームを雇って「会社にとって理想的なツールであり、あなたが必要です。」
そのため、まず、既存のチェックリストではテストの成功に対処できないことが明らかになりました。 彼らは十分ではありません、彼らはほとんど情報を持っていません、彼らは透明ではありません、彼らに結果を提示することは困難です、彼らは維持することが困難であり、新しいものを書くのに十分な時間がありません。 第二に：この状況では、テスト管理シナリオを効果的に管理できるツールが必要でした。「要件->テストケース->レビュー->テストスイート->テストサイクル->結果」。

上記のすべてを要約すると、ツールの要件は次のとおりでした。

-便利なユーザーインターフェース
-インストール、実装、サポートの容易さ
-テストスクリプトの便利な記述と保存
-JIRAとの連絡
-次のシナリオの効果的な管理：「要件->テストケース->レビュー->テストスイート->テストサイクル->結果」
-1回のテスト実行で実行するさまざまな領域からのテストケースの便利な選択
-テストスイートの立ち上げに関する透過的なレポートの受信が容易
-将来、ツールを自動テストに関連付け、書面による自動テストを開始する機会

だから、考慮されたもの：

-Microsoftテストラボ（ ロシア語での操作方法 ）
- ゼファー
- テストリンク
- 精巣タランチュラ
- テストレール

PS：警告の質問-HP Quality Centerは考慮しませんでした。1）それは不当に高価であるためです。2）特に「テストツールで作業したことがない人にとっては」「フレンドリー」ではなく、 ...

私はいくつかの主要なポイントを満たそうとします。

Microsoftテストラボ

「非常にクールなものがすべて」ではありませんか？ ただし、インストールと実装に一度も遭遇したことがなければ、楽観的な予測は必要ありません。 控えめに言っても、数か月間無料で利用できる場合は、歓迎します。 インストール、設定、素敵なボーナスもあります-ロシア語での方法を完了します。 私たちにとっての主な利点は、ライセンスと自動テストとの通信の簡単なセットアップでした。
合計：実装して使用する方法を習得する時間がありませんでした。

ゼファー

JIRAと統合された、優れた、モダンでカラフルなツール。 そしてまだ-テストサイクルを開始し、テストケースを記述する方法を見ましたか？ 編集用-ステップと結果を追加する別のウィンドウ-行ごとに番号付けされます。 スクリプトを作成して保存するための多くの不要なアクション。
合計：1つのプロジェクトを半年間、慎重にゆっくりとテストケースを実行すると、結果として、すべてが非常に美しく透明になります。 このオプションは私たちには合わなかった。

テストリンク

テスターの仕事で最も基本的なこと-テストケース+テストサイクル-を行うことができる非常にシンプルなツール。 それだけです。 デザイン-Cグレード、利便性-も。 テストリンクを自宅にインストールして、テストケースの入力方法と、合格/ブロック/失敗の設定でテスト実行に合格する方法を学習することができるように思えます。 もちろん、このオプションは悪くなく、さらに無料です。 短所：自動テストでは非自明、テストケースの記述が不完全。
合計：さて、レビューにまかせましょう。

精巣タランチュラ

QAチームで簡単に実装できる無料のフィンランドツールキット。 長所-テストプロセス、テストケース、テストの傷、レポートを制御するのに十分ではありません。 正しい構造：テストケース->テストスイート。 テストケースの「タグ」など、非常に面白い瞬間があります。これにより、必要なセットを見つけることができます（たとえば、これに影響する特定の機能についてのみネガティブテストケースが必要です->すべてのシナリオで最初に設定されます）タグの正しいセット。これにより、個別のテスト実行を簡単に選択できます。 利便性は悪くありません。自動テスト用に設定できます...短所：レポートが不十分で、カスタマイズに問題があり、JIRAに接続されていません。
合計：検討のオプションの1つとして残しましょう。

テストレール

私の意見では-最も簡単ですが、同時に非常に大規模な既存のツールの1つです。 主なプラス-ほとんどすべてでカスタマイズが可能です。 デザインから始まり、ロジックで終わります。 JIRAとの直接統合。 テストケースを効果的に入力し、適切なスイートに分割します。 マイナス面の1つとして、最近まで、テストレールのレポートシステムは実装が不十分でした。テスト実行の結果が悪い、レポートのカスタマイズが不十分などです。 しかし、Gurock＆Coがこの問題を取り上げ、ツールの第3バージョンまでに、彼らはバグの作業を行いました。 レポートは新しい色で再生し始めています：必要に応じて-マイルストーンのレポート、必要に応じて-欠陥のみ、必要に応じて-厳密に定義された機能のテストに関するレポートを含む通常の電子メールを設定します。 よくやった！ 結論-このツールは、私の要件のすべて（！）を満たしています。

合計：テストレールの導入です。 実際、Test Railとは何ですか？

•これは、テストケース、計画、テストサイクルの効果的な管理です（テストスクリプトの作成/保存/編集、テスト計画の管理、テストサイクルの起動、テスト結果の記録）
•これにより、テストの品質が大幅に向上します（テストシナリオの明確な説明、レビュー、要件との相関、領域への分割-これにより、機能テストによるカバレッジの完全性を評価でき、プロジェクトチーム全体に必要な資料です）
•これは、リアルタイムのテスト結果を取得しています（完全に異なる基準でレポートを作成します：欠陥の要約、ケースの比較、プロジェクト/コンポーネント/マイルストーンのテスト結果など）。
•これは簡単な組織であり、テスト部門のワークロードを簡単に追跡できます（「作業ダッシュボード」を完全にカスタマイズする機会、およびQA部門のステータスを取得するのに便利です）

実装

1. MSSQLベースのWindows Server 2008 R2仮想マシンにTestRailを配置します
2. AD認証をセットアップする
3. JIRAとの本格的な接続をセットアップする

最初に、TestRailの各ログインユーザーは、JIRAへの直接出力を設定する必要があります。 これを行うには、いくつかのカスタム変数jira_user + jira_passwordが必要です（ docs.gurock.com/testrail-integration/defects-plugins-variablesへようこそ ）。 JIRA_Restプラグインで作成した後（管理->統合-> JIRA_Rest）、次を設定します。

[接続]
アドレス= http：// jira / ***
ユーザー=％jira_user％
パスワード=％jira_password％

やったー これで、各ユーザーは[設定]でJIRAからログイン/パスワードを設定できます。

次に、JIRA_Restで、インストールされたJIRAへの直接接続と、その後のすべての既存のJIRAフィールドの接続の両方を登録します：メインフィールドかカスタムか（ docs.gurock.com/testrail-integration/tools-jira-restにようこそ ）。

JIRAとの直接通信（例）：
参照ビューのURL： your-server / jira / browse /％id％
参照URLの追加： your-server / jira / secure / CreateIssue ！ Default.jspa

メインフィールドへのリンク（例）：
[プッシュフィールド]
要約=オン
プロジェクト=オン
issuetype = on
コンポーネント=オン
譲受人=オン
優先度=オン
effects_version = on
fix_version = off
見積り=オフ
ラベル=オフ
環境=オフ
説明=オン

カスタムフィールドへのリンク（例）：
[プッシュフィールド]
customfield_XXXXX =オン

[push.field.customfield_XXXXX]
ラベル=顧客
サイズ=コンパクト
タイプ=ドロップダウン
必須= true

その結果、バグを開始するときに、テストレールツールを安全に使用でき、同時にJIRAで次のウィンドウに切り替える時間を無駄にしないでください。 それはプラスですか？ 大規模なテストサイクルを実行し、テスト結果を設定するとき、これは明確なプラスになります。これらの非常に数十秒が最終的に貴重な分になり、単に作業の利便性が重要になるためです。
そしてもう1つ：テストレポートを生成するとき、通常、結果の後にテストケースの通過をブロックする既知の欠陥のリストを表示します。 このようなリストを想像してください。このレポートの欠陥にカーソルを合わせると、チケットに関するJIRA情報（概要、説明など）がポップアップ表示されます。 ただ素晴らしい！ すべてがあなたのために行われます。

4.メインテクノロジーの後。 設定の場合、マイルストーンに関連付けられたプロジェクトを安全に作成し、テストケースを含むさまざまなセクションを含むテストスイートを作成できます。また、希望と基準のみに基づいてダッシュボードを構成できます。

あらゆる機能のテストケースを作成する場合、まず最初に、同等クラス、セクション、および少なくとも正負のシナリオに分割することを明確に説明するテスト計画を作成することをお勧めします。 TestRailを使用すると、このような計画を最も効果的に作成し、その後、本格的なシナリオに拡張できます。

もう少し詳しく：テストスイートを作成します。 次に、その中にセクションとテストケースの両方をこれらのセクション内に追加する機会があります。 ケースの内部の本質に行くことなく、Summaryのみを入力し、入力後にEnterを押すことで、テンプレート（=チェックリスト/テスト計画）を作成する機会があります。 次のようになります。



名前（テスト/グループ/等価クラス）を入力し、Enterキーを押します->入力フィールドにカーソルがある次のケースに既に移動しています。 したがって、可能な限り迅速に、必要な計画を作成できます。これは、多くの場合、以前にWord、Excelで作成されていた、またはまったく作成されていませんでした。 これらの開発は、アナリスト/開発者のチームを通過する必要があります->レビューの結果によれば、何かを追加する必要があるかどうかは完全に明確になります。 これは単なる計画であることを忘れないでください。すでに完全に満たされているテストケースと混同しないように、追加のテストケースを導入しました。 [タイトル]フィールドのみ。デフォルトは[はい]です。



このフィールドは、テストケース自体を編集フォームに書き込むことによってのみ、Noに修正できます（「タイトルのみ」= Noにチェックマークを付けるだけです）。



入力したカスタムフィールドは、表示される列で選択することにより、他のすべてのフィールドと同様にダッシュボードに配置することもできます（メインページの[タブ]をクリックして、フィールド名をリストする行にテストケースを記述します：ID、タイトルなど）。



5.テストケースのすべての内部フィールドもカスタマイズ可能

テストレールの初期構成では、テストシナリオの内部フィールドの古典的かつ無条件に必要なセットが表示されます：ID、優先度、初期条件、ビュー、ステップ、期待される結果、JIRAの要件または実装タスクへのリンクなど。 任意のフィールドを追加して、必要に応じて設定する権利があります。それが文字列、チェックボックス、ドロップダウンのいずれであるかは関係ありません。 すべてがあなたの手と頭の中にあります！ 私たちは何をしましたか：

- テストケースフィールドのデータを追加しました。このフィールドでは、1つの同等クラスからのテストについて、テストを実行する必要があるデータをリストするだけです。 エグゼキューターの役割から入力行のリストまで、何でもかまいません。

-ID AutoおよびAutoフィールドを追加しました。 ID Auto-自動テスト用の一意のID。 自動-テストケースが自動化されているかどうかを示す[はい/いいえ]チェックボックス。

これは、将来、自動化のためにテストレールを設定するときに、これらのパラメーターを使用して必要な自動テストを実行し、必要なレポートを生成できるようにするためです（http://www.gurock.com/testrail/tour/5/-自動テストとAPI）。

6.テストの実行では、テストケースのセットを完全に選択できます。

テストレールを使用すると、任意の基準でテストサイクルを作成できます。 これは、厳密に定義されたシナリオ（優先順位、マイルストーン、名前、名前の一部によって選択されますが、実際には何らかの方法で選択されます-すべてが目標に依存します）を実行する必要があることが多いため、ツールの非常に重要な機能です。 そのため、テスト実行を割り当てるときに、フィルターによって「自分の」スイートを選択する機会があります。 一般的なビューは次のとおりです。



しかし、たとえば、名前で選択します。名前は「等しいか、何かを含む」です。



これにより、テストスイートを選択して完全に実行できます。

7.カスタマイズ可能なレポートシステム

すべてのテスト実行は、明確なレポートの形式で表示できます：「なぜ、どこで、いつ」。 テストサイクルを作成するときのように、任意の基準を選択できます。 とりわけ、必要な時間と関心のある受信者のために、あらゆる種類のレポートの配布を構成することは理にかなっています。

おわりに

チェックリスト、アドホックテストは優れていますが、明確な手順がなければ、製品には多くの場合、時間の経過とともに増加して会社を倒すという弱点があります。 テストケースのセットとカバレッジマトリックスの両方を（少なくともコンポーネントごとに）持つこと-これは回避できます。

TestRailのすべての機能とはかけ離れたリストを作成し、その使用例をいくつか紹介しました。 それでも、このような柔軟なカスタマイズにより、多くの人がこのツールを開発プロセスに合わせてカスタマイズできることは明らかです。 特に、このツールを使用すると、QA部門を完全に透過的に監視することができます。これにより、まず「テスト対象」の控えめな表現が排除され、次にチーム間の明確な相互作用が確立され、「テストの理由と方法」を理解できます。

ツールを選択し、テストし、プロセスを制御してください！ 頑張ってください！

記事の著者：Vasily Petukhov、分析および品質管理部門の責任者Diary.ru