MagicPodのテストケースをチームで管理するための工夫

はじめに

MagicPodのコミュニティで「誰が見てもわかりやすい工夫、何してる？」といったテーマで各自の経験を共有する企画がありました。せっかくの機会なので自分の経験を記事にしてみました。
「今年は技術記事書こう!」と思いつつ踏み出すきっかけがなかったので、企画を立ち上げてくれたMagicPod社の方に感謝です。

本記事では、私なりに実践してきた「MagicPodのテストケースをチームで管理するための工夫」についてまとめています。

MagicPodをどのようにプロジェクトで利用しているか

参画しているプロジェクトでは、PM・dev・QAと大きく3つロールがあります。そして、QAチームがMagicPodを利用してE2Eテストを行なっております。QAチームが行うE2Eテストは基本的に全てMagicPodで行なっており、テスト対象の画面数は30画面以上、作成したテストケースは気づけば900ケース近くになっています。

チームでテストケースを作っていくときの問題

チームでテストケースを作る場合、以下のような問題があります。

1. どんなテストケースをどういった単位で作ればいいかわからない
   （＝作る人によってテスト内容が異なったり、１ケースあたりに詰め込むテスト内容がバラバラ）
2. 取り込み済みのUIや作成済みの共有ステップの存在が把握しづらい
   （＝同じようなUIや共有ステップが増え続ける。それによりメンテナンスしないといけない対象も増える）
3. MagicPodのテストケース一覧からはテスト対象の画面に対してどれだけテストがカバーできているか把握しづらい
   （＝他の人が見た場合にテストが十分なのか把握できない。上記の1（作る人によってバラバラ）と合わさると尚更）

工夫

上記の１〜３に対するそれぞれの具体的な工夫は以下の通りです。

問題１に対する工夫：テスト実装方針を作る

私のチームではテスト実装方針として、テスト内容とそれに対するテストケースの実装例などを社内のwikiにまとめています。
wikiの記述内容を順を追って説明します

1. 全画面で共有的に行うテスト項目を設定
2. 各テスト項目に対して検証する内容と検証しない内容を記述
   1,2までのwikiのイメージ（ 記述内容はあくまでもサンプルです ）

   テスト項目	検証内容	検証しない内容
   初期値	初期値が空白以外の場合、設計通りの初期値が設定されていること確認	初期値空白の項目は確認はしない
   桁数	各入力エリアが設計通りの最大桁までしか入力できないことを確認	入力チェックなどの処理がない限り最小桁の確認はしない
   ・・・
   データ登録、更新、削除	データが登録、更新、削除できることを確認	登録⇄削除を繰り返すような確認はしない

3. テストステップのイメージを記述
4. 実装サンプルへのリンクを貼る（1-3までの内容に沿ってMagicPodで実装したケース）
   最終的なwikiのイメージ

   テスト項目	検証内容	検証しない内容	テストステップのイメージ	実装サンプル
   初期値	初期値が空白以外の場合、設計通りの初期値が設定されていること確認	初期値空白の項目は確認はしない	step１：各項目の初期値を確認	リンク（xx画面の初期値のケース）
   桁数	各入力エリアが設計通りの最大桁までしか入力できないことを確認	入力チェックなどの処理がない限り最小桁の確認はしない	step１：入力エリアに最大桁以上の文字列を貼り付ける step２：想定通りの桁数に切り取られていることを確認 step３：その状態でデータが登録できることを確認	リンク（xx画面の桁数のケース）
   ・・・
   データ登録、更新、削除	データが登録、更新、削除できることを確認	登録⇄削除を繰り返すような確認はしない	step１：データを登録 step２：「１」のデータを更新 step３：更新後に値になっていることを確認 step４：データを削除	リンク（xx画面のデータ登録、更新、削除のケース）

実装方針のwikiを作るときに意識したポイント

• テスト実装方針のwikiは１ページにまとめている。テスト対象の画面は30画面以上あるがこのwikiだけ見れば、どんなテストをどんな単位で作ればいいか把握できる。
• 以下のような流れで作成
  テスト実装方針のドラフト版を作成　→　テスト内容が異なりそうな画面をいくつか実装　→　テスト実装方針の見直しを実施
• ルールを定めすぎると窮屈であるものの、新メンバーにとってはある程度ルールがあった方が嬉しい（迷いが減る）

工夫の１つ目であるテスト実装方針の説明は以上です。

問題２に対する工夫：命名規則などによるUIと共有ステップの管理

私のチームではUIと共有ステップの管理は結構気をつけています。（といってもそこまで難しい内容ではないですが）

UIの管理方法

• テスト対象の「画面名」単位でUI一覧のセクションを分ける
• UIの命名規則
  • ＄{画面名}_＄{用途やシチュエーションなどの説明}
    例
    　xx画面_初期画面表示：「xx」という画面を初期画面表示したときのUI
    　xx画面_エラーメッセージ：「xx」という画面にエラーメッセージが表示されているときのUI

共有ステップの管理方法

• 共有ステップの命名規則
  • ＄{画面名}_＄{画面操作内容}
    例
    　yy画面_登録：「yy」という画面でデータ登録を行う共有ステップ
    　zz画面_更新：「zz」という画面でデータ更新を行う共有ステップ
  • 特定の画面に限定されない場合は以下のようにする
    共通_＄{画面操作内容}

命名規則のポイント

• 命名規則の先頭は 人によって絶対に差異が出ない ものをつけるのが大事だと思っています
  • 私の例の場合「画面名」は人によって差異は出ない（※）のですが、＄{用途やシチュエーションなどの説明}、＄{画面操作内容}といった部分はどれだけ気をつけても差異が出てきます
    ※画面設計書からコピペするため
  • 人によって差異が出ないものの例
    画面名・画面ID・機能名・機能ID etc

UIと共有ステップを適切に管理できるかどうかが、テストケースのメンテナンス工数に大きく影響するので非常に大事な要素です。
工夫の２つ目の説明は以上です。

問題３に対する工夫：テスト対象の画面設計書にMagicPodのテストケースのリンクを貼る

MagicPodのテストケース一覧やテストケース内の情報からは、テスト対象の画面に対する実装状況（どれだけテストでカバーできているか）を把握するのは難しいと思います。
これはMagicPodだからというわけではなく、個別のテストケースの情報だけでは全体的な状況は見えづらいということです。この全体的な状況が見えづらいということに対する私のチームの工夫を紹介したいと思います。

• 元々のテスト作成のインプットや作業の流れ
  • devチームが作成した画面設計書（※）を参照しながらQAチームがMagicPodでテストケースを作成
    ※入力項目の桁数や初期値、画面上に存在するボタンやそのボタン押下時のイベントの概要などを記述したドキュメント
    画面設計書のイメージ（ 記述内容はあくまでもサンプルです ）

    画面項目	type	桁数	初期値
    入力項目A	textbox	10	空白
    入力項目B	textbox	10	xx
    登録ボタン	button	-	-
    削除ボタン	button	-	-

• 行った工夫
  テスト対象の画面設計書にMagicPodのテストケースのリンクを貼る

  画面項目	type	桁数 MagicPodへのリンク（桁数のケース）	初期値 MagicPodへのリンク（初期値のケース）	E2Eテストケース
  入力項目A	textbox	10	空白
  入力項目B	textbox	10	xx
  登録ボタン	button	-	-	MagicPodへのリンク（登録のケース）
  削除ボタン	button	-	-	（リンクを貼っていない状態）

  • 上記設計書の見方
    • E2Eテストケースの列に各画面項目に対して検証を行なっているテストケースへのリンクを貼る
      • 登録ボタンはテストケースへのリンクが貼られているので、テスト実装済み
      • 削除ボタンはテストケースのリンクが貼られていないので、テスト未実装
    • 桁数、初期値などは１ケースで全画面項目の検証を行うため、E2Eテストケースの列ではなく、桁数、初期値の欄にリンクを貼る

画面設計書にテストケースへのリンクを貼った狙い

• 普通であれば、画面設計書　→ テスト仕様書（※）　→　MagicPodのテストケース　と成果物を作っていくかなと思います
  ※画面設計書とMagicPodのテストケースを繋げる役割
  それに対して、私のチームでは画面設計書　→ 　MagicPodのテストケース　としています。
• これがベストなやり方ではないと思いますが、以下のようなメリットが得られます
  • テスト仕様書作成・メンテナンス工数がゼロになる（３０本以上の成果物の工数がゼロになる）。
    ※個別のテスト仕様書を作成しない代わりに、工夫１で紹介した「テスト実装方針」を充実させることが大事
• また以下のような副次的な効果も生まれました
  • 画面設計書を見ればdevチームもテストの実装状況が把握できる（テスト仕様書のように別成果物とした場合、devチームが見る機会が減る）
  • リンクをクリックすることでdevチームもテストケースをすぐに見れる（画面設計書とMagicPodのテストケースの紐付きがわかりづらい場合、devチームはテストケースにたどり着けない）

まとめ

MagicPodを上手に活用していくためには「チームでテストを管理する工夫」は必須だと思います。記事の内容は少し細かすぎてわかりづらい部分も多かったかもしれませんが、少しでも誰かの役に立てればと思い書いてみました。
ちなみに個人的な記事の投稿は今回が人生初です。MagicPodに限らず今後も定期的に記事を書いていきたいと思います。