以前に以下の記事でテストエンジニアの1日の仕事の流れを書きました。
今回はそんなテストエンジニアの中でテスト設計を主に行うメンバーの1日について書いていこうと思います。
まず、テスト設計を担当するテストエンジニアの仕事は1日単位で完結するものではありません。
僕はスクラム開発の現場がほとんどだったのでスクラムベースでの話になりますが、
スクラム開発ではスプリントの長さや開発規模に合わせて、仕様確認からテストケース作成までを複数日に分けて進めます。
現場によって違いはありますが、僕の体感では1スプリントを2週間とする案件が多いです。
おおよその進め方は次のようになります。
- 1週間：テスト設計の着手から完了まで
- 2週間：規模によってはテスト設計からテスト実施まで
- 4週間：複数の開発タスクを並行して設計・実施
もちろん、これは決まった形ではないので、開発規模やレビュー体制、テスト環境の準備状況などによって変わります。
このスプリントをもっと具体的にした話を今回はしていこうと思います。
day1.テスト対象の仕様を理解する
テスト設計で最初に行うのはテスト対象となる機能や内容の理解です。
正直ここだけで数日使うこともあります。
仕様書やチケットを読むだけではなく、
・どのようなユーザーが
・どの状態で
・何を操作するのか
までを基本としてテストケースに落とし込む内容を確認します。
この段階で仕様漏れや考慮漏れに気づいた場合は、開発者やプロダクトオーナーなどの関係者へ確認します。
そしてその内容次第で設計を進めたり、その開発自体をどうするかを判断します。
なので、この仕様理解と認識合わせはかなり重要だったりします。
テスト設計は決められた仕様をそのままテストケースへ変換する仕事ではないと思っています。
あくまでテスト可能な状態やユーザビリティを意識した状態まで仕様を整理することもテストエンジニアの大事な仕事だと思っています。
day2.テストケース数とテスト実施期間を見積もる
仕様を把握した後は、テストケース数を大まかに見積もります。
表面的には1つの操作パターンでも、
・権限
・契約状態
・入力条件
など様々な状態によって1つのケースを複数の状態で確認しなければならないことがあります。
そのため、画面数や機能数だけでケース数を判断すると実施期間を大幅に見誤まることがあります。
ケースは1つだけど、最低でも3パターン確認しなければいけないというだけで3倍にテストボリュームが増えるわけですからね。
ケース数の見積もりと同時にテスト実施に何日かかるかも見積もります。
その結果を基に今のスプリント内で設計と実施まで終わらせるのか、今スプリントは設計までとして次のスプリントで実施するのかを関係者と相談します。
この見積もりは各関係者との認識やリリースタイミングなどによってピリピリムードになるので伝え方は結構気を付ける様にしています。
day3.受入要件からテストケースを作成する
見積もりを共有して進め方が決まったら、現場のルールに応じて次の順番で成果物を作成します。
- 受入要件
- テスト観点
- テストケース
受入要件は、どのような状態になれば機能を受け入れられるのかを整理します。
次に、整理した受入要件を基に正常系や異常系、権限、制約などをテスト観点として作成します。
最後に、作成したテスト観点を画面に沿った具体的な前提条件、操作手順、期待結果をテストケースへ落とし込みます。
案件によっては
・そもそも受入要件を作成しなかったり、
・受入要件またはテスト観点のどちらかだけをレビューしたり、
・そもそも受入要件もテスト観点もレビューしなかったり、
と現場によって様々です。
個人的にレビューをされないのは楽でいいのですが、視点が自分一人だけになってしまうので、テスト観点のレビューはあるべきと思っています。
day4.テストデータ準備
書くか悩んだけど、テストデータの準備も設計に含まれるものと思っています。
ただ、テストデータの準備はテスト設計に含めるかテスト実施に含めるかは案件によってまちまちなので、案件のルールに従うでいいと思います。
個人的には設計時に作ってしまう方が後々のために良いと思っています。
ただ、テスト実施に含める場合はテスト実施者へ準備を任せる時もあります。
特に若手がテストを実施する場合は、観点やケースを基に「どのようなテストデータが必要か」を考えてもらうことで将来の設計に活かすという意味でお願いすることはそれなりにありました。
単にデータを用意するだけではなく、テストの意図を理解するための作業にもなるからです。
テスト計画書は毎回作る訳ではない
スクラム開発だからといって、スプリントごとに正式なテスト計画書を作成するとは限りません。
数ヶ月、数年かかる様な大規模開発ではテスト範囲、体制、環境、スケジュールなどを整理する必要があるのでテスト計画を作成する必要はあると思っています。
しかし小 ～ 中規模の開発ではチケットや受入要件、テスト観点で管理して独立したテスト計画書を作らない現場もあります。
というのも短いスプリントで回すのだから、そもそもとしてテスト計画を作るほどの大きな開発をしない、というのが理由に挙げられると思います。
個人的にも最終的にズレが生じることがほとんどだからテスト計画書は滅多なことでは作らなかったです。
まとめ
テスト設計エンジニアの1日、テストケースを作成するだけではありません。
・仕様確認
・テスト工数見積もり
・関係者との調整
・レビュー対応
・テストデータ準備
を複数日にわたって進めます。
以前SNSでテストエンジニアに必要なスキルとして「日本語力」と書きましたが、ほぼこのテスト設計に「日本語力」が集約されているのだな、と自分で書いてて思いました。
テストエンジニアはテストケースを作成したり、指摘したり、バグチケットを書いたりととにかく文章を書くことが多いです。
なので、相手に「何を最も伝えたいか」を意識するのが重要と改めて感じましたね。
コメント