開発者と作るテスト観点(小ネタ)

開発者と作るテスト観点

2019年にとあるプロジェクトで行った取り組みについて、備忘録がわりにまとめます。
そのものずばり、テストのための観点出しを開発チームと一緒になって行うことで、観点の過不足を補ったりや合意を取って進めることができました、というお話。

経緯

今回の評価対象は非常に難易度の高いものでした。
理由はいくつかあって

  1. 新サービスであること (e.g. ノウハウがまとまってない)
  2. テストチーム内に前任者がいないこと (e.g. すぐに頼れる人がいない)
  3. 環境が多岐に渡ること (e.g. 不具合の切り分けが難しい)
  4. ドメイン知識そのものの難易度が高いこと (e.g. 理解そのものが難しい)
  5. ボリュームが大きい
  6. メンバーに類似サービスの知見がない

etc....

のような感じでした。

取り組み

従来の進め方は以下の通りです

  • [テストチーム内] テスト対象の分析を行う
  • [テストチーム内] テスト計画を立てる
  • [テストチーム内] テスト観点出しをする
  • [開発チームに向けて] 概要レベルの観点レビューを行う
    • 基本的には 1回 こちらが観点を読みあげて、その場でチェックしてもらう
  • [テストチーム内] テスト詳細設計をする
  • [テストチーム内] テスト実装をする
  • [テストチーム内] テスト実施をする

今回は、まずテスト対象の分析に時間がかかったこと、開発物が出てくるのと仕様の FIX が計画時点ですでにテスト実施が始まってからでないと難しそうな予感を漂わせていたこと、その他もろもろの理由で、従来の進め方ではテストの遂行が行えないだろうと思われました。
そのため、以下の工夫を行いました。

  • 開発チーム、運用チーム、(必須ではないが) サポートチームを招いた「仕様理解MTG」を週次で実施
  • 仕様ができた(もしくはできる)順番にテスト観点だしをテストチームで行い、私(類似サービスの経験あり)がレビューをする
    • 観点をマインドマップの形にして、かなり細かいレベルで書く(必要に応じてテストデータ、パラメータも当てはめた)
  • レビューが済んだもののうち、不安が残るものは週次のMTGで対面で説明し、不明点を埋める
  • それ以外のものについては開発チーム側の見える場所に集約し、非対面で指摘をもらう

よかったこと

上記の取り組みを行うことで、開発チームの持つノウハウの吸収が行えました。
また、テスト観点漏れをかなり防げました。

悪かったこと

開発計画時点で考えていたことではなかったため、開発側の工数をだいぶ食ってしまった。
今回が初だったので、次回からは早い段階でこういう取り組みがしたい旨を共有しておく必要がある、と思った。 悪かったとは言われませんでしたが、反省点の一つです。