koma です。
第24回Ques「はじめてのテスト自動化」に現地参加してきました！
こういったイベントは初めてで緊張していましたが、参加してよかったと思える素晴らしいイベントでした。komaの理解の範囲ですが、忘備録も兼ねてまとめてみようと思います。
以前ハマログで「テスト自動化の素朴な疑問を調べてみた」を執筆した際にざっくりとは調べていましたが、実体験の話もヒヤリングでき、得るものが多かったです。
講演内容：はじめてのテスト自動化 （日本電気株式会社SI変革推進＆エンジニアリング統括部 スペシャリストテスト効率化推進担当坂下 聡氏）
自動化のデメリット・メリットについては上記のブログで調べていた内容と一致しているとことが多く、納得感がありました。
- デバイスがからむ、主観での判断力が必要になるテストに向いていない
- 動的な画面でパターン化が難しい
- ちょっと違うだけで影響度が大きいテストなどは向いていない
という話は気づきになりました。
「自動テストは実施後に、テスト実行時間がどれくらいか、テストが成功しているか、どんなテストが失敗しているかなど結果分析を行い評価する。評価結果をダッシュボードなどで共有すること」という話については、実施する際には共有はどの程度詳細にするのか？など考慮が必要だと思いました。
また、よくある失敗例には、自分にも当てはまりそうな例があり考えさせられました。
例）
- 観点のみの切り分け（曖昧）のみで実施し実は本当に必要な機能があったのに実施していない
- 仕様変更にメンテナンスがついていかない
- 自動実行したことに満足して終わってしまう
- テスト自体の観点が理解できていないまま実施している、など。
一番大事なのは、自動化で出来た時間をカバーできていない手動テスト実施時間に充て、改善や不要項目チェックなども一緒に行うこと。自動/手動テスト両方を改善することで、初めて効果を発揮するのだと思いました。
最後に経験談を伺いました。自動化に過大な期待を持つ人（お客様など）は、実際にはそんなに自動化できるテストが多くないとトーンダウンしてしまい、次に繋がりにくくなる。この過大な期待を崩すのに苦労したと仰っていました。私自身も当初は自動化したら工数削減など大きな効果が出る！と思っていました。実際に自動化してみると向いているテストケースはある程度決まっています。なかなか難しいところだなと感じました。
講演内容：●１人目QAがはじめるテスト自動化 株式会社FiT Tech部門 QAエンジニア武田 義之氏
QAエンジニアがたった一人という状況下で、どのように自動化を導入したのかお話しいただきました。
ビジネスインパクトが大きい（自動化しやすいというよりはその機能が重要か？にて判断）小さいテストケースから自動化し、毎日夜中に実行し、結果をSlackで受けとるようにしたとのこと。またそのテスト結果をだれでも見れるようにダッシュボード（エラーの原因・対応、テストの成功率、実行時間の推移など）を作成したそうです。
何度も失敗があった中で
- テストは小さく始めて着実に拡大する（継続）
- チーム全体（開発的な知識が足りない部分は開発者と連携するなど）で協力する
- テスト結果を可視化することでチーム全体で共有し、振り返りを行うこと
が重要だと仰っていました。
また、1人QAということで、今後増えるであろうQA担当者も自動化作業を継続できるようにコードベースツールではなく敢えてノーコードツールを入れたそうです。加えて、テストケースが増えた場合も、メンテナンスコストに対するノーコードツールの力は大きく、エンジニアが作業しないとダメといったことにならないようにしていると仰っていました。
講演後の懇親会
業界を超えて話をする機会がありたくさんの気づきがありました。
自動テストはリリースするときに1回ぽちっと実行するだけではもったいない（あまり意味がない）ので、毎日実行・何回も実行しよう。QA同士がそれぞれ別のPJにアサインされているときに、QA全体としてはお互いの状況を把握していても、個々が実際に作業しているテスト状況・情報を共有できていないことが多いが、横断的にも共有していく必要があるといったお話にハッとしました。
詳細については、以下URLで第24回Quesの資料が共有されています。興味のある方は是非読んでみてください。
余談
ノベルティいただきました
おしまい。
ここまで読んでいただきありがとうございました。
