テスト設計コンテスト'20 テスト要求分析チュートリアル

　今回、自身初のオンラインイベントに参加してきました。「テスト設計コンテスト'20 テスト要求分析チュートリアル」というイベントです。

テスト設計コンテスト

　テスト設計コンテストとは、ソフトウェアテスト技術の向上と促進の機会を提供する場として、 JaSST‘11 Tokyoより開催しています。 テスト設計コンテストでは、指定のテストベースに対してテスト設計を行い、その優劣を競います。
http://aster.or.jp/business/contest.html

　コロナウイルスによる影響でイベント関連はほとんどオンラインでの開催となっていますね。こちらのイベントも当日YouTubeのライブ配信となりました。
　テスト設計コンテストのチュートリアル自体は、一昨年のU-30とOpen版に初めて参加して既に一度参加済みなのですが、今回はオンラインということもあり調整がつけやすく参加し易かったので改めて参加をさせていただきました。オンライン最高ですね。
　ちなみに、私が初めて参加した社外セミナーもこの「テスト設計チュートリアル」でした。それまで前職では毎日仕事が残業続きで、そういった外部との交流はほとんどなかったのですが、転職して業務後の時間が自由に使えるようになった時、こういった外部セミナーが各地で行われているということを初めて知りました。そもそもテストの経験があったとはいえ転職してQAという業務を始めたばかりで、私としても色々と勉強したいという気持ちがあり、とても新鮮な気持ちでとても緊張して参加したのを覚えていますｗ

テスト要求分析

　さて、今回のチュートリアルでは「テスト要求分析」がテーマでした。テスト要求分析は「要求を集める」「要求を分ける」「要求を整理する」のプロセスを上手く回すことで、よりテスト設計の品質を上げていこうという話でした。
　テストに限った話ではないですが、ソフトウェア開発においては上流工程の取り組みや事前の取り決め・準備がとても重要だと考えています。最初に取り組むうえでのコアとなるものをしっかりプロジェクトで決めておくと後で問題が生じてもブレないので、後工程で問題が発生しても対応がすぐできます。テスト設計を行う前に分析を行うというのはとても重要です。

要求を集める（準備含む）

　テストを開始する際にテスト対象や仕様書のようなドキュメントの類が既に手元にあるならば、まずはそこから要求を集めるのが一番早いですよね。ただ最近はソフトウェア開発手法がウォーターフォール開発からアジャイル開発へ変化しており、事前にしっかりとした仕様書などを作成しないまま開発が進んでいき、その中でテストを進めていく経験をされている方も多いと思います。そんな時こそたくさんの情報を集めて自分たちの判断材料にしたいですね。

要求を分ける（分解、分類）

　分解と分類を行き来しながら、集めた要求を欲しいアウトプットに近づけるという話でした。テスト対象分析結果の識別を行う手法として3色ボールペン法について話がありましたが、私も昔、要求が色々な資料に散らばっているときは真っ白な紙やホワイトボードに「基本動作」「条件により変化がある動作」「確認事項」の3つの枠に分けて書いて分類していくというやり方をやったりしました。手段は異なりますが似たようなことですね。

要求を整理する（構造化）

　最後に集めて分けた要求を画面で構造化してみたり、遷移図を作ってみたりして整理するのが「要求を整理する」プロセスです。
　その際情報が足りなければ、また「要求を集める」など前のプロセスに戻ってみたりしてみることが、要求分析やテスト設計の品質を高めていくことに必要だということでした。
　要求は整理しておくと他のメンバーの助けにもなりますし、ステークホルダーとの認識合わせにも活用できるので良いことずくめですよね。時間がなかったりすると分析を疎かにしがちですが、課題を持ったまま開発が進み、後で問題となって発覚してからでは、製品や仕様のつじつまを合わせるのに本当に労力を使うのでそういうことはできるだけ無くしたいですね。

最後に

　私はウォーターフォール開発とアジャイル開発のどちらも経験があるのですが、アジャイル開発の方が要求を集めるというのがとても大切になる、特に要求を集めるうえで重要となってくるのがコミュニケーションスキル、またはテキストコミュニケーションスキルだと感じています。今回のチュートリアルでもステークホルダーから要求を集めるという話がありましたが、使用者や開発メンバーの他にも組織における経営層であったり営業部門の要求などは、本当に多種多様で必ずしも意見や思惑が一致しているとは限らないため、そこをみんなが納得できるような製品にどれだけ近づけることができるかは、とても大変ですがとてもやりがいを感じます。QAエンジニアっておもしろいですね。ちなみに最初に読んだソフトウェアテストの書籍は「知識ゼロから学ぶソフトウェアテスト」でした。参考までに是非。

知識ゼロから学ぶソフトウェアテスト 【改訂版】