HOME > 活動報告 > イベント報告 > JaSST'21 Tohoku

イベント報告
 ソフトウェアテストシンポジウム 2021 東北

2021年5月28日(金) 於 オンライン開催

ソフトウェアテストシンポジウム 2021 東北

はじめに

2021年5月28日(金)に、ソフトウェアテストシンポジウム 2021 東北(JaSST'21 Tohoku)が開催された。昨年は新型コロナウイルスの影響で中止となったが、今年はオンラインで開催され、参加者127名の盛会となった。テーマは「チームでテストをうまくやる ~現場で生まれたテストメソッド~」である。具体的には、湯本剛氏によって提唱されたテスト開発手法である「ゆもつよメソッド」を、ワークショップを通じて学ぶ一日となった。

今年は開催当日に加え、事前準備会が3回実施された。参加者は協力者と一般参加者に分類され、協力者は事前準備会および開催当日のワークショップに参加し、一般参加者は開催当日のワークショップを湯本氏の解説付きで視聴した。筆者は協力者の一人として参加したので、以降は協力者の視点でレポートを記述する。

事前準備会

ワークショップの題材は架空の計算アプリである。本アプリは、いわゆる合コンの参加者が、支払金額を計算する目的で使用する。事前準備会では、テスト対象の「何をテストするか」を整理した。

事前準備会1 ゆもつよメソッドについての動画視聴

はじめに、JaSST'20 Kansai招待講演「ゆもつよメソッドによるテスト分析の成り立ちと狙い」の動画を視聴した。テストを行う際、いきなり詳細なテストケースを書き出すことは望ましくない。まず全体を俯瞰し、大まかな抜け漏れがないかを確認することが重要である。また、関係者同士で共通認識をつくることも必要である。ゆもつよメソッドでは、フォーマットに従って順番にテスト分析を行い、これらのニーズを達成する。

事前準備会2 ワークショップ モデル図の作成

最初のワークでは、論理的機能構造を用いたモデル図を作成した。論理的機能構造は、ソフトウェアの内部構造を抽象化したものである。ワークでは、例えば「計算」機能のうち、支払金額を計算する処理は論理的機能構造の「変換」、金額をカンマ編集する処理は論理的機能構造の「出力調整」として整理した。最初は各自で付箋に書き出し、次にチーム全員で共有したが、判断に迷う箇所もあった。その場合は湯本氏に質問し解決した。

事前準備会3 ワークショップ 機能一覧の作成

続いて、機能一覧を作成した。機能一覧は、テストの対象となる仕様を機能単位で再構成したものである。仕様書には、必ずしも機能単位で仕様がまとまっているとは限らないため、本工程を通じた再構成が必要となる。
ワークでは、例えば「記録」機能には「記録の修正」機能が含まれていたが、テストの対象としては記録と修正を分けた方が整理しやすいと判断し、修正機能を別機能として定義することとした。また、仕様書の章番号を転記する過程で、仕様書の記載粒度のばらつきに気づくことができた。

ここまでの一連の作業で、テスト分析を行うための準備が完了した。

筆者感想(事前準備会のワークについて)

筆者は、ゆもつよメソッドについてはある程度知識を持っていたが、実際に手を動かして経験したのは初めてであった。手を動かしてみると、メソッド内で厳密にルールとして定められている部分(例:ある仕様が論理的機能構造のどこに該当するか)と、そうでない部分(例:機能一覧上で、機能をどう定義するか)に分かれていることを実感した。特に後者について、チームで話し合い、お互いに情報を俯瞰しながら認識を合わせていくことが重要だと感じた。

開催当日

開会

はじめに実行委員長である梅津氏より開会の挨拶をいただき、ゆもつよメソッド考案者の湯本氏からお話をいただいた。その後梅津氏より、ゆもつよメソッドの概要およびワーク全体の流れが説明された。

ワークショップ テストカテゴリ作成

開催当日は、事前準備会で整理した各機能に対して「どのようなテストをするか」を整理した。

最初のワークでは、テストカテゴリを作成した。システムの内部構造が不明な場合、テスト実施者の目に留まりやすい「入力」「出力」に着目したテストを作ってしまいがちである。仮に、データベースやシステム外部との連携に関するテストが重要である場合、入出力に思考が偏ると、重要なテストが漏れてしまう恐れがある。テストカテゴリは、後工程で仕様項目を導出する際に偏りを防ぐガイドとなる。
ワークでは、事前に作成したモデル図を用い、論理的機能構造内の抽象化された要素(「入力調整」「出力調整」「貯蔵」など)に、チームで検討しながら独自の名前を付けた。テストカテゴリ名は機能一覧の各機能に割り付けるため、ある程度抽象度が高い言葉を用いる。湯本氏曰く、チームで共通認識を持てるように命名することがポイントである。例えば筆者のチームでは、「変換」のテストカテゴリ名は「金額計算」と命名した。

ワークショップ 起こりうる不具合作成

次に、テストカテゴリから想起される不具合を列挙し一覧化した。ここでは、前工程で作成したテストカテゴリと「テストしたいこと」の対応関係に対する認識を深める。テストカテゴリは抽象度の高い言葉を用いているため、具体的なテストがどのテストカテゴリに属するかについて、チームメンバー間で想定が異なっている可能性がある。そこで、「起こりうる不具合」を具体的に列挙し、各テストカテゴリに対して想定する具体的なテストのイメージをすり合わせる。「起こりうる不具合」は、後工程で仕様項目を挙げる際のガイドとなる。
ワークでは、はじめは「金額が合わない」「数値以外が入力できてしまう」などの典型的な不具合が挙がったが、チームで議論を進めると「表示が崩れる」「自分以外の記録が見えてしまう」など、仕様書に直接書かれていない不具合も挙がった。テストカテゴリ作成では抽象度を高く、起こりうる不具合作成では抽象度を低く、それぞれ議論の対象を限定することで、抽象と具体の混在を防ぎ、情報を整理しやすくなる。

ワークショップ 仕様項目作成

続いて、機能ごとに、テストカテゴリに属する仕様項目を整理した。
仕様項目では、テスト対象の「何を確認したいのか」について整理する。仕様項目は、テスト分析とテスト設計の橋渡しになる役割を担う。ここまでの工程で作成した成果物を全て用い、仕様項目を作成する。特に、仕様書の記載内容を書き出すことが重要である。また、書き出した仕様項目を「どのように確認するか」について、期待結果として記述する。ここで注意すべきポイントとして、本工程はテスト分析の一工程であるため、テスト設計を行ってはならない。
ワークでは、実行委員のモデレートに沿って「まずひとつだけ確認するとすれば何か?」「起こりうる不具合をもとに考えるなら、何を確認するか?」といった要領で作業を進めた。実施結果から一例を挙げると、テストカテゴリ「金額計算」の仕様項目「繰り上げ処理が正しいこと」に対する期待結果は「自分側の支払い割合のうち100円未満の数があるとき、繰り上げられること」となった。

ワークショップ ピボットテーブル作成

最後に、ピボットテーブル(テスト分析マトリクス)を作成した。ピボットテーブルは、機能項目とテストカテゴリごとの仕様項目数を集計し、一覧化する。これにより、テストのボリュームや過不足を俯瞰的にチェックすることが可能となる。なお、当日は時間の都合で仕様項目作成が完了しなかったため、ピボットテーブルの分析は割愛された。

筆者感想(開催当日のワークについて)

ワークごとに考えるべきことが絞られており、焦点を絞って議論を進めることができた。結果として新たな気づきを得ることができ、テスト対象に対する理解が深まったと感じる。仮に、仕様書を一読しただけでテストを設計していたら、このような気づきや共通認識は生まれなかっただろうと思う。モデレートをして下さった、実行委員の皆様にも感謝したい。

クロージングセッション

最後に、湯本氏による総括が行われた。ゆもつよメソッドを用いてテスト分析を行うには、抽象的な話題と具体的な話題を適切に切り替える必要がある。これに熟練すると、良いテスト技術者になれる。また、ゆもつよメソッドでは、仕様項目を導くための分類作成に、多くの時間をかける。この時間の中で、テスト対象に対する理解が深まる。分析とは、理解するための行為であり、分析そのものにオリジナリティは不要である。ワークでも、仕様項目を挙げる際に設計の要素が混じってしまっていたが、これは避けることが望ましい。また、ゆもつよメソッドに限らないが、いきなりテストを設計せず事前に分析を行うことが大事である。このように湯本氏は語った。

全体の感想

事前準備会の開催や、協力者のみがワークを行い湯本氏が解説するスタイルなど、オフライン開催が難しい現状を踏まえた工夫が随所に感じられたシンポジウムであった。ワークの練りこみも素晴らしく、参加者が躓く箇所や時間も含めてワークが緻密に設計されていると感じた。
ゆもつよメソッドは、完成した成果物が非常に綺麗な構成となっているため、一見その作成も容易であると錯覚してしまう。しかし、実際に手を動かしてみると、(実行委員の意図通りに)様々な壁にぶつかり、その度にチームメンバーとのコミュニケーションが必要となり、一筋縄では成果物が完成しなかった。
朝から夕方までワーク漬けの一日を過ごしたが、チームメンバー同士で深くコミュニケーションを取り、真剣にワークを進めることができたと感じる。
湯本氏や梅津実行委員長をはじめ、実行委員の皆様、そしてチームメンバーの皆様に深く感謝を述べたい。
なお開催当日は、時間の都合で仕様項目の作成以降が消化不良となってしまったが、今後何らかの形で、テストケースを作成するまで継続的に取り組みを続けたい。

記:藤原 考功 (JSTQB)

[ページトップへ]