テストにもドキュメントがあることを皆さんの多くが知っていることを願っています。 そして、あなたはそれを昔ながらの方法で、xlsファイルとフォルダで、または本物のジェダイのように特別なツールを使用して行うことができます。
TestRailと呼ばれるツールの1つを次に示します。これは最近TestLab²に実装したもので、今日お話ししたいと思います。 楽器は非常に成功したため、沈黙はなく、私は最終的に社会に役立つ何かをすることにしました。
製品の簡単な概要：
- 公式ウェブサイト： http : //www.gurock.com/testrail/
- 目的：テスト文書の保守
- ライセンス：有料製品、159ユーロから*
- ステータス：リリース1.0
- プラットフォーム：LAMP
私たちがテストしているすべてのプロジェクトでは、小さなチェックリストから、クロスリンクと数百のケースがある分岐テストスイートまで、常にテスト文書が必要です。 ドキュメントをローカルファイルに保存するという考えは、すぐに完全に放棄されました。これは不便で、単に専門的ではありません。 「ユニバーサル」ソリューションであるwiki（DokuWiki）を試しましたが、根付きませんでした。 おそらく、それが習慣の問題であり、「棒で良い植物を植える」ことができる理由を言うのは難しいですが、その後、TestRailが現れてレースをしました。
用語の簡単な免責事項：
- テストケース-テスト計画のアトミック要素。次のコンポーネントで構成されます。
- ケースが実行される環境（環境）の説明（テスト計画の上位レベルを取り出すことができます）
- 実行手順
- 期待される結果
- テストスイート-いくつかの一般的な要因（製品全体、特定の機能など）によって結合されたケースのリスト
- テスト計画-テスト用に選択されたテストスイートのリスト
- テスト実行-テスト計画の合格（「実行」）
インストールとシステム要件
2つのオプション：典型的なLAMPまたは「IIS + SQLServer + FastCGI / PHP」。 ionCubeとcURLも必要ですが、これは珍しいことではありません。 それは十分速く動作し、mod_deflateを介してgzipをオンにした後、弾丸のように飛び始めました。
主な機能
テスト文書を保守し、テスト結果を記録するためのマルチユーザーマルチプロジェクトシステム。 この製品はすべての人に場所を提供します。「いつになるか」や「バグの数」に関心があるテストマネージャー、完了したケースの報告に慣れている単純なテスター、荒野に食い込んで内容を把握できるアナリスト向け
ワークフローはどのように見えますか？
- プロジェクトが作成されており、「Defect View Url」と「Defect Add Url」が示されています。 バグトラッカーとの統合は簡単であると同時に、見事です： your-bug-tracker.com / watch page /％id％ 、およびTestRailはthis％id％のバグを置き換えます。 ほとんどのオンラインバグトラッカーに適しています。
- マイルストーンが作成されます。実際、テスト対象の製品のバージョンは名前と期限で構成されています。
- テストスイートが作成されます。たとえば、「テストUI」などのテストケースのセットです。
- テストスイート内には、ケースと、オプションでケースセクションが作成されます。たとえば、「テストUI」には「クライアントUI」と「管理UI」の2つのセクションがあります。 セクションは無制限のネストをサポートします。
- 各具体的なテストケースは、前提条件、ステップ、および期待される結果で構成されます。 ここで、私の意見では、すべてが明らかです。 画像を添付して、それらの間にクロスリンクを作成できます。
- テストケースを使用してテスト対象のシステムを説明したら、テスト自体を開始します。 これを行うには、必要なテストスイートまたは特定のテストケースを含むテスト実行を作成します。 彼には（システムのアクティブなユーザーから）実行者が割り当てられ、この段階でテスト設計者の作業は終了します。
- テスト実行が設定されているという通知を受け取ったテスターは、実行を開始します。 テスト結果に応じて、各テストケースのステータスは合格、失敗、または再テストになります。 見つかったバグのコメントとIDも表示されます。
すべてのテストに合格すると、テストの実行は終了し、結果はタスクディレクターに送られ、テストの実行に関するすべてのデータがシステムに残ります。 - 顧客/ユーザーの要求に応じて、すべての結果を消化可能な形式にエクスポートしたり、印刷の準備をしたり、何らかの異常な用途のためにxmlにダンプしたりすることもできます。 システムは、テスト実行の結果のダイナミクスを迅速に評価し、すべてがどこに向かっているのかを理解できる少数のグラフを構築します。
競合他社との比較
選択肢の中で、私はRational Quality ManagerとTestLinkの 2つのシステムに出くわしていました。 オープンソースの支持者であるTestLinkを許してください。 もちろん無料です。もちろん、これは重要な議論ですが、ここでメリットがあります。 インターフェースは古くて不便で、特定のケースやスイートへのリンクの見当違いのシステム、スイートのまさしくその構造...一般的に、私の意見（およびチームの意見）では、それは「戦時中のサービスには不適切」です。
Rational Suite全体は優れていますが、小規模なプロジェクトには大きすぎて、独自の方法論を非常に強く課しています。 それがカーペットカーペットの卸売バッチとして立っているという事実は言うまでもありません。
先ほど読んだもののうち、 Testopiaと呼ばれるBugzillaモジュールについて言及しますが、残念ながら、私はそれがライブで見られず、誰かがそれを実稼働で使用しているとは聞きませんでした。 プロジェクトでBugZillaを使用している場合-Testopiaを見る価値があると思いますが、かなり高いレベルの統合が約束されています。
また、統合開発システム（同じMercury）またはデスクトップスタンドアロン製品（ TestLog 、 QaTraq ）に組み込まれた同様のソリューションが多数あります。 通常のWebアクセスがないため、私たちには適していません。 この方向のまだまともなウェブベースのシステムのコメントで誰かが私に言うことができれば-私は嬉しいです。
UPD1が追加で見つかりました（ astenixとKhizhnyakに感謝 ）：
個人的な印象
私たちにとって、このシステムは最低限必要な機能のセットの点で、そして日常使用の利便性の点でほぼ理想的であることが判明しました。 アウトソーシングテストを行い、ベンダーのライセンスポリシーに完全に適合する非常に多くの小さなプロジェクトを実施します。制限はシステムのアクティブユーザーの数のみを制限するため、プロジェクトの終了時にクライアントアカウントを無効にします。
注目に値する2つの欠点があります。現在のバージョンでは、TestRailはUnicodeをサポートしていません。つまり、現在のバージョンでロシア語/ウクライナ語のドキュメントをハックなしで維持することはできません。 しかし、対応する機能のリクエストは既に発表されており、すぐに追加する必要があります。 私たちのチームにとって、これはTestRailに入る価値のあるすべてのプロジェクトが英語であるため、これは原則ではありません。
2番目の問題は、すべてのテキスト編集フィールドにwysiwygエディターがないことです。 これはエンジニアを喜ばせますが、定期的に顧客を混乱させます。
まとめ
大規模なプロジェクトのテストドキュメントを実施している場合、またはケース付きの大量のdocファイルやxlsファイルで既に失われている場合は、TestRailに注意する必要があります。 これは誰もが必要としない製品ですが、専門的にテストしている場合は、この名前を覚えておくと、TestRailが次のプロジェクトで役立つかもしれません。
興味深い場合は、テスト用のさまざまなツールのトピックを作成する準備ができています。たとえば、同じTestopiaを注意深く学習して、それについて説明します。 コメントを書いてください。
* Googleで検索できる人は、インターネットで割引クーポンを見つけることができます。