📝

アジャイル開発でジワジワとテスト自動化を進めた話

2023/05/14に公開

Python

Bash

tech

LTで使用したスライドです

前提

プロダクト：Webアプリの標準開発
チームメンバー数：6〜7人
チームメンバーの作業：定義済の要件から製造して統合テスト完了まで
プロダクトの特徴：システムはモノリス構造。ユニット、コンポーネント単位でのテストの自動化は厳しい。
またユースケースが多く、パターン毎の仕様も複雑でドキュメントが詳細に作られていない。

ざっくり経緯

以下のようなユースケースを手動のE2Eテストで実施していた。
「注文」→「契約開始」→システム日付変更→バッチ実行(契約更新)→...
「注文」時の単純な入力条件(例えば「契約開始タイミング」「請求出力タイミング」「更新タイミング」)の組み合わせに対し、任意のタイミングで「注文数量変更」「金額変更」等の動作を行う為、時系列的にも組み合わせを網羅する必要があった。

序

ワイ「結合テスト手動なんキツイな。重いとこだけでもちまちま自動化しとこ」(スライドのStep1~3)

破

メンバーA「ここの改修テスト工数がヤベぇ！」
ワイ「そこツールで消化できるからこっちでやるで～」
メンバーB「すまんこっちも頼むわ」
メンバーC「よろ」
ワイ「ヒィ！」
ワイ「項目表からシナリオ生成できるようにしといたから、各々で自動テスト回して！」(Step4)

Q

ワイ「どうせやったら主要なテストなるべく出来るようにしとくか」
ワイ「(項目数)デカすぎんだろ......保守運用チームにお客さんの使用状況聞いて優先度付けとこ」(Step5)

注意した点

ツールの信頼性

ツールによるバグはもちろん、ツール実行による自動実行と手動によって結果に違いがないかは定期的に確認。特にチーム内で正式に導入されるまでは、自身のテスト範囲で手動テストをやりつつ、自動テストでも同様の結果が得られるかを確認することでツールの信頼性を担保していた。

製造者が「コードレビュー前にサッと実行」を目標

Step4以降は開発プロセスに絡むことを想定して、ツールの機能追加だけでなく使いやすさも意識して改善してきた。例えばスプレッドシート200行分くらいあった環境構築手順を徐々にスクリプトに埋め込んでいって20行程度にしたり、使用頻度の高いシナリオ群をツールに内包して引数指定できるようにしたり。このツールのユーザーストーリーとして 「コードレビュー前にサッと実行」 を目標に、最終的には シナリオを引数指定して1コマンドで実行できる状態にした。

偽陰性について展開

ツールの特性上、差分が出るべきだが出ない場合、つまり偽陰性の検出は難しい。これは割とどうしようもなかったので、エンジニアには 「差分のチェックだけでなく、変更・改修内容から重要な項目はある程度めぼしをつけて、差分の有無をチェックしてほしい」 と展開しつつ、自分からも重要なチケットは設計やコードレビューに参加して、めぼしをつけて確認をしていた。

使わなかったE2Eテストツール

Autify,selenium,seleniumIDEも検討したが没。詳細は以下の記事にまとめた。

所感

1. 誰が使うかを意識して自動化するのが大事

最初はbashとかpythonスクリプトに直接シナリオ書いてたけれど、やはり理想は「製造した人がその機能を担保する」なので、いずれは自分以外が使うことを想定して作るのがよいと思う。

2. 半端なツールは展開しないほうが良い

とはいえ他の人に展開する前提でいきなりツール作り始めるのはハードルが高い。
今回作ったテストツールを他メンバーに展開する際には少なくとも以下の情報を正確に伝える必要があった。

・使用できる条件(環境やバージョン等)
・対応範囲(実行可能なシナリオ)
・実行手順
・出力(何が実行、確認、担保できるか。OK/NG、差分、スナップショット等)

他のメンバーに 「そのテスト、ツールで確認できるよ！はい手順書！」 と言っても、まず 「ちょっとよくわからない……」 となり、対面や通話しながら解説する工数が発生する。
さらにツールに未完成部分がある場合は手順書に
$\textcolor{red}{※条件〇〇の場合は使用できません！}$
とか

とか目立つように記載することになる。そして大体読み飛ばされて問い合わせ→調査コース
「こんなことなら未完成部分作ってから展開すればよかった！」 と後悔することが多かった。

3. 開発チームの認知負荷を下げる経験を得られた

全網羅シナリオは最終的には2000項目程度に膨れ上がったが、比較的可視性の高いスプレッドシートでひとまとめにしていたことと、そこから選択した項目をワンクリックでシナリオ出力できるようにしていたことで、開発者が 「ここ直したらNoXXに影響あるな」 と見込みを付けれるようになってゆき、さらにはコードレビュー前にテスト実行しておいてで 「影響ありそうなNoXX~YYは確認済みです」 とレビュアーに対する意思疎通が捗ったり。
理想は 「人間の認知限界を超えるような仕様、設計はしない」 なのだろうけれど、IT業界で働く以上は技術的負債と向き合い続けなければならないので、それに対する一つの回答を得られたのはとても良い経験だった。