ソフトウェアテスト自動化カンファレンス2020　参加記録

2020/12/5(土)開催「ソフトウェアテスト自動化カンファレンス2020」に参加した記録です。
聴きながら書いた自分用メモなので、間違っている内容があるかもしれません。

CIパイプラインでのテスト戦略とその実現方法

大きなPJではブランチ開発が増えて、Merge時にコンフリクトが発生する。
また、本番環境に行って初めて問題が発覚するケースもある。

CI/CDのメリット：
手作業の自動化だけでなく、継続的にマージ・デプロイを行って常に動作するソフトウェアを維持できる。

コミットステージ

開発者がチェックインしたタイミングで実施されるステージ。
ソースコードの解析、ビルド、バイナリのアップを行う。

ここで実行されるテストはほぼxUnit系のユニットテスト。

失敗率やカバレッジが閾値を超えたら（切ったら）パイプラインを失敗させる！
閾値は、新しくコミットされたコードに対するカバレッジや重複率を参照して設定すると良い。

受け入れステージ

バイナリをステージング環境で検証。
この環境では外接は繋がない。

ビジネス視点での試験を行う。
要件に合っているか、環境や設定でアプリがコケないかを確認。

自動テストはシステム用語ではなくビジネスルールで記述したBDDを記述。
これらのテストは開発環境でも実行し、問題を再現できるようにする。

テスト戦略

アジャイルテストの４象限・テストピラミッドを用いて自動化を検討する

• コミットステージでは主にQ1。特に境界値試験など多くのパターンが発生するテストは重要。
• 受け入れステージではQ2～Q3。

テストアワーグラス

ITを減らしてSTを増やそうという動き。
IT＞＞STになると機能の目的がつかめなくなり、仕様変更に対応しずらい。
EtoE自動化・実行環境整備の技術が発展したことも後押ししている。

感想

CI/CDが重要なのは各所で言われているし、やってもいるけれど、現場ではテストのメンテナンスやフェーズの切り替えがなぁなぁになってしまうケースもあるので、閾値を設定して開発者にテストのメンテナンスを強制したり、４象限で試験内容を整理して維持管理していくことが重要そうです。

"全部乗せ" フレームワーク CodeceptJS でE2Eテストを楽にしよう

WebアプリのE2Eテストではクロスブラウザ対応や、
メーラーやダウンロードしたファイルなど、ブラウザ以外のチェックが必要なこともある。

色々なユースケースに対応したCodeceptJSの紹介。

できること

• データドリブンに対応、アサーション時にデータの参照も可能。
• オートログイン
  • Cookieがあってログインされていればそのまま、画面を判定してログアウト状態ならばログイン処理を行う
• メールのチェック
• 表示待機時の自動リトライ

（Ask Speakerで聞いた話）
- レポートはAllureというフレームワークを利用している
- テストの実行結果の統計を取って、Flakyなテストにはアイコンを付けてくれる！

感想

以前CodeceptJSについて聞いた時にはSelenideで十分では？という感想でしたが、
メールのチェックなどただのブラウザ操作フレームワークではカバーできない部分まで実装できると聞いて興味が湧いてきました。
レポートも良さげ。
JSちゃんと書いたことないので、この機会に勉強します。。

テスト自動化ツールで考えるモデルベースドテスト

（このセッションは上手くまとめられなかったので、後日資料公開されたら再編集します）

自動化以前にテストをモデリングしていないと効果的なテストができない（目的不明・非効率・実現不能…etcなテストができる）。
関係者とのコミュニケーションツールとしても有効。

モデルベースドテストとは

テスト設計モデルを用いてテストケースを設計する。
モデルはテスト対象やテスト目的を議論しやすくするためのもの。

モデルの例：人のアクティビティ、状態遷移、構造
状態遷移図やフローチャート、ユースケース図、ツリー（マインドマップ）を使って表現する。

手順
①モデリング
テスト対象のワークフローや同値クラス、テストの値

②テストの選択
テスト目的に沿ったテストを選択する。
要件、モデル要素、データカバレッジ、シナリオベース…etc.

注意点

テスト目的を満たすか粒度を確認しながら作ること
▼アンチパターン
- 何でもかんでも一つの図に書いてしまう
- ざっくりしすぎor詳細すぎる

テストの要件と紐づける

• 確認したいことをリストアップしてモデル作成する
• 要件↔テストのトレーサビリティを記録する

Eggplant

モデルからテストケース自動選択・生成、自動実行を行える。

E2Eのリトライを少し賢くして、落ちにくくしてみた

画面遷移・リグレッションテストをクロスブラウザで自動実行している。
テストデータはExcelからyamlに変更した。Diffを取りやすくなる。

リトライ

操作のリトライ＋テストのリトライを実施する。

テストごと再実行すると失敗率が上がるため、操作の再実行がメイン。
画面Elementの取得に失敗したら一定間隔待って再度Getする。

Elementの存在確認をリトライするだけで実現できている。
Sleepなどは使用していない。

テストのリトライについて。
Exceptionをキャッチしたら一定時間スリープし、テストごと再実行する。
ただし、再起不可能なエラーが発生した場合は即座に終了する。

次の課題

AWS上に乗せてスケールアウト、テストの並列実行を実現したい。

感想

操作リトライについては最近は自動化フレームワークが充実していて意識しなくても実行できてしまいますが、エラー内容によってテスト事実行・強制終了といったハンドリングをきちんと行っているのが良いなと思いました。
全部最初から作ると大変なので、うまくフレームワークと組み合わせて判定できるように作りたい。

reg-suitとQA Wolfを活用したVisual Regression Test

暗黙で目視確認しているところも自動テストにしたい。
→Visual Regression Test

修正前後を画像比較して同じならテストOKになる仕組み
いくつかのツールを試してみた
- Visual Regression Test：画像取得の方法が独特で難しい
- Desemble.js：結果を目視チェックできない
→reg-suitを採用

reg-suit

画像を比較するだけのシンプルなツール

比較結果を重ねたり並べたりしたレポートを出してくれる。
（便利だ…！）

期待値・実際の画像の配置などはプラグイン機能で実現できる。

QA Wolf

ブラウザ操作のリプレイキャプチャ。（コードの保守性は高くない…）
Playwright・Jestが組み込まれている。
→ブラウザ操作とスクショの取得を実施。

運用

Unit Testと同様にCIで実行し、この実行結果の確認も開発者の責務とした。
公式Dockerは日本語フォントが含まれていないので注意！

良かったこと：画面キャプチャがあることで、レビューア・QAにも変更内容が直感的に理解できる。
大変だったこと：CIに乗せるためのインフラ整備。

感想

画像の重ね合わせは、スクリーンサイズとかでブレが発生するので運用が大変なイメージがありますが、
Dockerなどで均一な試験環境をちゃんと用意したうえで、ある程度のブレはレポートの方を見やすくして、レポート確認の時にこれはOKな差分・これは意図しない差分、とサクサク確認できるように運用を工夫するのが良いのかなと。

総括

自動テストについて、E2Eだけでなく設計やCIなど色んな観点から話が聞けてとても楽しかったです！
聞けなかったセッションにも興味深いタイトルが多いので、資料を読んだら追記します。