はじめに
TestRailではデモ版があるということで、すぐにどんなものかを確認できたので、
一通り触ってみての感想を書き記します。
今回はデモ版をざっくりと触り、機能紹介に目を通しました
結論
- 小～中規模開発
- プロジェクトはこれから～最近始動
- 品質管理に詳しい人がチームに居ない
上記条件に当てはまるのなら、TestRailはすぐに導入してよいと感じました。
逆に、
- 大規模開発
- プロジェクトが始動してしばらく経つ
- 品質管理に詳しい人がチームに居る
という条件があるなら、TestRailの導入はコストやメリットを元に検討必須、という感じです。
導入すべき理由
私の感じる1番のメリットは、
とりあえずこれに全部集約しておけば、
テスト周りにおいて必須の要素を超えて、
多くのメリットを出しながら管理・維持できる
という点だと思います。
私の体験談から例を挙げるならば、
- テストケースのテンプレートがイケてない
- 過去のテストケースが行方不明
- テストの記載が全く無く、内容が不明確
あたりを使うだけで解決できます。
テストケースのテンプレートを作成するのは、練度が必要な作業です。
品質管理に詳しい人がいないと、穴だらけのテストを運用することになり、
品質の低下の主要因となり得ます。
過去のテストが消えたり意味がわからない問題は、
プロジェクトを始めて数年経ったあたりから、
ボディブローのようにじわじわと痛くなってくる点です。
Excel管理だと、1から作らないといけなかったり、
紛失するということが往々にしてありますが、
TestRailであればこれらを初期段階で回避でき、非常に有効です。
また、「設定次第で何でもできる」という印象があります。
テストスイート単位でリグレッションテストの括りをつけてやれば、
イテレーション単位の品質モニタリングも容易そうです。
ということで、開発テスト周りの管理はこれ1つで全部できそうです。
最も心惹かれた機能！
「工数実績からテスト全体の完了予測日を自動で計算する機能」ですね。
これ本当にすごいので、もっともっと推してください！
※上記サイト内より画像をスクリーンショットで引用しています。
テスト工数の算出と、現時点でテストにどれくらい遅れが出ているのかという報告は、
熟練の肌感になりがちな印象です。
そのあたりを機械的に実施することができますし、
進捗の良いテスト実行者を、進捗が悪いテスト実行にあてがう判断材料にもなると思ってます。
それに、この情報は後続のテストに品質管理部門が控えているなら、そちらにとっても重要な情報になるはずです。
- このケースはテスト実行に想定以上の時間がかかる
- このケースで不具合が出て追加修正したから遅れた
ということを知れれば、
- 対象機能周りのテストは想定以上に時間がかかるから、先に実施しよう
- 不具合が出ているということは、他にもあるかもしれないし、周辺領域もよく見ておこう
という判断ができるはずです。
ざっくりと言えば品質向上に寄与できるわけですね。これは本当に目玉機能ですよ。
デモや1イテレーションじゃわからないので実感がすぐ湧かないかもしれませんが、
半年や1年、5とか10イテレーション経った時、運用していてめっちゃ頼ることになりますよ。
あと、この時間を計る系領域は、Excelで管理しようものなら地獄を見ると思います。
Excelでどう統計を取ったらよいか、大変過ぎて私は考えたくありません。
要検討の理由
先ほど、即決にならない条件を挙げましたが、以下の通りです。
- 大規模開発
- テストケース数が膨大だと、この形式では管理しきれないか、視認性低下のおそれがある
- イテレーションが長いと情報を引き出す回数が減るのでメリットが薄まる
- 機能に頼らず、遅れを人海戦術ごり押しパワープレイで乗り切れてしまう
- CICD面や他領域で利用するソフトの連携を考えると、他に最適解が存在する可能性がある
- プロジェクトが始動してしばらく経つ
- 既存のテストが多く、情報を乗せ換えるのに多大なコストが発生する
- テストケースの形式が異なる場合は書き換えのコストが発生する
- そもそも形式が合わず乗せ替え自体できない場合もある
- 品質管理に詳しい人がチームに居る
- ローカライズした品質管理手法の方が、低コストかつ高メリットになる可能性がある
- もちろん「良いものだから導入すべき！」と音頭を取る可能性もある
記載の通り、どれも「Excelで管理すべきだ」という話ではないんですよね。
「ExcelよりTestRailの方が圧倒的に良い！ 可能ならTestRailを使うべき！」という前提で、
TestRailを使うために検討すべき事項がいくつかある、という話です。
弊チームは導入するのか、その理由は
残念ながら導入はしません。
そんなこと書くなよ、とも思うのですが、
理由は有用だと思うのでそれを書くには、導入意思を書かざるを得ないわけで……。
先の条件の話に照らし合わせると、
- プロジェクトが始動してしばらく経つ（6年以上経過）
- 品質管理に詳しい人（私）がチームに居る（諸々対応済）
ここら辺に該当します。
上記以外の具体例を挙げると、
- イテレーションも短めで一度のリリース量が少ないため、集計せずとも口頭や目検でテスト結果を容易にチェックできる
- リリースに不具合を含めることは基本認めないため、不具合数等をモニタリングする必要性が薄い
- 自動テスト/リグレッションテストも、不具合が出ることを認めていないのでモニタリングの効果が薄い
- 実行するテストが開発者テストだけでなく所謂評価者テストも実施するので、テストの書き方が則してない
特に、シナリオテストを開発側で実施している場合、表現するのは難しいと思います。
大昔にシナリオテスト用のテスト管理ソフトを少し使ったことがありますが、それすら使い辛そうでしたし、ソフトがあってもテストケース自体はExcelで書いてたんです。
それくらい、シナリオテストはExcel形式の方がわかりやすいです。
Excelで作るシナリオテストのイメージを載せます。
例としてECサイトのテストを想定したものを書いてみました。
シナリオテストの雰囲気を感じ取ってもらえればと思います。
これをTestRailで運用しようとすると、
- 実行手順が長く、途中途中で確認が入るため、文章で表現するのが難しい
- 1つのテストケースで複数の確認項目や期待結果を確認するため、NGがついてもどこがダメなのかわかりづらい
- 手順の途中で止まるケースがあり、それを理解するにはぱっと見でわからない（長ったらしい手順を読むしかない）
- これを文章形式に乗せ換えるのも運用をするのもコストがかかるし、同様のテスト設計クオリティを出せるか難しい
という問題点が考えられます。
もしかしたら解決方法があるかもしれませんが、見つけられませんでした。
流石にシナリオテストの運用は想定されていないと思うので外れ値的な理由ですが、
珍しいケースでしょうし、記載しています。
総評
テスト管理においては、Excelと天地ほどの差があると思います。
その点は100％導入した方がよいです。
Excelと比較して不都合な点を強いて挙げると、シナリオテストまで実施している場合はテストの書き方と集計が則さないことです。
あまり開発内でシナリオテストを実施するケースは多くないと思いますので、デメリットにはならないと思いますが、可能性として挙げておきます。
前述の通り「品質管理に詳しい人がいる」からこうした判断ができるだけであって、
わからないのであればデモ版を使って検討してみるのは大アリです。
きっと、テスト管理の行く先、展望が開けるでしょう。