こんにちは、フロリアでQAエンジニアをやっている中園です。
現在サイボウズではkintoneのフロントエンドリアーキテクチャプロジェクト（フロリア）と称して、Closure Tools から React へと置き換えるプロジェクトが進行中です。
今回は、フロリアのチームの1つであるMiraチームのテスト手法について紹介します。
フロリアの詳細については次の記事をご覧ください。
フロリアについて
フロリアでは、次のような構成でそれぞれのチームがオーナーシップを持って活動しており、テストの方針はチームごとに決めています。
- プロダクトオーナー: 1名
- エンジニア: 3-4名
- QA: 1名
- スクラムマスター: 1名
チームのミッションに合わせたテストの目的
Miraチームでは、kintoneのデザインやふるまいを変えずに、利用者に気づかれない形でReactに置き換えるというミッションがあります。
このミッションに合わせて、次の2つをテストの目的として設定しました。
- Reactに置き換えたときの品質を担保する
- Reactに置き換えた前後で、ふるまいが変わらないことを正確に判断する
目的に沿ったテスト方針
テストの目的から、適切なテストは何なのかチームで議論を行いました。
これまでは、E2Eでの自動テストとQAによる手動テストが主でしたが、実装してからフィードバックを得るまでの時間・コストがかかる状態でした。しかし、Miraチームでは、最速でReactへの置き換えを目指しているため、実装時にテスト結果の素早いフィードバックが必要です。
そのため、Miraチームではテストの方針として、Testing Trophy の考え方を参考にしました。 手動テストだけでなく、Unitテスト、Integrationテスト、E2Eテストの各レイヤーに対して適切な自動テストを行うことで、実行コストを低く、かつ、素早いフィードバックを得られるようにしました。
Miraチームでは、各レイヤーのテストを次のように定義しています。
Unitテスト
Unitテストは、Reactに置き換えたときの品質を担保する、という目的のため行っています。Miraチームで実装したコードに対するテストで、エンジニアの観点でテストを作成しています。エンジニアが実装時やリファクタ時に素早くフィードバックを受け取れるようにするためのテストです。
Unitテストでは、単一の関数・コンポーネントが対象です。
より詳細なテスト内容については、こちらの記事も合わせてご覧ください。
Integrationテスト
Integrationテストは、Reactに置き換えたときの品質の担保と、Reactに置き換えた前後でふるまいが変わらないことを正確に判断するために行っています。
Integrationテストでは、複数コンポーネントを繋ぎ合わせた画面単位でのユースケースが対象です。QAが作成するテスト仕様書をベースにテスト観点を洗い出し、実装しています。
バックエンドはモックしているため、QAのテスト仕様書の中でも、Integrationテストで実装できること・できないことがあります。例えば、ページをまたぐような操作や、値が保存されていることの確認などはここではできないため、別の種類のテストでカバーする必要があります。
QAとエンジニアで議論し、実装できるテストケース・できないテストケースを判断しています。
テストの実装自体は、内部構造を知らないと難しい部分があるためエンジニアにお願いしていますが、実装されたテストの確認をQAが行い、テストとして充分か、抜けている観点がないかを確認しています。確認しやすいように、どういった処理を行っているかテストコードにコメントを書いていく方針としています。
Unitテスト（エンジニアの観点）とIntegrationテスト（QAの観点）で、似た観点のテストケース・テストコードが作られることが稀にありますが、Miraチームでは次の理由からそれらの重複を許容しています。
- 観点を検査し重複を排除するコストのほうが高い
- テストコードが似ていても目的が異なる
- Unitテスト: 部品単位の検証をするもの
- Integrationテスト: 結合した状態でのふるまいを検証するもの
- QAが意識すべきテストがIntegrationテストに絞られるため、確認が容易になる
E2Eテスト
ページが一通り完成したタイミングで、E2Eテストを実装します。Reactに置き換えた前後で、ふるまいが変わらないことを正確に判断する目的のテストで、フロントエンドとバックエンドを通して想定通りに動作していることを確かめるためのテストです。
実行時間、コストを考慮し、テストケースは基本的に「ハッピーパス（正常系のうち代表的なケース）」としています。
しかし、機能によっては異常系のケースが重要なこともあるため、ハッピーパスだけでよいかどうかは都度チームで相談して決めています。
手動テスト
次のようなケースは、自動化せず手動でテストを行っています。
- E2Eテストではカバーしきれなかったサーバ側との繋ぎ込みのテスト
- クロスブラウザでのテスト
- 画面崩れが無いかを確認するテスト
- 自動化にコストがかかるテスト
また、探索的テストも行っており、細かい箇所や複雑な組み合わせを見ています。不定期で、フロリアの他チームのQA複数人でモブで行うこともあります。
テストのフロー
Miraチームでは1ページずつReactへの置き換えを実施しているのですが、置き換える対象のページが決まり次第、実装よりもまず先にQAがテスト設計を行っています。
Reactに置き換えた前後でふるまいが変わらないことを担保する必要があるため、既にある外部仕様書をもとに、テスト設計を行います。
実装フェーズに入ったら、最初にエンジニアとテストの内容を確認し、プロダクトバックログアイテム（PBI）ごとに自動化するテストケースを決めます。これを実施することで、PBIで必要なテストがわかるため、エンジニアとQAとで詳細な仕様や実装範囲の認識が揃うという良い効果もありました。
また、PBIの完了の定義にテストの完了まで含まれているため、PBIの中で自動テストと手動でのテスト実施も完了させる必要があります。必然的にPBIが小さくなるため、扱う必要のある範囲が非常に小さくなり、実装・テストがしやすくなるという恩恵がありました。
このあたりの開発の流れは以前ブログに書いたのでそちらをご覧ください。
実際にやってみての感想
テストの目的から考え、適切な箇所で適切なテストを実施していますが、一定の実装速度を保ったまま、着実にフロントエンド刷新ができているなと実感しています。小さいクロスファンクショナルチームで活動しているため、問題があればすぐに振り返りをし改善をすることもできています。
刷新対象のページはまだまだ残っているため、引き続き、最速でフロントエンド刷新をしていきたいと思います。
この記事を読んだ皆さまのチームに、少しでも参考になると幸いです。
採用情報
フロリアでは絶賛メンバーを募集しています。一緒にチャレンジしませんか？
