Gunosy Tech Blog

Gunosy Tech Blogは株式会社Gunosyのエンジニアが知見を共有する技術ブログです。

JaSST'22 Tokyo 参加レポート

QAチームのkorokiとmiyagiです。

3/10-11にオンラインで開催されたJaSST'22 Tokyoに参加しました。
JaSSTはソフトウェアテスト技術振興協会(ASTER)が開催する、テスト技術力の向上と普及を目的としたソフトウェアテストシンポジウムです。

今回は、興味深かったセッションをいくつかピックアップして共有したいと思います。

基調講演「Competing with Unicorns」

こちらはSpotifyのエンジニアだったJonathan Rasmusson氏による講演でした。

内容としては以下の2点についてのお話がメインになりました。
・ユニコーン企業の考え方が他の企業とどのように違うのか
・Spotifyでのテストをどのように改善していったか

Spotifyのテストに関してはまとめると以下のような内容でした。

Spotifyでも最初の数年間は全てがマニュアルテストで行われていた (音楽が流れるか、プレイリストが作れるか、、、)
→マニュアルテストには非常にコストがかかる
→UIテストから自動化を進めた

しかしUIテストを多くやっていると、以下のような問題に直面した

  • 実行時間が長くなっていく
  • テストの脆弱性が高く、不安定 (UIを変えると失敗する等)

テストピラミッドでは以下の3つが△の形になっていることが理想
* UI
* 統合テスト
* ユニットテスト

テストピラミッド

(http://www.agilenutshell.com/episodes/41-testing-pyramid より)

UIテストが多く、ユニットテストがほとんど行われていない状態でこのピラミッドが▽の形になっていた
Jonathan氏はテクニカルコーチとして、ピラミッドを△にすべく以下の支援を実施

  • ユニットテストをもっと厚くする

  • 開発者に関与させる

  • より良いテストが書けるようにトレーニングやワークショップを実施

会社レベルでも「Fix It Week」という業務改善週間を作った
→1週間業務を止めて通常の業務時間内ではできないような、チームの仕事がよりやりやすく生産性が高まるよう改善に取り組む週


テストの改善について全体的にざっくりとした説明だったため、自社でそのまま活用するのは難しそうではありましたが、ケースとしては興味深かったです。
UIテストの自動化時の問題点については直近の業務でも同様の課題があったので、どこでも共通で起きる事案なのだな…と感じました。

ユニコーン企業の考え方についてのお話は今回紹介していませんが、講演と同じタイトルの書籍をJonathan氏が書かれており、こちらの本でより詳しく知ることができそうでした。

https://www.amazon.co.jp/dp/4873119464/

「60分で学ぶ実践E2Eテスト」

このセッションではE2Eテストを自動化するにあたっての、テスト設計の考え方から実際のテストコード実装の話まで聞くことができました。
まず前半部分では、E2Eテスト自動化のためのテスト分析やテスト設計を行う際に考えるポイントについてのお話でした。

テスト自動化の8原則から
「手動でおこなって効果のないテストを自動化しても無駄である」
という文言を引用し、テスト自動化においても事前のテスト分析とテスト設計を正しく行うことが重要であるとのことを強調していました。
テスト自動化研究会 - テスト自動化の8原則

自動化のためのテスト分析と設計でそれぞれ考えるべきこととしては、以下のような点が挙げられていました。

テスト分析(何をテストするか)で考えるべきポイント
* 最重要な機能から自動化する
* 正常系の基本的なユーザーシナリオを自動化し、異常系の細かいパターンは除く
* バグがあった場合にビジネス上の影響が大きい範囲を対象にする
* 人数ベースで見た場合は対象のブラウザ等の利用割合、金額ベースで見た場合は売り上げの割合を考える

テスト設計(どのようにテストするか)で考えるべきポイント
* テスト技法を活用してテストしたいことを網羅できるようにする
* 手動で行うことを前提に作ったテストケースをそのまま自動化しない
* テストの実行単位を自動化に合わせて変更するなど、自動で行う場合の効率を考える

これらを踏まえた上で、自動化練習用に公開されているホテル予約サイト
を用いて具体的にどうテストするか、テスト対象の範囲を決め、シナリオを手順化するところまでの解説がありました。

セッションの後半部分では、前半で作成されたテストケースをもとに「Cypress」というテストツールを使ってJavaScriptでの自動化の実装方法の紹介でした。

読みやすいテストコードを書くための要点としては、以下のような点が挙げられていました。

  • 設計したテスト手順をそのままコードのコメントとして書く
    →1:1でコメントの手順に対応するテストコードを書いていく

  • テスト手順、ユーザー操作と関係のない処理を記述する必要がある場合は、テストコードから分離する
    →Cypressでカスタムコマンドを定義する
    →ユーザー操作と関係のない部分を隠してシンプルにすることで、ユーザー目線の読みやすいテストコードになる


このセッションを聞いて、自動テストにおいてのテスト分析・設計時に考えるべき観点、手動テストとの考え方の違いなどは参考になる点が多くありました。
後半のテストコードの書き方については、JavaScriptの知識ゼロで聞きましたが、説明が非常にわかりやすかったため要点は把握できました。
今回はCypressをインストールして軽く触った程度でしたが、今回のお話を参考に今後自分で色々と試して理解を深めたいと思います。

「品質エンジニアリングと自動化後の世界」

こちらのセッションではブラウザテスト自動化サービス「mabl」のデモを混じえてアジャイル開発における品質の維持についてのお話と、自動化が進んだ先の未来についてのお話をされていました。

特に興味深かったのは、自動化後のこれからの10年の話で、仮説として挙げられた以下のような点でした。

  • 自動テストのカバレッジが広がっていく
    →ユニットテスト、リグレッションテスト、E2Eテスト、APIテスト…

カバレッジが広がることで起きること2点

  1. アクセシビリティテストが注目される
    ・操作しやすさ、アクセスしやすさをみるテスト
    ・アメリカでは関連した訴訟が増えている
      →視覚障害者がサイトを利用できない等
    ・日本でも法改正により企業に対して“Webアクセシビリティへの合理的な配慮”への対応が義務化

  2. テストに対する視点の変化がある
    ・自動テストはverification視点
    →仕様通りに動くかの検証
    →当たり前品質
    ・手動テストはvalidation視点
    →作り手が提供したいものであるか、ユーザーが本当に求めているものであるか、使いやすいものなのか… →魅力的品質

データとインサイト
・自動化が進んだ未来には、ツールを利用してデータとインサイトを得て人間が判断する、という仕事が残る
・例として、自動テストの成功率のデータをもとに、不安定なテストの原因を特定して安定化させるか、調査コストを考えて自動テストから除外するか、リファクタリングすべきか、カバレッジを上げるべきか、などの判断
・意思決定により品質を底上げしていくような活動が今後は増えていく


自動テストのカバレッジが拡大する中で、アクセシビリティテストが重要になってくるのではないかというお話は特に印象的でした。
自社のプロダクトに対して、障害を持つ方や高齢者でも使うことができるか?誰にとっても操作しやすいか?という観点ではあまり考えたことがなかったため、新たな視点を得ることができました。
また今回のセッションは、テストの自動化が進んだ先でも「人間にしかできないテスト」とは何だろう?ということを考えるきっかけにもなりました。

「テスト設計の意図を届けよう」

こちらのセッションでは、テスト設計成果物をステークホルダーにレビューしてもらう際に起きる困りごとと、テスト設計者ができることについてお話されていました。

テスト設計成果物をレビューする時、
「何を確認したくてこのテストをするんだろう…?」
「このテスト、確認したいことちゃんと網羅できてるのかな?」
とテスト設計者の作成意図がレビュアーに伝わらないという困りごとが発生することがあります。

そうなってしまう原因として、レビュアーにいきなりテスト設計成果物だけを見せてしまうことで(作成者が頭の中で無意識に考えている)設計意図やどうしてその項目をテストしようと思ったのかという意図がうまく伝わっていない事が挙げられるそうです。

テストの設計意図を伝えるためにテスト設計者が気をつけることとして以下の点が挙げられていました。

1. テストケースになるまでの過程を見せる
・テスト設計の途中過程で、自分が考えたことを出力する(メモ/つぶやき/雑な絵)
・テストケースになるまでの間に参照したものを辿れるようにする
2. Whyを明確にして納得度を上げる
・「このテストをする根拠はなんだろう?」を問いかける
・あえて提示しないと根拠は伝わらないことを意識する
3. 構造を見せる
・テストしたいことの全体像を見せる
・全体像を見せるために適した考え方や表現方法を選ぶ(デシジョンテーブルや状態遷移図などのテスト技法を使い分ける)

日々の業務に追われてテスト設計を完了させることに意識が向いてしまいがちですが、どうしてそのテストをする必要があるのかという意図を見える形で出力し、レビュアーと共有するという工夫を加えることでお互い納得して高い品質のテストを行うことができるのだなと勉強になりました。

まとめ

今年はリモートでの開催だったのですが、チャット上で様々な質問や議論が飛び交っていて講演と同じくらいとてもいいインプットと刺激を受ける機会になりました。
JaSSTには今回初めての参加でしたが、JaSSTnanoという小規模なイベントも定期的に開催されているそうで、今後はそちらの方にも参加できたらなと思いました。