JaSST'21 Tokyoに参加して、テスト技法の必要性を考察してみた
こんにちは、カトです。
2021年3月15日～16日に開催されたJaSST'21 Tokyoに参加してきました。
私が参加したセッションはこちらです。
| セッション番号 | タイトル |
|---|---|
| A0) オープニングセッション | ― |
| A1）基調講演 | Being Agile about Architecture |
| B2）テクノロジーセッション | JSTQB AL テスト自動化エンジニア シラバスの概要＆見どころ！ |
| F3）チュートリアル1 | 価値につながる要件・仕様からテストを考える |
| F5）チュートリアル2 | JSTQB Advanced Level テストアナリストのシラバスでテストプロセスとテスト技法を学ぼう |
| F6）基調講演／招待講演者チュートリアル | QA2AQ – Being Agile at Quality: Values, Practices, and Patterns |
| D8）一般公募セッション | 仕様整理のためのテスト設計入門 |
| A9）招待講演 | パターンQA2AQによるアジャイル品質のマインド、体制、プロセス、技術 |
F5とD8で、テスト技法に関するセッションを聴講し、テスト技法の必要性を再認識しました。
そこで、「テストケースとセットで、テスト技法を残した場合とテスト技法を残さなかった場合に、どんな差が生まれるのか」をテーマにして、社内でQAエンジニア向けに共有会を実施しました。
共有内容
ワークショップで使われたカレンダーの仕様がわかりやすかったので、「カレンダーの色分け」を例に考えていきます。
カレンダーの日付を確認して、表示色が仕様通りかを確認するテストケースを作成していきます。
テストケースを作成する
今回は、テスト技法としてデシジョンテーブルを使います。
テスト技法とテストケースをセットで残した場合
これを見た人の反応はどうなるでしょうか？
きっと、テストケースを確認しやすいと感じるはずです。
テスト技法とテストケースをセットで残さなかった場合
これを見た人の反応はどうなるでしょうか？
「そんなおかしなことをするなんて、ありえない」と思いますか？
この例では、テスト対象が慣れ親しんだカレンダーで仕様も複雑ではないので、そのように思うかもしれません。
しかし、実際に業務で扱う仕様は複雑で入り組んでいるので、予定外なテストケースを追加してしまう可能性もあるのです。
翌年のケースにメンテナンスする
無事に2021年対応のテストが完了したら、2022年対応に向けてメンテナンスをしていきます。
テスト技法とテストケースをセットで残した場合
デシジョンテーブルに変更はありません。
デシジョンテーブルをみながら、テストケースを修正していきます。
はい。スムーズです。
テスト技法とテストケースをセットで残さなかった場合
混沌としてきました。
仕様追加が発生する
カレンダーの仕様としては違和感があるかもしれませんが、色分けを追加することにします。
製品・サービスの開発現場では、新規開発だけではなく、追加開発することが多いので、例題として対応してみます。
テスト技法とテストケースをセットで残した場合
水曜日の確認のため、デシジョンテーブルを更新します。
デシジョンテーブルに合わせて、テストケースも更新します。
迷うことなく、追加に対応できました。
テスト技法とテストケースをセットで残さなかった場合
翌年に変更した時点で、何をテストしたいのかわからなくなってしまっています。
何をテストしたいのかわからない状態のテストケースに対して、仕様追加に合わせたテストケースを追加することが難しくなってしまいました。
結論：テスト技法とテストケースはセットで残す
レビューイにとってのメリット：
テスト技法を成果物として残すことで、レビューイである初回の作成者の思考整理だけではなく、メンテナンス実施者にとっても迷いがなくなります。
レビューアにとってのメリット：
レビューアは、テストケース1つずつを見なくてもテスト技法を見ることでテストケースの過不足を確認できるようになります。
テスト技法を共有し受け継ぐことは、レビューイにもレビューアにも効果があります。
JaSSTに参加し、さらにJaSSTの学びを社内のQAエンジニアと共有することで、テスト技法の必要性を再認識する機会になりました。
場面にあったテスト技法を使うことは、テスト工程だけではなく、仕様検討や設計の際にも有効になる手段です。
私は、QAエンジニアが製品開発のすべての工程でテスト技法を使いながら関わっていけるチームをつくっていきます。
