テストプロセスにテスト管理ツールを導入した話

はじめに

こんにちは、Kyashの品質管理を担当している Tokkiです。品質管理のテストプロセスの一部である、テスト活動においてテスト管理ツールを導入したお話をしたいと思います。
前半では、何の課題があって導入したのか、実際の導入の流れ、導入してどうだったかの話。 後半では、実際にツール上でこういうことをやったという、作業レベルの話に触れたいと思います。

テスト管理ツール導入の検討

KyashのQAチームメンバーは2022年7月現在、管理者1名+外部のQAエンジニア5名で構成されています。プロダクト開発はアジャイル開発で行い、テスト実施期間は2週間〜3週間のスプリントで回しています。期間中のテストは主に機能テストとリグレッションテストを行っています。
チーム編成などの詳細は過去のブログでも公開していますので、是非読んでみてくださいね。

プロダクト開発やテストで使用しているツール

Slack (社内コミュニケーション)

Figma (UIデザインの共有)

Git Hub (主に開発者が使用)

JIRA (プロジェクト毎のタスク管理、テスト期間中のTicket運用)

スプレッドシート (テスト計画・観点・テスト項目の作成と運用)

会社によって使用するツールに違いはあると思いますが、ソフトウェア開発を行う上でコミュニケーションツール、UIデザイン用ツール、開発用ツール、バグ管理用ツールが基本的に使用されていると思います。
今回テスト管理ツールが果たす役割は、主にスプレッドシートを活用しているテストプロセスに関する内容です。 小規模なチームである今の段階で、テスト管理ツールの導入を検討した主な理由(目的)は次の通りです。

理由1:改善したい点があった

  • テストケースのテスト進捗を把握するためにデータ欄を設け、複雑な計算式を入れたり、そのデータを用いて視覚的に把握できるようにグラフを別途作成していた。
  • 過去のテスト実施実績が増え、フォルダ管理によってテストケースが埋もれ、再利用しづらい状況になりつつあった。
  • 複数のプロジェクトのテスト状況を把握する場合、成果物が管理されているフォルダ毎にテスト進捗状況を確認するため、状況把握と管理に時間と手間がかかる。
  • テストケースの進捗状況をQA以外のプロダクト関係者が確認する際、視覚的に把握しづらい。
  • テスト報告に必要な進捗データは、報告書用に進捗グラフを活用するなど実施者の報告に負担があった。

理由2:テストコントロールにおけるメリットがあると感じた

  • テスト管理ツールを使用することで、今までスプレットシートの活用スキルに掛かっていた時間を、テスト実行やコントロールへ集中できる。
  • テスト管理ツールでのテスト運用経験を得ることで、QAエンジニアのメンバーが今後他の分野で、QAチームの立ち上げやツールの選定を担う状況になった時、管理ツールを導入するメリット・デメリットを考慮した判断ができる。

理由3:スプレッドシート運用に限ったメリットが少ない

  • 複数人で同時に作業ができる
  • 共有がしやすい
  • 必要な計算式の追加、フォーマット変更などのカスタマイズが容易
  • 導入費用がかからない

これらの理由を含め将来的なQAチームの拡大を考慮した時に、現時点からテストに関するナレッジをテスト管理ツールに蓄積した状態の運用に切り替えていく必要があると考えました。 そこでテスト管理ツールの代表的なものをいくつか調査してみた結果、UIが直感的で使用しやすいと感じたPracti Testを試験導入してみることにしました。

ツールの主な機能は次の通りです。

  • 要件定義から、テスト作成、テスト実行、課題管理、進捗管理、報告まで品質管理に必要な機能
  • カスタマイズ可能なダッシュボード
  • Jenkins、Selenium、Git、Jira、Eggplantなどの外部サービスと連携が可能

テスト管理ツールには多様な機能がついています。
導入に際して、以下のルールで試してみることにしました。

  1. incidents の管理は従来通りJIRAで行う。テスト管理ツールには連携しない。(テストフェーズの準備+実行にフォーカスする)
  2. タスク管理もJIRAで行う。((従来通りJIRAのスプリント機能を活用)
  3. テスト管理ツールでは主に、ダッシュボード、テスト観点の作成、テストケースの作成、テスト実行の機能を活用するものとする。

上記運用にすることで、テスト管理ツールに必要なアカウントはQAエンジニア+管理者のみが所持すれば問題なく、最小限のコストで管理・運用ができます。ダッシュボードやレポートをQAエンジニア以外の社内メンバーに共有したい場合は、共有用のURLが発行できるためアカウントが無くても詳細確認が可能です。

導入準備と導入

テスト管理ツール導入のスケジュール

テスト管理導入スケジュール
※こちらは例であり実際の実施期間とは異なります。

導入にあたってはいくつかの段階を踏んで行いました。
実際にツール上で行う作業は次の通りです。

テスト管理ツール上で行う作業の流れ

最初からテストフェーズにこの全ての工程を、実行するのは負荷が高いと感じました。そこで最初はリグレッションテストの稼働期間に絞って実施することにしました。 リグレッションテストの実行をツール上で行うことで、メンバーにツールの使用感をフィードバックしてもらうことができると考えました。

以下の流れで導入を進めていきました。

  • 準備テスト管理ツールのフィルタールールなどを決める。QAエンジニアが実際にテストフェーズで使用する機能について、その実行順にテスト管理ツール上での操作ナレッジを作成する。

  • 学習リグレッションテストケースのインポート方法と、テストセット(実施するテスト項目の集まり)の作成、リグレッションテストの実行方法に限定してメンバーにツールの使用方法を共有。

  • 1回目:ツール上でリグレッションテストを実施。

(目的)一旦メンバー全員がツールの使い方に触れるタイミングを作る。 ツール使用上の疑問と改善点をあげる。

  • 1回目終了、改善期間:フィードバックされた内容から、ツール上の表記の仕方や運用上のルールの見直し。

  • 2回目リグレッションテスト実施。

  • 2回目終了:改善点が出なくなったことを確認する。プロジェクト毎のテストフェーズでツールを導入してみることにする。

  • 学習(テスト実行部分以外):テスト設計部分に関するツール使用方法に関して、QAエンジニアに説明を行う。

  • 3回目以降:一連のテスト活動をツールを活用して行う。各QAエンジニア全員がプロジェクトアサインのタイミングでテスト活動の一連の流れを、ツールで実行してみることを優先とした。

上記の段階的な導入によって通常のテスト稼働の中で、混乱はなく通常稼働にのせることができました。

導入してどうだったか

肌感でしかお話しできないのですが、今後のQAチーム拡大を視野に入れたときに、今回のツール導入は結果としてメリットはあったと感じています。
導入するにあたって、考慮しておくべきポイントがいくつかあるなと感じました。

導入におけるコツ
  • パイロット的なプロジェクトもしくは、テストプロセスの一部工程から導入するなど、なるべく小さい単位で段階的に導入を進めるのが良い。
  • テスト用(架空)のプロジェクトを作成して、管理ツール上で操作しながら覚える状況を作る。
導入にかかるコスト
  • アカウント料金(どの範囲の人までが実際にツールを使用するかで切り分ける。閲覧だけならアカウント不要のケースもある。)
  • ツール内の構成ルール決め、ナレッジの作成、教育&学習時間など、お金以外の部分でのコストが必要。導入して課題が解決できるツールではないという認識は必要。
なんの課題を解決したいかを明確する
  • テスト作業のコストを減らせるか?
  • やり方次第だと思いますが、テストケース作成の部分において100ケース以上のテストケースを作成するレベルだと、ツールで直接テストケース作成を始めるよりもスプレッドシートやエクセルでテストケースを作成したものをインポートする方が、作業効率的には良いです。既存のテストプロセスの作業工程の工数は減らないことの方が多いと思います。
テスト進捗の報告コストは減らせるか?
  • ダッシュボードの活用によって、視覚的に確認しやすくなりました。報告におけるコストは減ると思います。報告自体のコストは現在、レポートにダッシュボードの画像を添付し共有用URLに記載するようにしています。
ダッシュボード例>

ダッシュボード例
そして導入してみてまだ短期間ですが、テストにおける現場の変化は少しずつ出てきているように感じます。

  • リアルタイムでテスト進捗の状況が見られる。(管理者的には嬉しい)
  • ダッシュボードの活用で、テスト報告が楽になった。
  • どのテストでどのような不具合が検出できているかを確認しやすくなった。
  • テスト要件と要件に関するテストカバレッジが分かりやすくなった。
  • テストにおける再利用しやすさを考えるようになってきた (ここは、まだまだ。これからの期待値も含む)

ツールの導入は完了したので、現場レベルで今後これを更に有効活用していくことが次の目標です。 こういった現場でのテストプロセスの改善や、テストアプローチの精度を高めることに能力を発揮し、自走しながら活躍ができるQAエンジニアをKyashでは募集しています。

QAエンジニアの募集はこちら herp.careers

導入準備で行った作業

実際にテスト管理ツール導入の準備で行った作業について、参考程度に触れておきます。テスト管理ツールの種類によっては細かい機能は異なると思いますが、同じような作業が発生すると考え参考になれば幸いです。

テスト管理ツールの構成を決める

管理ツールを使用するには、ツール内の構成管理をどうするかを決める必要があります。 決めるタブは次の3つですが、タブ毎のルールは共通にした方が管理しやすいので、一つルールを決めれば良いです。

  • 要件タブ:テストフェーズでいうテスト観点を作成するところ
  • テストライブラリタブ:テストケースを登録(インポートor 作成)するところ
  • テストセット&実行タブ:テスト実行する単位でインスタンス(テストケースのこと)を管理

ここでいう構成ルールとは、フォルダ構成を決めることに相当します。 テスト管理ツールではこの構成を「要件」「テストライブラリ」「テストセット&実行」の各タブごとに「フィルター」で管理します。

フィルターの役割

  • 各タブ毎の構成ルール決めるもの
  • ダッシュボードに表示する元データとなるもの

フィルター=フォルダと考えた時、そのフォルダにはどの条件の「要件」「テストケース」「テスト結果」を表示(格納)するのかを決めるのが、フィルターの検索条件項目である「カスタムフィールド」です。

「要件」「テストケース」などを作成する時に、カスタムフィールドを正しく設定することで、該当フィルターの条件とマッチングした結果として表示することができます。

ここでは要件タブのフィルターを例にあげています。リリースする単位毎のバージョンでフィルターを作成し、そこに紐づくカスタムフィールドをフィルター毎に設定し、該当する要件が表示されています。

同じ要領で「テストライブラリ」「テストセット」でもフィルターを作成します。

条件フィルター

テスト運用に合わせていたツールの使用ガイド ((ナレッジ)の作成と、導入操作の説明

構成ルールが決まったらツール上の運用方法を、テスト設計者、実施者が実際に使用する流れに沿ってdoc.に整理しました。
実際に担当者が使用する機能は決まっているので、そこを明確にしておけば新メンバーが増えた時にもすぐにツールが使用できます。
初めてのツールを使用ガイドだけで把握するのはストレスが高いので、実際に担当者が作業を行う日程に合わせて、作業日の直近でツールの使用説明を実施しました。 説明後は管理ツール上にテスト用の架空プロジェクトを作成し、該当のプロジェクトでフィルターの作成、要件の紐付け、テストケースの追加などの動作を行い確認、不明点はナレッジも活用しながら実際にやってみることで理解を深めました。

Doc.で作成したナレッジの一部です。

テスト管理ツール操作詳細のナレッジ

テスト管理ツールのフローについて

テスト管理ツールのフロー

ツール活用によって新しく課題が生じ改善したお話しに触れる前に、テスト管理ツールのフローと用語について記載しておきます。 ここでは、インスタンス(instances)という馴染みのない言葉が出てきます。テスト管理ツールでは一般的に使用される用語のようです。フローの中に出てくる用語の意味は以下のイメージです。

  • テストライブラリ:テストケースを入れる箱。全てのテストケースが集まっているところ。
  • テストセット:テスト実行時には、テストライブラリの中にあるテストケースを選択する。実行対象のテストケースとして選択したものは、インスタンスと呼ばれます。そのインスタンスの集まりがテストセットになります。
  • ラン(Run)インスタンスの実行結果。テスト実施では、同じテストインスタンス(インスタンス)を2回以上実行することがあります。よってインスタンスのカウントは以下のようになります。

    • 「実行前のラン数=0。」
    • 初回実行で結果がOKその後も問題がなければ、「終了時のラン数=1」
    • 初回実行で結果がOK→その後エンバグにより失敗した場合、修正確認で再実行で 『終了時のラン数=2」になる

既存のテストケースをツールにインポートできるフォーマットに変更する

既存のリグレッションテストケースは、スプレッドシートで運用していました。 これをそのままインポートすることはできません。まずインポート用テーブルフォーマットの形式に直す必要がありました。そして限られたフォーマットの表現の中に、既存のテストケースの特徴をどう生かすかを考える必要が出てきました。

既存のテストケース

既存のリグレッションテストケースの特徴
  • 「No」と「セグメント」で、続けて実行する項目かどうかと実行しやすい順番を明記。
  • 「カテゴリ」「対象画面・機能」「画面内エリア」で確認する対象機能を明記。
  • 「事前条件」にはテスト実施時のアカウントの状態を記載。
  • 同じアカウントで実行できるものは、「ユーザー」欄にアカウント種別を記載することで明記。
  • テスト時に必要なテストデータの情報は、「詳細情報」に明記していた。
  • Android/iOSで実施し、一部のOSで実施しないとした項目は結果に予め「N/T」を入れて処理していた。

スプレッドシートのテスト項目を、インポート用のテーブルフォーマット(横長の項目を縦に続けて表示しています。)に反映したもの。

テスト管理ツールテストインポート用フォーマット例

テスト実施で出たフィードバック結果と改善

テストケースをインポートし、初回のテスト実施(1回目のリグレッションテスト)を実際にしてみると、実務上での細かな改善点要望がいくつかでてきました。フィードバックされた意見と改善した内容は次の通りです。

  • テストセットを実施端末毎に分けて作成した。しかし、実際には複数端末で確認が必要な項目があるのでこのやり方だと実施条件が不足した。
    • 改善:テストインスタンスのカスタムフィールドにある、端末とOSの詳細をテスト実施者が実施の時に選択することにした。このやり方にした理由:何かのOS条件である場合。同じOSでも実施者でも持っている端末が異なる。などの実施かでの細かな条件指定が難しかった。

テストインスタンス(テスト項目)には以下のように、カスタムフィールドを表示させ選択することも可能です。

カスタムフィールドの選択

  • テストインスタンスの確認に、1端末で完結できる内容と、2端末以上必要な内容があった。
    • 改善:確認する対象端末毎に、テストセットを分割した。
  • どのアカウントで操作するかがわからなかった。

    • 改善テスト管理ツールのテストフォーマットには、既存のテストケースにあった「ユーザー」欄に該当する項目が無かった。どのアカウントで操作するのか、どの端末で操作するのかを事前条件(Preconditions)に記載するようにした。
  • インポート用のテストケースフォーマットに、関数を使用していなかった。

    • 改善:関数を使用しても問題ないことが分かったので、インポート用のフォーマットのテストケースには、関数を使用して既存のテストフォーマットの項目を、インポート用フォーマットに変換するようにした。こうすることで、テスト実施手順などが実施者の目線で認識しやすいような記載で反映された。
  • 既存のテストケース(スプレッドシート)は、上から順に実施するとやりやすいように作成されていた。

  • スプレッドシートでテスト項目を作成していたときは、全体のテスト項目が一覧で見渡すことが可能でしたが、テスト管理ツールではテストセットの中に選択したテストインスタンスが一覧になって表示されます。

インスタンスを選択すると、ステップ毎の「説明」「期待結果」「実際の結果」のテスト詳細が確認できます。詳細をみるのには、階層になるという点が従来のスプレッドシートとは異なる点でした。 スプレッドシートのテストケースで、続けて確認する項目はセグメントを利用して1〜3などの手順を振っていました。ツールではインスタンスの中のステップとして記載されることになります。

  * この場合「事前条件」がステップ毎には記載ができないので、該当のインスタンスのPreconditionsの欄に、該当のステップに関する事前条件をまとめて記載するようにしました。

テストインスタンス詳細

実際にツールを導入するにはある程度準備期間と、テスト管理ツールの仕様に合わせた軽微な改善や工夫をする必要が出てきます。
小さく始めれば、決して難しくはありません。より良いテストマネジメントの参考になればと思います。

おわりに

Kyashではエンジニアの皆様を募集しております。 カジュアル面談も随時募集中です。 是非以下のリンクをご覧ください!

QAエンジニア募集中はこちら! herp.careers

SET募集はこちら! herp.careers