QAとDevで作る自動化テスト Toshinari⚡ (@10shinari) 1

自己紹介 2 • Toshinari（@10shinari） • サイボウズ株式会社 開発本部 kintoneチーム • QAエンジニア/スクラムマスター

チーム紹介 3 • kintoneのフロントエンドを Closure ToolsからReactへ 技術刷新するチーム（通称：フロリア） • 『フロリア Cybozu』で検索すると、 エンジニアブログにヒットします！ • 4つの小さなチームに分かれて活動 • 1チームあたり6~7名 PO Dev SM QA Dev Dev

本日ご紹介する取り組み 4 QAのテスト仕様書をもとに、 Devがテストを実装 テスト仕様書とは 機能試験（要件や外部仕様をシステムが満たしている ことを確認する試験）のテスト仕様書のことを指す。 手動での操作を前提とした手順で構成されている。

QAとDevのコミュニケーション 5 Devにテスト仕様書を渡して終わりではなく、 QAとDevでコミュニケーションをとりつつ進める • テスト目的のすり合わせ • QA内で暗黙的に実施している手順があると、DevとQAでテスト目的の認識にズレが生じる可能性があるため • テストのレイヤー決め（E2E/Integration/VRT） • 適切なレイヤーでテストを実装するため ※ Unitテストに関しては内部実装の把握が必要なためDevの観点でテストを実装 • 自動化するかどうかの判断 • 実装のコストが高い、テストが安定しない、自動化しても意味がない項目等は自動化しない

メリット 6 • QAのテストのノウハウをテストコードとして品質に組み込め る • Devのテストスキルに依存せずに一定の品質を担保できる • Devからの実装視点のフィードバックにより、テスト仕様書 がブラッシュアップされる

デメリット 7 • Devがテスト仕様書を解読するのに苦労する • DevとQAでテスト目的の認識にズレが生じるとQAの意図した テストでなくなる可能性がある • テスト仕様書の全ての項目を自動化できるわけではないので、 自動化するかどうかを判定する議論が必要

チーム内の声 8 テスト仕様書をみることでQAのテストのノウハウを感じられた。 テスト仕様書をベースにしてテスト自動化してみて、率直にどんな感 想を持ちましたか？ 安心してリファクタリングができる。 Dev Dev QA 私 Devにテスト観点を説明することで、暗黙的に実施していたテスト観 点を再考するきっかけになった。

9 クロスファンク ショナル 完全分業ではなく、 QAとDevがお互いの領域 に踏み込んでいくことで、 チームにとって最適なフ ローを作り上げる。

クロスファンクショナルな事例① 10 • Dev⇔QAのコミュニケーションコストを下げたい。 • Devの負担を減らしたい。 QAがソースコードにテストファイルを作成し、 予めテストファイルにテストの目的や自動化に寄り添ったテスト 手順をコメントアウトで記載する。

クロスファンクショナルな事例② 11 • QAによるテスト設計の待ちをなくしたい QAはDevにテストのノウハウを伝授。Devがテスト設計⇒実装し、 QAがレビューをする体制をとる。

最後に 12 • 各チームの詳細な取り組みは、ブログや社外発表の場でアウト プットしていきますので、是非「フロリア」をチェックしてみ てください！ • 質問や相談、雑談希望の方はお気軽にTwitterでDMをくださ い！（@10shinari） • サイボウズでは一緒に働いてくれるメンバーを募集しています。 ご応募お待ちしております！