はじめに
2025/03/25(火)に、QA Test Talk Vol.4に同僚QAエンジニア経由でtarappoさんからお招きいただき、登壇してきました。
登壇内容について、お話しできなかった内容を補足しながらつらつら書いておこうと思います。
主にQAエンジニア向けの記事なので、一部QA業界の用語が出てきます。そこはご容赦くださいね〜！
ちなみに
登壇前の週末にぎっくり腰をやらかし、壇上でクネクネしながらの登壇でした。録画がなくてよかった。アラフォーこわいな〜〜〜
スライド
こちらです。 speakerdeck.com
さあ本題
タイトル
「みんなでテストする」ということの重要性については理解されている方も多い？のでは？と思っています。
でも、「みんなでやる、ってどうやるんだよ〜」と思っている方々も多いと思います。なので、「みんなで」というところから内容を組み立てました。
私は一人目QAエンジニア(しかもQA初心者)としてJOINして、まずぶち当たったのがQAエンジニア一人で開発エンジニアに向き合うのは無理だ！！！ということでした。
なので、とても消極的な理由で、「みんなでテストする」しかない、と思ってQAエンジニアとしてのキャリアをスタートしたんです。
とはいえ、開発エンジニア経験から、開発者も事前にテストをしたい・知っておきたい、というのは理解していました。
「実装前後の自動テスト」
本当にシフトレフトしようと思ったら、ビジネスサイド(PdM)とのテスト(仕様レビューなどですね)が重要です。
しかし、リファクタリングできていない、現状動いて(しまって)いるプロダクトのテストだと、そうはいかないケースが多いです。
ということで、「まずは開発エンジニアにテストを作ってもらう」ことから始めています。
特に現在は内部の構造改善について、開発エンジニア主体でテストを作ってもらっています。
という意味でスコープを絞ってお話ししました。若干の逃げですね〜。
思想
開発エンジニアやってたときから「最後にテストするのおかしくない？」と思ってたのです。特に前職の組み込み系のテストはひどかったので…！ (そのうち記事にしよう) 開発エンジニアが実装してんだから降りてきた仕様は知ってるはずだし詳細仕様も知ってるんだからテスト作ればいいじゃん、というところです。
あと「最後の砦」というのは本当にキライです。孔明がいなくても負け戦だとわかる。
頓挫と再構築
自動テストにおける最重要(だと思っている)な部分は、いかに被テスト状況を生み出せるかということです。それを初期データで生み出すことができれば、テスト自体は容易に実施できます。
個人的な感覚では、BDD的にいえば、Givenが8・WhenとThenが各1くらいです。
テストが遅い・再実行できない・メンテナンス性が悪い、というのは結局この初期化ロジックによるところが大きいです。
初期データは主にDBへのinsertになりますが、固定IDでの操作は並列化・再実行と非常に相性が悪いです。
そのため動的にテスト対象環境を生成するようにしました。動的に"閉じた"環境を都度作成することで、強烈に並列実行でき、FlakinessのせいでFAILした場合はリトライできるようにしています。これもそのうち記事にします。
ここ5年間
ATDDもTDDも以前からあったはずですが、ここ数年で普及した印象です。もはや「アジャイル開発でないのはダサい」という風潮になってきているから？でしょうか。5年ほど前はそこまでではなかった気がします。
ウォーターフォール開発であれば不確実性を許容しないので、ATDD・TDDの恩恵はあまり受けられませんからね〜。
本当にやるべきだったこと
開発者体験(DX)の向上は、5年前には全く勘案できていませんでした。反省点でありつつも、まあしょうがないよな、と思っています。
テストを作ることが重要で、どう実行するか？どうFAILを拾うか？まで考えられていない、ということは今でもそれなりにあるはずです。
また当時は私自身CI/CDの重要性がそこまで腹落ちしていませんでした。自動で全て実行されることのとんでもない強力さは実際に作って使ってわかる部分も大きいのではないかと思います。実際に体験するからこそDXが向上できる、と確信しています。
自動テストの好循環
自動テストが作りやすいこと
ここはどこに重点を置くか、というところで「作りやすい」は変わります。
今はGauge(テストランナー)と、マニピュレータとしてPlaywright(UIテストツール)・Axios(RESTAPIクライアント)を使用しています。この構成、実は開発エンジニアとしては作りやすくはないです。あと多分AI類にも作りやすくないと思います。
開発エンジニアが作って実行するならコードベースのものが最適です。AIに任せたい場合もそうだと思います。
私としては、最終的には「ビジネスサイド(PdM)とレビューしあいながら仕様を具現化しながらテストを作れるようにする」ことを目標としているので、ヒューマンリーダブルなmarkdown記法で書けるGaugeが最適だと考えています。
他にも、Gherkin記法で書けるCucumberなどもあります。テストするストーリーが十分小さければ、Gherkin記法の方が書きやすいかもしれないです。
そして、ここでももちろん、「初期データが作りやすいこと」という観点が重要です。
かつてCSVでデータを用意することも試しましたが、リレーションをIDでたどる他なく、メンテナンスが困難でした。
現状はTypeScriptのファイルです。シャローなクエリビルダーを用意して、insertしたレコードのIDを返し、他のテーブルのレコードにセットできる仕組みにしています。
作ったテストが実行されること
本当にやるべきだったこと、で出てきたCIの話です。
テスト実行自体は通常コマンドライン一発だと思います。なので、実際には被テストプロダクトの実行環境構築とそこに向けたテスト実行環境の構築です。
コンテナ化してあるプロダクトであれば、ECSでもEKSでもいいですし、GitHubホステッドランナー内でも動かすことができると思います。
もしコンテナ化していなかったとしても、それ用のEC2インスタンスを立てるなど、やりようはあります。
「コスト的にどうなの？」と思わなくもないですが、不具合が出て1レーンで半日費やすよりよっぽど安いです。
また、「おもしろそうなおもちゃ」のような環境であることも大事です。個人的にはCI環境を「ピタゴラ⚪︎イッチ」と呼んでいます。
ピタゴラス⚪︎ッチの、目覚まし時計が鳴って、おもりが落ちて、なんかゴウンゴウン動いて、パタっと旗が立つの、なんだかワクワクしませんか？？
そんな感じで、「動いた！」と思えることが大事です。開発エンジニアの快感のひとつは、実装したものが「動いた！」ときなので！
実行され続けること
何度でも言いますが、動いていないテストは害悪でしかないです。
動いていないと勝手に腐ります。中途半端に資産なので簡単に捨てられません。
そして、FAILしたら「そりゃそうか」ですし、PASSしたとしても「これはテストとして正しいのか？」と疑心暗鬼になります。そんなテストに何の意味もありません。
あと、「ローカルで実行してください」は誰もやらないですし、commit等でhookしてローカルで強制的に実行するのもbadです。commitするたびに待たされたい人はいないです。アジリティも爆下がりです。
というわけで、マトモに自動テストを回しておくためには、やはりCIは必須だと思っていいと思います。
次なる課題
「もういつでも自動テスト作れる！」という状態になったからこそ、見えてきたものがあります。
開発者が自動テストを作れるようになると、今動いているプロダクトについては、まず「内部のロジックに沿って」テストを作ることになると思います。
基本的に最初はAPIテストにとどめておくのがベターです。APIテストなら高々数秒で1シナリオ終わりますし、Flakinessもないです。
逆にUIベースのテスト(E2Eテスト的)は数分かかることもありますし、正しく作らないとすーぐFlakyになります。作らないと確認できないことについては作ってもいいんですが、最低限のストーリーにしておいた方がいいです。そこも初期データでうまく作るのがコツです。
テストの信頼性を保つには、QAエンジニアによるテスト分析・計画・設計のノウハウが必要になります。そこがQAエンジニアのスペシャリティだと思っています。
新規にフルスクラッチで作れる場合は、あらかじめQAエンジニアを交えてテスト計画をしておけば、大きくズレることはないかな？と思います。楽観的かもしれませんけどね…。
全体最適化は、現在ちょうど悩んでいる部分です。テスト関連語彙のユビキタス化から始めています。
シフトライトっぽい文脈については、やはり測定をするところからになるだろう、と考えています。
比較的取りやすいのはコードカバレッジですが、開発エンジニアにテスト作成を促す契機にはなると思っています。ただカバレッジを上げればよいわけではないですが、テストできていない部分を明確にしてテスト作成を促す効果はあるだろうと推測しています。
今進めつつあるのは、CREチームと連携し、利用率・不具合率・対応工数などを取得して、その部分を厚くテストする・修正するようなことです。
偉そうに言っていますが…まだなーんにも見えていません！
包括的にテストせず開発するのはダサい、というのは、アジャイル開発の隆盛と共に少しずつATDD・TDDが普及していったのと同様に当たり前になっていくといいなあ、と思っています。仕様など早くから、モニタリングなどずーっと、テストし続けることが最適なプロダクトを作る最短経路ですからね〜。
いかがでしたか？
15分枠のLTだったので、話せることは限られており、色々書いたらこんな分量になっちゃいました！まあいいか！
私が体験して頓挫しまくったことを他のみなさんには経験してほしくないな〜と思ってるのは確かです。
自動テスト取り組んでみたいとか、始めてるけどまだみんなでできてないとか、十人十色有象無象な状況だと思います。
役に立つかどうかわかりませんが、「こんな経験をした人がいた」くらいでも役にたてば幸いです〜！
