新規開発におけるシフトレフトアプローチ

こんにちは。QA Engineer の@testtattoです。
今自分は新規開発プロジェクトのスクラムチームの一員として参画しています。

今回はチーム内で行っているテスト活動をシフトレフトアプローチの事例として紹介いたします。

対象読者

以下に興味や関心を持つ方を対象読者として想定しています。

まえがき

読んでもらう前にいくつかの前提を共有します。

シフトレフトとは

この記事では シフトレフト(shift-left)「テスト活動を早期に行う」 という少し広い意味で使っています。

シフトレフト自体はWikipediaにおいて複数のタイプに系統分けされていたりしますが、国内におけるシフトレフトはテスト 7 原則の「早期テストで時間とコストを節約」の実践という認識が強いことから、この記事では上記の意味で以下話を進めていきます。

QA エンジニアのチーム参画

これまで QA エンジニアがいなかったので、全ての実装完了後にテストベンダーに依頼してテストを実施してもらっていました。しかし、今回のプロジェクトでは開発者と同じタイミングで QA エンジニアも参画し、チームの進め方や要件整理から関わっています。 チーム構成としては以下です。

  • TPM(Technical Product Manager) 1 名
  • Devs 10~15 名
  • QA 1 名

    (他にもチーム外で PO、Design、Contents、Data、SRE チームとも関わりがあります)

実践したこと

ここからが本題になります。 スクラムチームとはいえ、新規開発プロダクトではイテレーション内で要件定義・設計・実装・テストのサイクルを必ず完結させるのは難しく、特に初期は技術調査や環境準備でプロダクトインクリメントの検証ができない場合があります。 なので、便宜上以下のようにフェーズを分けて実践したテスト活動を話します。(実際にこういったフェーズ定義をしているわけではないです)

  • 要件フェーズ
  • 設計・実装フェーズ
  • 検証フェーズ

要件フェーズ

この段階では TPM、Designer と協調して動くことが多いです。このフェーズのゴールは「要件に対して仕様がどうなっていればいいのか」、「どういう振る舞いをするのか」をアウトプットし、開発に着手できる状態にすることです。 仕様の決定については TPM が担う責務なので、QA は主に壁打ち相手になります。

テスト活動

ISTQB Agile Technical Testerシラバスの要求エンジニアリングの章に記載されているような活動になります。並行してテストプロセスに定義されているようなテスト活動を行います。

テストタイプ型のテストアーキテクチャ test-architecture

実践によって得られたこと

TPM とのコミュニケーションによってテスト分析のインプットができるので、テスト分析を前倒しできていると言えます。また、プロダクトに対してはレビューにより考慮漏れを減らせるので「早期テスト」のメリットである「欠陥の作り込みを防ぐ」効果が得られています。

設計・実装フェーズ

この段階では Devs とこれまで以上に関わることになります。QA はシステムアーキテクチャやロジック周りを Devs に教えてもらいつつ、「仕様の認識が合っているか」「各データパターンが考慮されているか」「テストコードの粒度が適切か」といった観点でレビュアーとして参加します。 門番的な立ち位置で全てのコードをレビューするのではなく、必要に応じて壁打ち相手としての立ち位置です。

QA 活動

  • Devs の仕様キャッチアップサポート
  • コードレビュー
  • native cross review
  • テスト設計(因子・水準の整理、テスト観点のメンテナンス)
  • 一部のテスト実装と検証に向けたテストデータ作成

実践によって得られたこと

実装に対して動的テストの代わりに静的テスト(レビュー)をするので、テスト実施を前倒しできていると言えます。 QA 側の副次的な効果としてロジック周りの理解が深まることで新しいテスト観点やテストデータ作成時にやるべきことが明確化されます。 Devs 側の副次的な効果としてはテストコードのレビューにより、プロダクトコード側のリファクタリングが進むといったケースもあります。

after-review

余談気味の内容 native cross reviewでは iOSAndroid の技術差異によってどこの層にテストコードを書くかなど違いがあって純粋に面白いです。 Quipper の Devs はテストコードをちゃんと書いてくれる(何の仕様に対してのテストかとか、テストの確認粒度とかを考慮してくれる)ので、QA 側の理解が深まる効果の方が大きいと個人的に感じています。

検証フェーズ

このフェーズでは特にシフトレフトアプローチに該当する活動はないです。

今後の課題

これまでの実装が完了してからテストベンダーに検証してもらうというプロセスと比較すれば、シフトレフトアプローチによってプロセス品質は上がっていると感じます。 しかし、早い段階での E2E 自動テストや受け入れテスト駆動(ATDD)の要素を取り込んだシフトレフトアプローチができるとより改善できるのでは、という思いがあるので今後はそういった挑戦をしていきたいです。 今回は新規開発プロダクトにおけるアプローチの話になりましたが、既存のプロダクトのエンハンス開発だとアプローチも異なりそうなので、機会があれば紹介したいと思います。

終わりに

今回、QA 活動を詳細に書きすぎると長くなりすぎるので、ある程度抽象的な記載にしています。(プロジェクト内でのテストタイプの話や、テスト分析、テスト設計のやり方など) もし、「もっと詳細が知りたい!」「自社開発の QA のやり方について議論したい」など、Quipper に興味をお持ちいただいた皆様、ぜひ Quipper に遊びに来ませんか? 以下 Wantedly ページよりお気軽にご連絡ください! https://www.wantedly.com/companies/quipper/projects