はじめに

仕事でテスト管理ツールの選定を行ったので、その備忘録を残す。
半年後、あるいは1年後に、より良いツールが誕生して乗り換えたくなったときに、思い出せるように...

本記事に記載されている内容は筆者の所感に過ぎない。
うちの会社の状況にフィットしたものを選んだ形である。
選定されなかったツールを非難する意図は全く無い。

テスト管理ツールとは

ざっくりといえば、テストケースとその結果を一元管理するアプリケーションのこと。
スプレッドシートやExcelで管理するのと何が違うかというと・・・

ケースのマスタ、テンプレート、リポジトリという概念がある
テストを実行するときは、↑から対象ケースを選ぶ
1回目と2回目 ... n回目の実施結果を明確に管理してくれる

といった性質を持つ。
一番でかい性質は、ケースを集積する概念があり、この仕組みの利用を強制できることだろう。

導入しようと思った理由

スプレッドシートを用いた管理には、こんな問題があった。

QAエンジニアごとにフォーマットが違う

僕も勝手なフォーマットを使っていたから人のこと悪くいえる立場ではないのだが、同じ組織に属するQAエンジニアなのに、皆オリジナリティあふれるフォーマットを利用していた。

当時は「1プロダクトチームに1QAエンジニア」という個人プレー状態であったため、フォーマットの齟齬は、さほど問題にはならなかった。
しかし、1プロダクトに複数のQAエンジニアが属するようになると、フォーマットがバッティングすることもあるし、「プロダクトチームに専属していない横断的なテスター」は、複数のフォーマットに踊らされ続ける。

さらには、スポットでQAプロセスを外注する可能性も出てきた。
外注先にも、一律のフォーマットを利用してもらいたくなってきたんだ。

テストケースの再利用性が低い

スプレッドシートでは、昔のテストケースを検索することが困難だ。
過去のケースをコピペすることもあるにはあるのだが、大体は、「探すのが面倒だからイチから書いちゃう」という状態。

そのため、再利用性を高めるような構成にはしていないし、書きっぷりも雑。
だから、自分以外の人が読んでも謎...みたいな感じである。
僕自身もそうだし、たぶん他の人もそう。

「イチから書く」という行為に費やす工数は、本来、「再利用性のある分かりやすいケースを書く」行為に費やした方が良い。
そのため、ケースの「マスタ」「テンプレート」「リポジトリ」といった概念の利用を強制させるツールの導入が望ましいと考えた。

ツール選定の様子

選定の様子を先に書いてしまうと、こんな感じだった。

選定項目について

およそ20項目ほどの指標で比較したが、重要性の高いものだけピックアップしている。

ケースの表現方式

スプシを踏襲した形式か、1ケース1ページの形式か、箇条書きのようなリスト形式か。
最初は既存のスプレッドシートをインポートできるよう、スプシ形式が良いとも思っていた。

しかし、ケースを再利用可能な状態に整理するには「画面単位」「手続き単位」で管理するのが良さそうであるが、現状のスプレッドシートのケースはそのように管理されていない、
おそらくイチから手入力またはコピペすることになると思われるため、形式に甲乙はつけなかった。

ケースの管理方式

色々と試していく中で、階層構造を深く作れるのが望ましいと感じた。
上述の通り、Webアプリケーションのテストケースを整理する際には「画面単位」でフォルダを作り、更にページ内のUI単位でフォルダ分けすることが良さそうだった。
そうなると、少なくとも5つほどの階層を作れないと整理整頓がしんどそうである。

バグチケットの俯瞰

Failedになったケースがどのバグチケットと紐づいているのか、或いは、Blockedになったケースはどのバグチケットが直ったら実施可能になるのか。
こういう「ケースとバグチケットの対応」を一覧で俯瞰できないのは、アジャイルでは結構辛そうだ。
大きめの開発ではいくつものバグが発生するし、そのバグは個別に修正がなされて再QA依頼が来るからだ。
ウォーターフォールのように、すべてのバグが直ってから再QA・・・などではない。
そのため、バグチケットに関連したケースを俯瞰できる必要がある。
「1ページずつ開けば分かる」でも駄目。
一覧として俯瞰できる必要があった。

エンジニアへの共有手段

QAエンジニア以外にテストケースを見てもらいたい機会は結構ある。

[1] 認識齟齬がないか、テストケースを見てもらいたいとき
[2] 事前にQA観点を共有するとき
[3] テスト完了後に、実施結果を共有するとき

QAエンジニアとエンジニアの人数比率は、「1 対 10」とかだったりするので、定常的に利用するわけでないReadOnlyユーザーに対しても課金が発生するツールは、コスパが悪い。

最終選定したツール - Testmo -

Testmoを選定した。
選定理由は以下の通り。

ケース/結果ともにカスタムフィールドを設定できる
- 自動テストへの実装状態や、対応する自動テストシナリオを管理可能
- 結果列に不具合原因等、分析に利用する項目を任意に追加できる
エクスポート機能が充実している
- Runs(実行)単位でも出力できるし、複数の実行結果をまとめて出力することも可能
- 同じケースを複数回繰り返し実行した場合も、行を分けて結果を出力できる
- カスタムフィールドも出力可能
レポート機能が充実している
- 出力有無などを調節しながら、結構ちゃんとしたレポートとして出力可能
- エンジニアへのQA観点/テスト結果共有に利用可能なレベル
マークダウン/画像を利用できる
- プレーンテキストにしか対応していないツールだと、デシジョンテーブルや状態遷移図を別管理する必要がある。
  こうした「整理後アウトプット」もツール内で整理したいため、マークダウン/画像挿入が可能である点は非常にありがたい
ケースのフォーマットをカスタマイズできる
- ケースや結果欄のフィールドをカスタマイズできるのはもちろんのこと、そのフォーマットをテンプレートとして管理し、ケース作成時記述する際に任意のテンプレートを選択できる。
  そのため、「機能テストはこのフォーマット」「シナリオテストはこのフォーマット」という使い分けをケース単位で行える。
  QAエンジニアによっては、「～～できること」という超簡素な箇条書きしかケースに書かないヤバい人もいる(←自分)ので、意図的に手順欄や期待値欄がないフォーマットを作れるのもありがたい。
ユーザーライセンスがbulkでの購入になる
- Teamプランには10名分内包されており、Businessプランには25名分内包されている。
  11名以上となった瞬間にBusinessプランの契約が必須になるため、利用可能なユーザー数は「10名の次は25名」と不連続に増加する
- うちの会社のQAエンジニアは10+α名程度であるため、25名までだいぶ余裕がある。
  その余剰分のユーザーライセンスを、エンジニアに期限付きで渡し循環させることで、実質的にゲストユーザーの仕組みを作れる。
  でもって、QAの人数的にTeamプラン(10ライセンス)では足りないため、「プランがこうなっているんだから仕方ないでしょ」と上長を説得するのが楽。
  一長一短だが、自分的には好都合だった。

おわりに

もしも自分ひとりで利用するなら、超クセ強な「Testpad」を採用している。
このツールは期待値記入欄すらないほどシンプルだ。
シンプルすぎるがゆえに、「一番早くケースを書けそう」かつ「脳への負荷が少なそう」だ。
また、「Libraries」は「コピペのテンプレート」に過ぎないため、コピペ先で一部内容を変更しても、Libraries側のケースには影響がない。
つまり、「Librarieが常に最新」ということだけ覚えていれば良く、「バージョン」を意識する必要がない。
いわば、Librariesを「クラス」とするならば、実施時にインスタンス化した上で一部内容をオーバーライドする、、、みたいな柔軟な使い方が可能だ。

しかし、QAエンジニア毎に多種多様なフォーマットを利用している現状や、各々が我流で設計している様子を考慮すると、このクセ強感はデメリットになりかねないと思った。
「ツールに適合できた者」と「ツールの仕様に縛られる者」が出てきて、全体のパフォーマンスとしては悪くなる怖さがあった。
なので、比較的構造がベーシックであり、機能が柔軟、、、んでもってモダンなデザインでちょっとテンションが上がるようなツールとして、Testomoを選んだ。