結合テストの自動化にQAはどうかかわっていったか

こんにちは、サイボウズの永田です。
私は、サイボウズの開発本部、アジャイル・クオリティで、アジャイルの品質を探求する活動をしています。

この記事では、2023年3月9日、JaSST Tokyo 2023のテクノロジーセッションで発表させていただいた内容を、より解説を入れながら紹介します。

今回取り上げる事例では、kintoneのフロントエンド刷新プロジェクト（フロリア）で結合テストの自動化を決定した際に、QAメンバーがどのように関与し、困難に直面しながらも、信頼性の高いテストコードを作成するに至るまでの過程をご紹介します。フロリアについては次のブログをご覧ください。

blog.cybozu.io

テストのポリシー ~このミッションにおけるQAのチャレンジ~

フロリア内で新しく3つのチームが立ち上がった際、各チームのテスト戦略の中心を、自動テストへと移行させることに決定しました。テスト自動化のアプローチとして、Kent Doddsが提唱しているテスティング・トロフィーを参考にしました。テスティングトロフィーはテストピラミッドとは対象的に結合テストを手厚く行うアプローチです。このテスト方針についての議論がどのように行われたかは、次のブログをご覧ください。

blog.cybozu.io

テスト自動化の課題

結合テストの自動化を推進するにあたり、課題が生じました。

QA側の課題

QAにとっての課題は、このチャレンジにQAはどうかかわるかということです。よくあることは、QAはE2Eテストにとどまり、結合テストは開発者にお任せしてしまうことです。結合テストでは、テストコード開発のスキルや知識を学ぶなどハードルが高いからです。一方で、開発者のみで結合テストの自動化を実施する場合、QAはテスト設計がどうなっているのかなどが見えにくくなり、テスト品質が心配になります。

開発側の課題

開発者にとっての課題は、何をテストするか（What）、テストコードをどのように実装するか（How）など、テスト設計に不安、悩みを持つことです。

結合テストの自動化にサイボウズQAはどうかかわったか

フロリアのQAは、結合テストの自動化を開発者にすべて依存してしまうのではなく、QAが作成したテスト仕様書を基に、開発者と協力してテストコードを実装することにしました。しかし、当初は順調に進まず苦労しました。

用語の齟齬とコンテキストのずれの解決

まず、テスト用語に関する齟齬を解消するために、テスト用語とテスト仕様書の説明を行いました。その時に気づいたのが、暗黙的表現です。

例えば、期待結果が「～が正しく表示できていること」などと書かれていることでした。長い間、継続して同じ製品をテストしていると、操作手順や期待結果はパターン化し、暗黙知になります。QAが手動でテストを実行する際は、その暗黙知で補完され、正しくテストされていました。しかし、そのような暗黙知を持たない開発者から、「正しいってどういうことですか」と言われました。
自動化するためには、具体的に期待結果が分からなければ、テストの成否判断を実装できません。そこで、あいまいな表現をすべて直しました。

さらに、テスト仕様書に書かれている内容自体が伝わらないという問題も起こりました。 QAがテスト仕様書の説明をしていく際に、テストの目的やテスト観点を開発者に理解してもらうためには、その背景や意図を含めて言語化して伝えることが大切だと感じました。これにより、QA自身も、テスト観点を深く考えるきっかけとなりました。

テスト設計の議論

次に、QAと開発者で一緒にテストの実装可能性や目的達成を議論しました。QAと開発者がテスト設計を共同で考えコラボレーションすることで、テスト設計の核心部分が明らかになりました。ここに、その一例をご紹介します。

それは「このテストは、このテストケースでやるべきなのか？」という議論です。

開発者側から、

「テストの目的からして、テストで注目しているのは、バックエンドの処理結果ではないのか」

「それならば、バックエンド側でテストしたほうがよいのではないか」

などの意見が挙がりました。

このような議論は、QAだけでは考えられません。また、開発者だけでもたどり着けません。
テスト対象やテスト観点をQAが持ち込み、プログラム構造から開発者が考え、コラボレーションした結果生まれたものです。

テストの責務

ここに、 テストの責務 という考えが生まれ、適切な場所やレベルでのテストが可能になりました。

明確なテストの目的により、テスト設計やコード実装が容易になり、テストの品質も向上しました。 QAと開発者のコラボレーションによる議論を通じて、質の高い結合テストの設計ができるようになり、双方が新たな知識を学びました。

このように、QAが結合テストの自動化に対して介入していったチャレンジは、いくつもの苦労はありましたが、QAと開発者のコラボによるテスト設計の議論により、より品質に確信が持てる結合テストのコードを設計することができるようになりました。 QAはテスト観点を改めて深く考え、テストの責務を学び、開発者はテスト設計の考え方を学びました。

プロセス

そして、この活動により、チームの手で自らのプロセスを進化させていきました。これは、その一つのチームのプロセスです。

QAと開発者がテスト設計を行い、開発者がコードとテストコードを実装します。このプロセスで認知の共有が進み、スピードが上がりました。また、実装段階から自動テストを書くことで、実装に対してのフィードバックが早めに得られるようになり、不具合を見つけられるタイミングが早くなりました。QAが手動テストを実施するタイミングではほぼ不具合は見つからないため、手戻りが減り、実装からテスト完了までがスプリント内でできるようになりました。詳細は次のブログでも紹介をしています。 blog.cybozu.io

テスト仕様書の変化

さらに、テスト仕様書についても変化がありました。

あるチームのQAは、テスト仕様書とテストコードで2重にテスト観点を管理していることを改善するため、テスト仕様書の設計方法の見直しを検討しました。開発者もExcelで作られたテスト仕様書を触る機会が少なかったため、QAはコード上にテスト項目を書くようにしました。開発者はそれに基づいてテストコードを書き、QAとレビューをしました。そのようなやり取りを重ね、QAと開発者が連携を取る中でQAもテスト実装に挑戦することになりました。詳細はブログをご確認ください。

blog.cybozu.io

QAがテストコードを書く

これは素晴らしいことで、QAの好奇心とチャレンジ精神が必要です。テスト自動化へのQAの関わりは、テスト仕様書の説明から始まり、最終的にQAがテストコードを書くまで進化しました。これはまさにアジャイル開発の特徴と言えます。

文化的な背景

何故、このような取り組みをチームは実現することができたのか？それにはサイボウズの文化的な背景があります。

上記のスライドにある、中央にある感謝ループが特徴的です。

具体的には、Slack内で”Thanksチャンネル”という、感謝を共有できる場があります。「～さん、～してくれてありがとう」と投稿することで、お互いに感謝する文化が生まれ、これがチームの貢献意欲を高めています。感謝をもらったメンバーは、もっと挑戦したくなる、チームのために貢献しようと行動するようになります。

このような文化の背景のもと、チームは取り組みを達成しました。