今働いているチームでは、メインプロダクトの正常系処理を一通り手で触ってみるリグレッションテストを週に1回実施している。このテストにテストマネジメントツールを1ヶ月間試験導入してみたので、実際にやったこととやってみた感想を書く。

tl;dr

雰囲気だけでテストをしているのでテストマネジメントツールをお試しで使ってみたら現状の運用のよくないところが見えてきてよかった。

テストマネジメントツール試験導入の概要

テストマネジメントツールは英語・日本語共に使用レポ記事が多い印象を受けたTestRailを選択した。

www.gurock.com

スケジュール

日付	やったこと
1/22	TestRailのアカウント取得テストケースのimport
1/24	実施計画提出
1/25 - 2/19	テスト実施(週2)
2/4	中間報告提出
2/19	最終報告提出各データのexport

テストケースのimport/exportに関しては別のエントリで書いた。

wifeofvillon.hatenablog.com

試験導入期間はテスト実施回数を増やすため、毎週火・金曜日にテストを行った。その点についてメンバーに理解を求めるためなぜ、いつまで、なにをするかという実施計画をSlackに流した。

TestRailを触り始めて半月くらいで中間報告をレポートとして先の実施計画に追記してSlackに流した。最終報告は追記したものの中間報告でほとんど書いていたためそういえばSlackに流してないな……

実施計画・報告書の内容

このエントリは社内向けの実施計画/報告書を下敷きにして書いている。参考までに目次を貼る。

Overview

History

Why did I try the test management tool

How working on Basic Test and QA testing currently

What I expect the test management tool

How I try to use the test management tool

Trial schedules

Interim Report

Steps to start to run Basic Test on TestRail

Good and Not-good points

Functions of TestRail which need to be followed in spreadsheet method

Final Report

How I used main features

Appendix: Screenshots of TestRail

テストマネジメントツールを使ってみた感想

「今やれていないこと」を可視化できる

現状ではGoogle スプレッドシートを使ってテストケースの登録からシナリオの作成、レポートの作成まで手動でやっている。

これは実施者が私ひとりであることに依存した運用なのでpreconditionが書かれておらず、stepsと期待結果が分離されておらず、本来独立した複数のテストケースとして扱われるべきフローをひとつのテストケースとして扱っていることがある。元々開発者から引き継いだテスト仕様書とはいえ、あまりいいことではないなと気づくことができた。

今回対象となったプロダクトは英語とそれ以外の言語設定でシナリオが異なるが、それもテスト実施中に私が吸収してしまっていてよくないなと思った。上で書いたことと合わせて属人化している要素が思った以上に多いようだった。