この話はある開発チームのリードエンジニアがそれまでのチームの非効率的なテストの管理に嘆き苦しみ、改革を行ったごく最近の物語である
■対象読者
- プロジェクト管理ツールJiraを現在使っている、もしくは導入検討中である
- テストの管理で苦しんでいる、改善したい
- 例.ExcelもしくはGoogleスプレッドシートでテストを書いているが、もやもやを抱えている
- テストが非効率であることに自覚がない方
- 上記のいずれにもあてはまらないが、何かおもしろそう
プロローグ〜僕達はテストの無駄を無くしたいと願った〜
僕達の開発チームではマニュアルテストケースは今までGoogleスプレッドシートで書いて、特定のフォルダにまとめていました。
プロジェクト管理ツールはJiraを使っており、Jiraで作ったそれぞれの課題にスプレッドシートのファイルが紐づく形です。
実際の流れを説明しましょう。
例えば新機能に関する課題を以下の様にJiraで作るとします。
TEST-1:ユーザー検索
TEST-1はJiraの一意の課題キーです。
テストケースファイル名はJiraの課題との紐付けをする為に{Jira課題キー}.xlsxのルールにしていたので、例で言うならTEST-1.xlsxのファイルを作り、ユーザー検索に関するテストケースを記載します。
皆さんも業務で一度はこのようなフォーマットを見たことがあるかもしれませんが、大体このようなフォーマットです。
※サンプル
テスト実行時はテストケース×ブラウザ・端末・Web/アプリの組み合わせで担当を割り振り、順次実行します。
もしテストが失敗した場合はバグとして新たにJiraに課題を作り、開発者がバグを修正後、修正部分とその修正による影響部分を再テストします。
そうしてテストが全て完了したら、リリースを行います。
基本的にはこの繰り返しです。
「なんだ、普通じゃん」と思うかもしれません。が、、、このスプレッドシートでのテストは様々な問題があります。
スプレッドシートでのテストは何が悪かったか
どこにどのテストケースがあるのか分からない
一番困るのは過去に書いたテストケースがどこにあるのかが分かりづらい点です。
課題キーでの検索で紐づいているテストケースファイルは分かりますが、特定のテスト内容を検索したい場合ファイルを開いていちいち検索しなければいけません。
複数のファイルを横断的に検索することが出来ないからです。
この検索性の低さは容易にテストケースの重複を生み出します。
「あれ？あの機能のテストケースどこにあったっけ？ 誰かが過去に書いた様な気がするけど・・・
なんか見つからないな。もういいや、新しく作っちゃおう」
本来なら存在するテストケースを修正もしくは流用するだけで済んだのに、テスト作成の時間とテストケース重複の無駄が発生していくわけです。
これが続くと、どのテストケースの内容が今最新の仕様に基づいているのかも分からなくなり、さらなる重複が発生すると言う悪循環に陥ります。
テストが書きにくい
画像が貼りにくい
ExcelやGoogleスプレッドシートは画像がとにかく貼りにくい。
スプレッドシートは普通のファイルアップロード方法でしか画像をあげられず、画像をコピーペーストで気軽に貼ることが出来ません。
デスクトップアプリのExcelは可能ですが、どちらにも共通して言える問題がセルの中に画像を簡単に格納出来ないということです。
例えばテストの手順や期待結果、失敗した時の実際を分かりやすく伝える為に、画面のスクリーンショットを貼りたい場合があります。
画像はセルから浮いており、セルの中に格納することは出来ません。
なのでセルの高さを調整して、あたかも格納しているように見せるわけです。め、めんどくさい・・・
(セル内に画像をぴったり表示する方法はあるにはありますが、それはこの記事では説明しません)
テストの内容を他の方(特に開発者以外)に分かりやすく伝える場合、スクリーンショットは非常に効果的です。
しかしこの問題により、テスト作成者はスクリーンショットは貼ることはせず、文章だけを載せます。
なぜならそもそもテストを書くこと自体人は面倒臭いと感じるからです。
画像を貼るのが面倒くさくなってしまえば、人はやりません。
その他
画像以外にも表現したいことは様々です。
フォーム入力のテストであればテスト手順の中で項目ごとの入力値を表形式で載せたいかもしれません。
そういったリッチな表現方法が提供されていればテストを書くのにストレスが減り、テストが分かりやすくなります。
しかし画像と同様に人は面倒臭いと思うと、「こう書いた方が分かりやすい」と理解しつつも、ついついシンプルな記載をしてしまいます。
そうして「画面下部の***ボタンを押下せよ、さすれば道は開かれん(ページ遷移すること)」のような黒魔術的テストケースが生まれ、テスターがテストを実行するときに作成者にこう聞くわけです。
「ねえねえ、これってどういうこと？＼(^o^)／」
はい、このやりとり自体が無駄です。
そもそもスプレッドシートはテスト管理の為のツールではない
テストを書くこととテスト管理は全くの別物です。
スプレッドシートはあくまでテスト内容を表形式で書けるファイルに過ぎません。
それをどう実行するかは皆で話し合い、認識をすり合わせる必要があります。
これも実際のケースに沿って考えてみましょう。
例えばある機能の開発でテストケースのかたまりとなるグループが1〜10まであったとします。
リリース前に検証環境でテストを実行します。
1回目は単純に全てのテストケースグループを順次実行します。
実行結果としてテストケースグループ1〜2で失敗し、バグがあることが分かりました。
バグを修正したので、2回目のテスト実行に移ります。
さて皆さんだったらここからどうしますか？
まず2回目に「何」のテストを実行しなければいけないかを決める必要があります。
もちろん全てのテストを最初から実行する必要はありません。
修正部分とその修正によって影響がある部分、テストケースグループ1〜3だけテストを行います。
このテストケースグループ1〜3だけ実行することをどうチームメンバー間で認識を擦り合わせるか。
スプレッドシートに「2回目の実行結果」というカラムを追加して、膨大なテストケースの中で実行しないテストケースに「-」などのマークを入力すれば良いでしょうか？
もし3回目、4回目があった場合は？
もっと細かく言えば1回目で失敗したテストケースが、2回目で成功したが、3回目で失敗した場合は？
テストサイクルの中で誰がいつ実行してその結果どうなり、次のテストにどのような影響を及ぼすのか、流れを可視化することは不可能です。
ここにスプレッドシートの限界があります。
しかしこのテストプロセスの可視化こそテストの管理で最も重要な点です。
テストを書くことはプロセスの一部に過ぎません。
そう、スプレッドシートは限界だった
上に挙げた点以外にも僕達は様々な不満を抱えていました。
- 機能改善でテストケースを修正しても修正部分が分かりにくい
- テストで時間がかかった部分についての分析が出来ない
- 分析出来ないということは改善もできない
- etc
・・・一言言わせてください、すぅぅぅぅっ
そう、「無駄」が多すぎるんです！
この無駄な部分を取り除き、テストプロセスを可視化しないと、テストのみでなく開発自体が改善しない！
そう心に誓い、テスト管理の改革に取り組むことになりました。
チャプター1 あるべき姿を求めよ
長いプロローグですみません汗
でも何が悪いのかを自覚しなければ、改善することはありえません。
「今までそうやってきたから」は思考の停滞です。
まず僕がやったことはテスト管理の「あるべき姿」を定義し、Must(必須)とBetter(必須では無いが満たせたら良い)に分けました。
例を挙げると僕達はプロジェクト管理ツールのJiraを使っているので、Jiraと連携出来ることはMustとしています。
■Must
- Jiraと連携出来る
- 新機能/機能改善/バグの課題とテストを紐づけられる
- テストで失敗した時に、その失敗したテストケースに紐づくバグの課題を作成できる
- いつ誰がどのテスト環境(端末/ブラウザ/Web or Native App)で何のテストを実行し、結果どうだったのか履歴がわかる
- 実行履歴は同じテストケースグループで前回の実行からどのように結果が違ったのかが把握できる
- テストケースを簡単に検索できる
- テストケース追加・修正・削除が簡単でストレスが無く行える
- スクリーンショットや表の埋め込み等、リッチな表現が気軽にできる
- テストごとに失敗した場合のコメントやスクリーンショットの添付が出来る
- 利用料金が予算内である
■Better
- テストケースのバージョン管理が出来る
- テスト結果を分析出来る
- テストにどれくらいの時間をかけたかが自動的に分かる
チャプター2 あるべき姿を基に調査せよ
あるべき姿が定まったら現状とのギャップをどう埋めるか、その手段がテスト管理ツールです。
はじめからツールを入れれば解決にするという思考になってしまうと、結局本来の問題が解決されずに終わってしまいます。
調べ始めてすぐに、実はテスト管理ツールというのは世の中に山ほどあることが分かりました。
参考にさせて頂いた以下の文献だけでも数多くのテスト管理ツールが紹介されています。
2017年最強のテスト管理ツールベスト１０
テスト管理ツール導入のススメ
モダンなテスト管理プロセスのためにテスト管理ツール３つを比較検討したはなし
JIRAで使えるQA用テスト管理ツール「Zephyr」と「TestFLO」を試してみた
これらを一つ一つ詳細に調べるときりがないので、先ほど定めたMustの要件を満たしているものをどんどん絞り込んでいきます。
こういった比較調査の場合、評価項目と比較対象のマトリックスで行うのが一般的です。
しかしこの方法が有効なのは比較対象が限られている場合です。
目安として比較対象が5つ以下までになるまでは、必須要件で絞り込む方が効率的です。
Jiraと連携出来るか
テスト管理ツールをJiraと連携させるには二通りの方法があります。
- Saasとして提供されているテスト管理ツールをJiraと外部連携する
- Jiraのアドオン単体
1も実はJiraアドオンを使いますが、あくまで外部サービスとの紐付けだけで、機能は備えていません。
サービスによっては1と2どちらの方法も提供しているものもあります。
例えばQMetryというサービスも両方の連携方法で利用出来るようになっています。
QMetryもそうですが、たいていは1の外部サービスと連携するものは「** integration」、
2のJiraアドオン単体で動くものは「**** for Jira」といったようにアドオン名を分けていますのでご注意ください。
連携方法による料金の違い
Jiraとの連携方法で1と2って何が違うの？と言ったら、大きく異なるのは料金です。
例えばテスト管理ツールの一つでTestRailというツールがあります。
このツールが提供しているJiraとの連携方法は1で、料金はクラウドで利用するにしても、
最低$30/月/人はかかります。
もし5人が利用する場合は1ヶ月$180となります。
他のSassとして提供しているメジャーなテスト管理ツールも同じくらい、もしくはそれより高い料金になっています。
対して2のJiraアドオン単体の場合は当然アドオンの料金だけで済みます。
Jiraアドオンの料金はホスティング方法(オンプレ/クラウド/データセンター)、チーム人数の二つで決まります。
僕達はJiraをオンプレかつチーム人数10人以内で使っているので、以下のような一般的なアドオン料金によると、$10の1回払いで恒久ライセンスが手に入ります。
もしJiraをクラウドで大規模な人数で利用している場合は1の方法の方が安くなることもあるでしょう。
条件によりますので、Saasと連携する方が必ず高いとは言えません。
ただ少なくとも僕達のチームの場合はJiraアドオン単体で利用する方がはるかに安く済むので、まずはそちらの方法で優先して候補を絞り込むことにしました。
テストケースを「テスト環境」と組み合わせることが出来るか
Must要件の一つで
「いつ誰がどのテスト環境(端末/ブラウザ/Web or Native App)で何のテストを実行し、結果どうだったのか履歴がわかる」
があります。
この要件を満たせているものを絞り込むだけで、候補はなんとたった二つにまで減りました。
正確に言うと、テストケースとテスト環境を組み合わせることが出来るツールが二つしかなかったのです。
メジャーなテスト管理用のアドオンであるZephyrでさえも、普通なら備えてそうなこの要件を満たせていませんでした。
その二つは
です。
Xray vs Test Management for Jira
この二つはその他のMust要件も満たしていましたが、結論としてTest Management for Jiraが僕達のチームにより適していると判断しました。
その理由は以下に記載します。
テストケースは「課題」ではない
XrayだけでなくほとんどのJiraアドオン単体で動くテスト管理ツールはある特徴を備えています。
それはテスト自体をJiraの課題として扱う点です。
これについては実際見てもらえると分かりやすいので、以下はJiraのバックログの画像をご覧ください。
例としてJira Cloudでサンプルサイトを立ち上げて、Xrayをインストールして利用してみました。
さて、機能開発に関する「課題」はいくつあるでしょうか？
実は機能開発に関する課題は上の3つだけで、あと残りは全てテストに関する課題となります。
Jiraの課題にはデフォルトでエピック、ストーリー、タスク、サブタスク、バグといった種類がありますが、テストに関する独自の種類が追加されます。
いわばJiraの課題をカスタムフィールドで拡張してテストとして扱います。
それぞれの課題の違いは公式ドキュメントをご覧下さい。
このバックログを見ても分かるように、機能要望やバグとしての課題の中にテストとしての課題も含まれるので非常に煩わしいし、見にくくなります。
何より「テストは課題じゃない」という違和感が強い・・
一方Test Management for Jira(名前長い・・)はテストをJiraの課題ではなくアドオン独自の概念として扱っています。
当然カンバンやバックログには表示されません。
ただし課題との紐付けは行えます。
以下は課題に対して紐づけたテストケースが実行して問題なかったことを表しています。
開発における課題とテストは紐づいた方が良いですが、基本的な概念は異なるべきで密接しすぎてもいけません。
テストケースをバージョン管理出来る
Test Management for Jiraの良い点はテストケースをバージョン管理出来るところです。
まずは本記事の冒頭で例としてあげたユーザー検索のテストケースファイルを基に同じテストケースをJira上で作っていきます。
Test Management for Jiraではこのようになります。
テストケースを新規に作ると自動的にバージョンは1.0となります。
仮にこの機能をリリースしてから少し経ってユーザー検索を改善することになったとします。検索条件が増えるそうな。
仕様が変わるのでテストケースも当然変わります。
ただ機能改善前後でどのようにテストケースを変更したのかが分かるようにすると、テストケースレビューが簡単になりますし、これまでどのように仕様が変わったのか経緯も把握できますよね。
そんな時の為のバージョン管理です。
仕様が変わってテストケースが変更になるので、テストケースのバージョンを新しくしましょう。
右上の「New Version」ボタンをクリックします。
バージョンは2.0に変わりました。
次にテストケースを変更します。
氏名だけでなく性別でもユーザー検索出来るようになったので、Step3,4を追加して保存します。
テストケースの履歴タブではバージョンごとにどのように変更したのか履歴を見ることができます。
特筆すべきはバージョンとバージョンの比較ができます。
比較したいバージョンにチェックを入れて「Compare Versions」ボタンをクリックしてください。
するとGitHubライクに追加した箇所と変更した箇所が色ごとに表示されます。
何が変更されたか一目瞭然ですね。
このバージョン管理は僕がTest Management for Jiraの中で気に入っている機能の一つです。
他にも様々な利点はありますが、それはまた別の記事で後日紹介させていただきますね。
チャプター3 説得、そして改革の夜明け
調査を終えたので、チームメンバー全員を集めてテスト管理をこれからどうすべきか、そのためにはどうすれば良いかプレゼンテーションを二週間ほど前に行いました。
プレゼン後の話し合いの結果、Test Management for Jiraを試験的に導入することに決めました。
メンバーからはいくつかの質問が挙がったものの、「テストケース作成が楽になりそう」「検索が出来るので重複が無くせるね」などおおむね好意的だったのでほっとしました
現在はある機能の改善において、Test Management for Jiraを用いてテストケースを作成・実行している段階です。
エピローグ〜戦いはこれからだ〜
テストは面倒だけれど必要です。
面倒くさいからこそテストの管理・運用はストレスなく効率的に行いたいですよね。
よくありがちなのが、非効率的なテストを頭の片隅では感じつつも「このプロジェクトではこういうルールなんだ」で自分を納得させ、環境に慣れてしまい、おかしいことをおかしいと思わなくなることです。
でもテスト管理を改善すれば、開発全体の速度が向上し、クオリティの高いプロダクトをユーザーに速やかに届けることが出来ます。
この記事が同じようにテストで苦しんでいる方々の助けになれれば幸いです。
あ、もし気になる点や質問があれば気軽にコメントをください。お待ちしています。