こんにちは。QAエンジニアをしているゆ太郎です。
ここ数年は主にWeb管理システムのリグレッションテストに関わることが多く、テスト自動化に興味津々な今日この頃です。
3/9-10に開催された、JaSST’23Tokyoにオンライン参加してきました。JaSST’23Tokyoの開催を知りセッション概要を確認した際に、テスト自動化に関する面白そうなタイトルが並んでいたので、急遽オンラインで参加して聴講させてもらいました。今回は、『結合テストの自動化にQAはどうかかわっていったか』というセッションについてレポートしたいと思います。
JaSSTとは
JaSSTとは「ソフトウェアテストおよびソフトウェア品質に関心のある方が深い学びを得ることを目指して、 ソフトウェアテスト分野の幅広い情報と、参加者同士の交流や議論ができる場を提供」するため、特定非営利活動法人ソフトウェアテスト技術振興協会 (ASTER)が主催する日本最大級のソフトウェアテストのシンポジウムになります。
JaSST’23 Tokyoのテーマは「相互理解で広がる世界」ということで、関連するセッションが多数催されました。
結合テストの自動化にQAはどうかかわっていったか
よく広告で見る『Kintone』で有名なサイボウズさんより、永田敦さん（アジャイルの品質アドバイザ）が登壇され、『テスト自動化におけるQAと開発の関わり方』という講演をされていたのを聴講してきました。
永田さんたちKintoneのフロントエンドチームでは<< フロントエンドでUX構築のため、JSライブラリ変更 >> というミッションのもと自動テストをテストアプローチとする新規チームが立ち上がったそうです。
テストポリシーとしては「テスティング・トロフィー」を採用し、結合テストの割合を厚くするという方針に決まり、開発チームと協力して多くの困難を乗り越え、テスト自動化の業務プロセスを作り上げていったという感動的なお話でした。 「テスティングトロフィー」は、E2Eテスト、結合テスト、単体テスト、Lintや型チェックの４つのテストカテゴリで構成され、各テストの書くべき総量をトロフィーの体積の比率で表しています。特徴として、結合テストに重点が置かれています。
発表資料を頂きましたので ↓ こちら ↓ をご参照ください。
出典：JaSST’23Tokyo D4-2 一般公募セッション「テスト自動化におけるQAと開発の関わり方」より
講演内容から得た「３つの学び」を以下にまとめます。
学び１ 用語の齟齬をなくす
自動化チーム発足時にQAから開発者に向けて、テストポリシーを説明する機会があったそうですが、QA用語に関して開発側の認識の齟齬が多くあり、はじめはコミュニケーションが上手く取れなかったそうです。例えば、QAでよく出てくる以下のような用語について
[開発]
－ 探索的テストとは？
－ フロントエンドの結合テストって？
－ ハッピーパスって？
[QA]
－ 言葉が通じない・・・
ですが、一つ一つ丁寧に用語の共通認識を揃えて行くことで、その後は阿吽（あうん）の呼吸レベルでコミュニケーションがとれるようになったそうです。 私の経験から同じQAでも文化が違ったりすると用語の解釈も違ったりして、後になってテスト仕様書を修正したり、、なんて苦い思い出がありました。 「使用する用語の認識レベルを揃える事」小さな事かもしれませんが、成果物に対する認識のずれが生じる事もあるので、その重要性を再確認しました。
学び２ 暗黙的表現をなくす
これも大きくはQAと開発の間での認識の齟齬が起きていたというお話ですが、主にテスト仕様書の表現に関する問題点と改善点の事例を2点挙げられていました。
1点目：
【問題点】
テスト仕様書を開発に説明する際に手順や期待値が曖昧な表現になっていたため、正確な自動化テストコードが書けない
【改善点】
期待値は誰が見ても分かるような書き方にすべて書き直した
2点目：
【問題点】
テスト目的や背景説明がなかったため、開発側も目的に沿ったテストコードが書けなかった
【改善点】
テスト観点や背景を言語化して伝えるよう努めた
2点目においては、QAにとってもテスト観点を深堀して洗いなおす良い気づきになったそうです。 上記2つの事例を聞いて、テスト設計において「曖昧な表現」はバグを見逃す要因にも繋がってしまうため、危険だという事を再認識したと同時に、テスト設計者とテスト実装者が異なる場合は特に細心の注意を払って明確な表現にすべきだということを学びました。
学び３ 責務を明確にする
自動化できるテスト、できないテストの選定が難しかったという事例を紹介して頂きました。 バックエンド側で実施するテストなのか？フロントエンド側で実施するテストなのか？そこで開発とレビューを重ね「フロントエンドチームとしてのテスト責務の見直しと再確認を重ねる」ことで、不要項目の大幅な削減につながったそうです。
どれだけ忙しくても、レビューはとても大切。
まとめ
上記改善の成果として、以下の①～④のシナジー効果が得られたそうです。
①設計の容易化
②（簡単な設計のため）実装もシンプルになる
③（複雑なコードにならないため）テスト実行も早くなる
④（また実装がシンプルなことで）コードの保守性、可読性も上がる
一にも二にも、QAと開発が歩み寄りの姿勢をもって接したところに成果が築かれたのだろうなと私は感じました。 さらに永田さんは、レビューでの議論や説明の際、円滑なコミュニケーションを図るための秘訣を教えてくださいました。
それは、、 開発もQAもお互いに「気持ちのこもったありがとう」を言う事でチアリング（お互いにリスペクトを持った対応）のループを作ることだそうです。
人と仕事をする上で、最も大事なことの１つなのに、焦ってたりすると忘れてしまったりするので。常に心の中心に置いておきたいものです。
参考文献：
サイボウズさんからご紹介頂いた参考文献（今回の事例の詳細が記載してあったりします。）
フロントエンド刷新プロジェクトを成功に導くためのテスト手法の紹介
エンジニアとの距離が近くなっていいことたくさんだったQAの話
最後まで読んで頂き、ありがとうございました。
