概要
テストベースを分析して、どんな品質保証が適当なのかを勘案の上、計画を策定する事例紹介です。
先に自動テストを試してみてから、テスト計画策定をしてみました。
テストスィートの章立て事例が、以外と公開されていないという状況もあるようで、これからテスト計画を策定する機会がある方の参考になればと思います。
尚、本記事では、概要や方針といったことを決定する事例としている点、「策定」としました。
具体的なテスト計画を記述するのは、次回とします。
以下のようなテスト計画策定プロセスでやってみます。
- テスト対象を、軽く、触ってみます。
- 自動テストが、どれくらいできるか、少しだけ動かしてみます。
- マニュアルテストと自動テストとで、「かんばんりすと 注1」の品質保証が、どんなふうにできるか考察します。
- 品質保証計画を策定します
前提
2020年JaSST東北（筆者は参加していない）でワークショップのお題として使われたり、VSTePワークショップ（こちらは参加しました）でも、テスト観点出しの対象としていた「かんばんりすと」を使って仮想的に品質保証計画を策定します。
テスト担当部門あるいはテスト担当者に、テストの依頼が来るタイミングは、いろいろかと思います。
今回の事例のように、既に触れるモノがあるといった状況は、実際には無いことの方が多いですし、テスト担当へのインプット時期が、テスト開始ギリギリで、十分なテスト計画策定時間がとれない中でのテスト開始の場合もあると思います。
ユーザー・マニュアルが手元にある点も、前提とします。
また、ある程度のe2e自動テストの導入経験があるというのも、前提になっています。（注2）
テスト対象を軽く触ってみる
ユーザーマニュアルを片手に、テスト対象を軽く触って、どんなことができるアプリケーションなのか、何が嬉しいのかについて、一通り・簡単に確認します。なんだか既にテストが始まっている感が、なくもないですがあくまでも、テスト対象の理解を主目的とします。マニュアルやアプリケーションの機能数などに因りますが、画面や代表的な機能ごとに、1時間を限度として作業してみます。
ここで、1次案としてのテスト章立てが定義されます。画面とかマニュアルの機能説明が単位になります。
1時間に収まらない章立ては、分割しましょう。
かんばんりすとは、割とシンプルだったので、それぞれ1時間に収まりました。
1時間には、ユースケース図を書いてみたり、状態遷移図を書いてみたりする時間も含まれます。
一通り済んだら、リストを作成します。
- どんな時に使う機能なのか
- この機能の何が嬉しいのか
- 誰が使うのだろうか
を考えてみながら、リストを作成します。品質保証計画のベースライン1次案みたいなものです。
開発側からベースラインが提示されている場合にも、要望の背景についてはできるだけ聞き出しておくのが良いと思います。
| 機能 | その機能によって実現される要望や背景 |
|---|---|
| タスク登録 | タスクを登録したい |
| タスク優先度更新 | タスクの優先度（Low / Middle / High）を更新したい |
| タスク状態更新 | タスクの状態（ToDo / Waiting / Doing / Done）を更新したい |
| タスク削除 | タスクを削除したい |
| フィルター | キーワードを使って、含まれるタスクのみ表示させたい |
| Book操作 | カテゴリー（Book）を使って特定のカテゴリーのタスクのみ表示させたい |
| dashboard | 全カテゴリーのタスク状態、DONEの数、を表示させたい |
| レイアウト変更 | HOME画面のレイアウトを変えたい。 |
| ポモドーロタイマ | 思考時間を集中できる25分を限度としたい |
| Done List | 完了したタスクを表示したい |
軽く触っているといろいろと気づきもあります。バグかな？ と思うこともあるかもしれません。
手元に記録しておくのが良いと思います。ここでは、あまりバグについて深堀りするというより、テスト対象への理解を深めることを優先します。
自動テストを少しだけ動かしてみる
未だ全体像がバクっとしていますが、ここで自動テストを試します。
専任のTAEさんがプロジェクトに居る場合は、相談するのも良いでしょう。
利用する環境で制約を受けたり、自動化が難しいテストも、実際には存在します。最近では、playWrightやCodeceptJSなどのローカル実行環境を使ったり、MagicPod等のSaaSを使うことで、Seleniumを利用したテストコードを記述するよりも、簡単に自動テストが試せるようになってきました。ここで試す目的は、短時間で自動テストがどこまでテストできるかの”あたり”を付けることです。
筆者はWeb画面上の要素をドラッグ＆ドロップして移動する操作を自動でやったことがなかったので、結果的にCodeceptJSを利用して実装してみました。注3）
- タスクの登録と優先度や状態の変更、変更結果の表示反映
- Book操作で選択されたプロジェクト表示における、タスクの数（優先度、状態別）検証
- dashboardにおける、タスク優先度と状態表示の検証
- DONE List画面にて、タスク数の検証
- タスク削除
マニュアルテストと自動テストとの役割分担を決める
自動テストにできるけど、マニュアルテストで深掘りしてみて、結果次第では次回から自動化が適当と判断したテストとしては、
- フィルター機能と、Book切替えの状態遷移
- Book切替えからのdashboard画面への遷移と、タスクへのリンククリック操作によるHome画面
- DONE Listからのdashboard画面遷移
触っている内に、どうやらBook切り替えで絞られたカテゴリーは、dashboard画面やDoneList画面に遷移しても、再びHOME画面に戻った場合に”保持”されていそうなことに気がつきます。
これは例えば、再優先で参画しているプロジェクトについてタスクを確認したいけど、dashboardでは、他のプロジェクト含めた全体像を確認したいといった要求がありそうなことに気がつきます。
テスト開始初期の自動テストをどこまでやるかは、100%を目指さない方が良いです。これは現状の有り姿が仮にバグで修正された場合、自動テストスクリプトが受ける影響範囲が広くなるからです。
自動化をもっとしたいところではありますが、タスクの数を表示する機能にバグが無いことの確認が大部分を自動化できたことだけでも、安心して、状態遷移テストに集中できる安心感はあるかと思います。
ここまでの作業で、もう一度、ベースライン1次案を見直して、テスト章立てを決めていきます。
特に、「ユーザーマニュアルに書かれていない、とんがった機能は、ないのか」を考察します。
ここでも作業中に気がついた現象は、手元の課題リストにどんどん書き込みます。注4
| テストスィート名 | テスト概要 |
|---|---|
| タスク操作テスト | Doneへの移動は禁止の確認。チェックボックス操作のみの確認。 |
| フィルター機能Book絞込みテスト | プロジェクト横断的なタスクが表示できるかの確認。 カテゴリー（Book）を使って特定のプロジェクトのタスクのみ表示できるかの確認。 カテゴリーの追加のみできるかの確認。 dashboardの最終更新日やタスクの状態で分類されたリストからのリンクは、カテゴリーを絞った表示になるかの確認。 |
| タブレット端末テスト | タブレット端末から使って、レイアウト崩れ等が無いかの確認。 |
| ポモドーロタイマテスト | 時間いっぱいになったら、休憩を促すメッセージが出ることの確認。 F5キーで歩進停止することの確認。 |
| Done Listテスト | 完了したタスクの完了月・時刻が、0時から9時に更新した場合も当日の日付と時刻になることの確認。 |
自動テストのテストスィートは、「タスク操作テスト」になりました。
Doneへのドラッグ＆ドロップはできないことの確認のみ、マニュアルテストになります。
自動化できるかもしれませんが、Doneへのドラック＆ドロップは、絶対にできてはいけないという探索的テストとして、意図的にマニュアルテストとして残しました。
フィルター機能とBookの絞込み機能とDoneList機能とを組み合わせて使う状態遷移テストがありそうです。
プロジェクト横断的なタスク（例えば、セキュリティ対策の修正とか）をフィルターでかき集めて表示したいといった使い方もするかもしれません。そんなシナリオもテストケースとして用意します。
また、プロジェクトメンバーは、必ずしも国内だけとは限りません。DoneListに記録されるタイムスタンプは、どこの国の時刻なのかも、確認するテストケースを用意します。本当は、レビューで明確にしておきたいところです。
ポモドーロタイマで制限時間になったら、メッセージボックスが出ることも触っている内に判りました。
品質保証計画を策定する
テストスィートが決まりましたので、ここまでの作業成果物を品質保証計画として記述します。
機能についてのテストと、それ以外の観点で実施するテストとを分けて、テストスィートが、どこを分担するのかについての星取り表です。
ベースラインとは別に、品質保証の観点からどんなテストになるのかについても記述します。
QAオリジナル部分は、開発側にテスト仕様レビューを行っていただく時の、つっこみ処です。
どんな観点を持ってテストに臨むのかをテスト前につまびらかにしておくと、開発側も気づいた事は全てでは無いにしてもテスト前に修正するといったことも実際にあって、シフトレフトに少しは貢献できると思います。
総括
マニュアル片手に実際のアプリケーションを触ってみたり、自動テストを試してみたり、
品質保証計画を策定するにあたってのアプローチとしては、正攻法とは言い難いかもしれません。
しかしながら、自動テストで担当できるテストが早い段階で明確になれば、Excelやスプレッドシートに大量のテストケースを記述した後で自動化できないかの再検討する必要も少なくなります。
品質保証についてQA独自に考える行為は、開発や実装する側とは異なった見方をする点で大切なプロセスと言えます。
詳細に記述したテストケースを開発者にレビューしてもらおうと思っても、実装が佳境を迎えているような時期には、なかなか難しいと思います。抽象度が高い段階でのドキュメントならば興味を持ってレビューしてくれるかもしれませんし、自動テストのアイデアが開発者から出ることだってあります。
次回は、テストスィートが固まったのでテストケースを記述し、テスト管理ツールを利用してテスト計画の作成と実行を行なってみます。
注1：
2022年12月現在、稼働していないのか、アプリケーションエラーになっているようです。
注2：
MagicPodなどのSaaSや、CodeceptJS、Cypressといったフレームワークを使うのも良いです。
注3：
CodeceptJSを使った自動テストのテストコードは、ここにあります。
注4：
テスト依頼をした開発者は、テスト担当の作業進捗を気にしだします。日報などの報告の機会がある場合、手元の気づきを連絡してあげると、既知の課題だとしても、テスト対象について理解を深めてくれていると安心するかもしれません。