概要
前回、「かんばんりすとの品質保証計画をつくってみた」で、品質保証とテストの関係、テストの概要が決まりましたので、具体的にテストケースを記述して、テスト管理ツール（CATを使います）を利用してテスト実施と進捗管理をしていきます。
ところで、テスト管理ツールで、自動テストもマニュアルテストも、混ぜこぜ管理する目的ですが、筆者は以下のように考えています。
- 自動テストで見つかるようなバグが本当にあるのかの記録
- マニュアルテストが、例えば少ないテストで効果的にバグを見つけられているのかの評価
- 自動でもマニュアルでも、とにかくテストがどれくらい進捗しているのかを見える化
テスト対象に対する知見や、リスク分析についても浅めということもあり、ここまでの自動テストの範囲は、割と当たり前品質的な確認を担っているので、ほぼバグは見つからない前提です。
経験的にバグがありそうとか、大事な部分なので深堀しようとか、マニュアルテストで意図的に残したテストもありました。
そういった計画時に付けた"あたり"が、妥当だったのかの検証にテスト管理ツールを使います。
テストの依頼を済ませると開発者はテスト実施状況について気にし始めます。
- 遅れていないか
- バグ報告はどうなのか
- 修正した部分について再テストされたのか
CATのdashboardを開発者と共有すると、問い合わせ都度、状況整理したり、資料作成する手間はありません。テスト管理専任者が居ても、テスト実施者も兼任している場合も多いので、ツールのレポート機能があると助かるケースも多いと思います。
ここから、以下の手順でテスト管理ツールを利用してみます。
- CATの設定、サービスの基本設定。
- CATの設定、テストの基本設定。
- バグ修正後の再テストに対応するように、CATの設定を変えます。
- テストケースを記述します。集計に使うフィールドを追加します。
- テスト計画を登録します。
- テストを実行してCATに記録していきます。
おさらい
品質保証計画を策定した段階で、テストスィートが決まりました。各テストスィートと、テスト概要は以下のようになりました。
| テストスィート名 | テスト概要 |
|---|---|
| タスク操作テスト | Doneへの移動は禁止の確認。チェックボックス操作のみの確認。 自動テストで、タスク登録、移動（優先度と状態）、dashboard画面でタスク数の確認、タスク削除 |
| フィルター機能Book絞込みテスト | プロジェクト横断的なタスクが表示できるかの確認。 カテゴリー（Book）を使って特定のプロジェクトのタスクのみ表示できるかの確認。 カテゴリーの追加のみできるかの確認。 dashboardの最終更新日やタスクの状態で分類されたリストからのリンクは、カテゴリーを絞った表示になるかの確認。 |
| タブレット端末テスト | タブレット端末から使って、レイアウト崩れ等が無いかの確認。 |
| ポモドーロタイマテスト | 時間いっぱいになったら、休憩を促すメッセージが出ることの確認。 F5キーで歩進停止することの確認。 |
| Done Listテスト | 完了したタスクの完了月・時刻が、0時から9時に更新した場合も当日の日付と時刻になることの確認。 |
サービスの基本設定
CATに設置したサービス（かんばんりすと）の基本設定画面にて、機能名を登録します。これは、テスト分析で、どの機能にバグがあったかの集計・分析で使われます。
また、同画面でテスト担当者を追加できますので、自動テストを追加します。（下の図では、MagicPod）
アカウント切替えて使うなんて、面倒なことしてますが、ツールによっては、自動テスト結果をAPI経由で取得するような連携をしている事例もあるようです。
テストの基本設定
ここでは、再テストの設定とテスト区分を設定します。
テスト区分は、テストケースのプロパティで使われます。
CATで使われる用語は、少々特徴的な感じがするので、以下に書き記しておきます。
| CATで使われる用語 | 紹介した事例での解釈 |
|---|---|
| サービス | プロジェクト（かんばんりすと） |
| テスト仕様書 | テストスィート（タスク操作テスト等） |
おそらく、もっと大規模なプロジェクトにおいて、例えばフロントエンドチームのテストとバックエンドチームのテストが、それぞれテストを担当するような場面を想定した構造になっていると推察します。
自分の使いやすい解釈で利用すれば、良いと思います。
テストケースを記述する
テスト件数の少ないテストケースは、Qaseっぽくしたカスタムヘッダを使ってテストケースを記述します。
テストケースを新規作成して、列設定ボタンから、ヘッダテンプレートを設定します。
続いてテストケースを記述し、
プロパティで機能とテスト区分を登録します。
この調子でテストケースを記述しても良いのですが、テスト件数が多い場合は、ブラウザ画面で新規作成するより、慣れているせいかExcelの方が使い勝手がいいです。
フィルター機能_Book絞込みテストは、状態遷移テストなので、GIHOZから、0スイッチのテストケースを生成してCATに取り込みます。
尚、状態遷移のテスト量が多くなりそうな場合、特に初回テストでは、0スイッチでも十分なことが多く、ある程度安定してきてから、状態遷移図を書き直して、1スイッチ以上の状態遷移テストとすることをお薦めします。0スイッチでバグがあった場合、1スイッチ以上の状態遷移テストケースを生成しても実施できない分、無駄になります。どうしても状態遷移テストをより多く状態遷移してテストしたいならば、バグのあった状態を抜いた状態遷移図からテストケース生成して実施するのも手かと思います。
テストケースは、一度作成したら永久的に使い続けるものではなくて、適宜、状況に応じて簡単に生成できるツールを用いて、テストが有効になる工夫が、テスト期間中ずっと必要になってきます。
タスク操作テストについては、「直接Doneに移動できないことの確認」以外は、自動テストのため、こちらはExcelシートに適当な粒度で記述して、CATに取り込みます。
テストコードとは別に、テストケースを作成するのは無駄な気もしますが、バグと紐付けすることが主目的になりますので適当な粒度というのが難しいですが、かんばんりすとについては、以下のようなものにしました。作成の手間がそれほどでも無いというのも理由でした。
ここまでで、5つのテストスィートをCATの管理下に置くことができました。
テスト計画を登録する
テスト担当者については、予定入力画面で設定します。
自動テストの予定とマニュアルテストの予定は、担当者を別々に入力します。
事例では、MagicPodさんが自動テスト担当者にしていますが、判ればなんでも構いません。
「お自動さん」とかでも、全然OKです。
なお、マニュアルテストと自動テストとを、同じタイムラインで進捗管理すること自体には、あまり意味が無くて、ここではテストケース記述の結果、確定したテスト件数が予定されたかどうかの確認程度になります。
テスト実行の記録と共有
テスト管理ツールを使うメリットは、テストに専念できる点かと思います。
登録の済んだテスト計画を実行して、結果を記録していきます。自動テストについてはアカウント切替えて記録するという原始的な方法をとりました。
CATでは、結果を記録したいテストケースを選択して、一括記録機能もありますので、自動テストの結果については、まとめてバッサリ記録するということをしました。
バンドルされている集計・分析機能を利用して、マニュアルテストと自動テストとで、テスト件数や抽出したバグ件数が可視化されます。
CATに開発者アカウントを作成しておけば、共有することも簡単ですし、見るだけ権限になりますが、dashboard等の集計結果は、CATにアカウント無くても、閲覧用のURLが発行されますので共有手段があります。
総括
自動テスト（予め仕込んだ処理を一気に実行する）とマニュアルテスト（テストケースの記述に従うが、実行中の気づきも多い）とを混ぜこぜにして管理するというのは、テストの進み具合を管理するだけなら、粒度も違うし、実行スピードも違うので、適当ではないかもしれません。
自動テストはプロジェクト開発の中で、何回か実行する機会がある点、修正作業や仕様変更によって意図しない不具合発生を、比較的単純なテストで発見する場合が多いですし、マニュアルテストはテスト対象への知見がテスト中に深まって、テストの深掘りをすることで仕様上の矛盾や配慮漏れに行き着く場合も多いです。
今回の自動テストくらいの内容だと、ほぼバグには辿り着かないですが、かんばんりすではない実プロジェクトで、基本的な機能テストでバグが見つかるような場合、あるいは、仕様変更やバグ修正都度、基本機能の回帰テストでバグが見つかるような場合は、機能実装に忙殺されて確認ができていない可能性大です。
今回、ケース有り課題は0件でしたので、本当にバグが無いか、テストが効果的で無いかのどちらかです。
実プロジェクトでは、マニュアルテストを一通り済ませた頃には、テスト対象に対する知見も深まっている場合も多いですので、別のマニュアルテストを計画するのも良いでしょう。
テスト管理ツールに記録された結果から、プロジェクトの健康状態やより効果的にテストを計画していくことも可能です。都度の見直しと軌道修正のきっかけとしてテスト管理ツールを有効活用しましょう。