はじめに
はじめまして！株式会社ビットキーの三上です。
私は現在QAエンジニア兼テストエンジニアとして、ローコードテスト自動化ツールであるmablを用いたリグレッションテストの自動化を主に行なっています。
今回は自動テスト作成に関する業務を行う過程で得た知見の中から、
Echoステップを利用したテストケースのフォーマットを作ることで自動テストの可読性を向上させる方法についてご紹介します！
対象読者
- mablで自動テストの作成を行なっている方 *特にチーム単位で作業されている方
この記事を読むことによる価値
- 自動テストの可読性を向上させ、メンテナンスにかかるコストの削減および心理的ハードルの低減を行うことができる
自動テストに関する私のチームでの取り組みについて
自動テストは作成して終わり、ではなくプロダクトのリリースに合わせて自動テストを実行して結果を確認したり、機能に改修が入った際は自動テストが成功するようにメンテナンスを行う必要があります。
私のチームではこれらの作業は複数人で分担して行なっているため、「Aさんが作ったテストをBさんが実行orメンテナンスする」といったことは日常的に発生しています。
※補足：コストだけ見れば作った人が実行する方法が最も時間効率が良いですが、知識が特定のメンバーに依存しないようにするためこのような方法を選択しています
自動テストの可読性の低さによって生じた課題
自動テストの作成に取り組みはじめた初めの頃、テストケースのフォーマットが定まっていませんでした。
そのため他のメンバーが作成した自動テストに触れる際に下記のような状態のものを見ることがしばしばありました。
r0ku. 自動テスト歴0年でもできる！テスト工数を46時間/月削減した方法 ～1年目で得られた成果と展望～[スライド93]. Speaker Deck. 取得元: https://speakerdeck.com/r0ku/developers-summit-2024-zi-dong-tesutoli-0nian-demodekiru-1nian-mu-dede-raretacheng-guo-tozhan-wang?slide=93
このような状態だと「このテストステップは必要なものなのか」「期待値となるテストステップはどれに当たるのか」など手を加えるために必要な情報を把握することが難しく、結果メンテナンスというプロセスに対するコストおよび心理的ハードルが大きくなっていました。
課題に対して行なった可読性を向上させるための取り組み
上記の件から「自動テストは作成後も継続的に触れるものである」ということを改めて認識しました。
またメンテナンスに関しては継続的に行う必要があるプロセスであったため、コストがこれ以上膨らまないようにするために早急に改善に取り組む必要がありました。
いくつか試行錯誤を重ねた結果、可読性を向上させるための方法の1つとしてテストケースのフォーマットを作ることにしました。
これによって心理的なハードルは大きく下がり、またメンテナンスに要するコストも比例して下がったと実感しています。
r0ku. 自動テスト歴0年でもできる！テスト工数を46時間/月削減した方法 ～1年目で得られた成果と展望～[スライド100]. Speaker Deck. 取得元: https://speakerdeck.com/r0ku/developers-summit-2024-zi-dong-tesutoli-0nian-demodekiru-1nian-mu-dede-raretacheng-guo-tozhan-wang?slide=93
テストケースのフォーマットを利用する中でチーム内で意見を募った結果、何回か改良を重ねる機会がありました。
そこで今回は現在進行形で私のチームで利用している最新のフォーマットを紹介します。
自動テストの可読性に関して課題に感じている方の参考になると嬉しいです！
テストケースのフォーマットの作成方法
- テストケースのフォーマットとして必要なものを決定する
- 手順1のフォーマットをEchoステップで見出しとして作成する
- 新しくFlowを作成し、手順2のEchoステップを格納する
- テストケースを作成する際に手順3で作成したFlowを呼び出す
1. テストケースのフォーマットとして必要なものを決定する
まずはテストケースのフォーマットとして必要なものを決定します。
私のチームではmablで自動テストを作成する際、下記の項目をテストケースのフォーマットとして定めています。
- 項番・・・リグレッションテストのどの項番と一致するかを確認
- テスト観点・・・該当のテストで何を確認したいかを確認
- 前提条件・・・データ作成や画面遷移など、手順を行う前に整えておくべき条件を分類
- 手順・・・環境が整った状態で行う操作を分類
- 期待値・・・手順を行った結果起こるべき事象を分類
- 画面・データの初期化処理・・・期待値を確認した後、不要なデータを削除したり特定の画面に遷移する必要がある操作を分類
正式なテスト仕様書に沿った場合項目の数はもっと多くなりますが、ここで私たちが重視しているのは「メンテナンスを行う際に自動テストが手を加えやすい状態になっていること」です。
テスト仕様書としてmablは利用していないため、項目数を削り自動テストのメンテナンスに特化したつくりにしています。
プロダクトの性質によってmablの使い方は変わると思うので、自身の利用状況に適したテストケースのフォーマットを用意するようにしていただくと良いと思います。
2. 手順1の型をEchoステップで見出しとして作成する
テストケースのフォーマットが決まったら、各項目をEchoステップで表現します。
私のチームではEchoステップは注釈として利用することもあるため、区別できるようにテストケースのフォーマットとして利用するものには絵文字を先頭に付けています。
必要に応じてお好みでつけてみてください。
※Echoステップの概要・作成方法に関してはmablの公式ドキュメントをご確認ください
mabl. Echoステップ.mablヘルプ.https://help.mabl.com/hc/ja/articles/19078175250324-Echoステップ
3. 新しくFlowを作成し、手順2のEchoステップを格納する
ここは特筆することはありません。手順2で作ったEchoステップを新しく作ったFlowに格納します。
テストケースのフォーマットを作る手順としてはここまでで完成です！
最後にFlowの呼び出し方と実際の使い方の例を見ていきましょう。
4. テストケースを作成する際に手順3で作成したFlowを呼び出す
最後に使用する際の使い方を説明します。
といってもやることとしては手順3で作成したFlowを呼び出し、フォーマットだけ残してFlowを削除するだけです。
あとはテストステップの作成をフォーマットに沿って進めていけばOKです。
最後に
いかがだったでしょうか。
チームで自動テストの作成に取り組む際、自動テストが読みやすい状態になっていることでメンテナンスを行うことに対するコスト及び心理的ハードルは大きく下がります。
この記事を読んでいただいた方の一助になればとても嬉しいです。
ご精読ありがとうございました！
Discussion