2021/5/28(金)にオンラインで開催された、JaSST'21 Tohokuのレポート。今回のテーマはゆもつよメソッド。

例年のJaSST東北は講演＋ワークだけど、今回はワーク担当がワークし、ワークの様子を参加者が見るという形での開催。自分はワーク担当としての参加で、事前ワークの3日含めて参加。準備した実行委員の方々、本当にお疲れ様でした＆ありがとうございました。

ワーク

論理的機能構造図の作成

仕様書をインプットにして、仕様書の内容を機能に分割して「論理的機能構造図」に落とし込む。論理的機能構造図は以下のような図。

f:id:mokky14:20210530021316p:plain — 論理的機能構造図

これがゆもつよメソッドの最大の特徴。(多分)
一般的なテストは、システムをブラックボックスとして、ある入力を与えたときの出力を確認する。このやり方は、システムの内部でどのような事が行われているかを意識しない(できない)ので、必要なテストが漏れる可能性がある。
必要なテストを行うため、内部構造を含めてテスト対象を理解する。また、機能の構造を理解することで、障害発生時にどこを確認すればよいかを事前に想定できる。

ワーク作成物の例

f:id:mokky14:20210530021440p:plain — ワークで作成した論理的機能構造図(一部)

不明な点があったら「分からないことが分かった」で作業を終了する
- 「テスト対象を理解する事が目的」なので、仕様書から読み取れない内容は確認する。想像で作らない。
- この図に当てはめることで、仕様が曖昧になっている箇所が分かる
- 仕様が明確であればあまり苦労せず作成できる
- 後で新事実が分かったら戻って見直す
まずは、「テスト対象をざっくり理解する」ことが大事

機能一覧の作成

論理的機能構造図に落とした各機能を一覧化し、仕様書のどこに該当機能の記載があるかを反映する。
仕様書は、開発者が実装しやすいように作成していることが多く、テスターがテストしやすいようには作られていないことが多い。機能に関する記載が仕様書の複数箇所に点在している事があるため、テスト対象の仕様の漏れを防ぎ、後から仕様を確認できるよう、一覧化する。

f:id:mokky14:20210530025138p:plain — ワークで作成した機能一覧(一部)

機能カテゴリは、大きいシステムを対象にした時に分類しやすいように使う。今回の演習は対象アプリが小さいので使用してない。後の成果物では使わないのであまり気にしない。

テストカテゴリの作成

論理的機能構造図のカテゴリ名を、テスト対象に対して開発チームが理解できる言葉にする。そのまま(入力調整とか)だと分かりづらいので。

f:id:mokky14:20210530030924p:plain — ワークで作成したテストカテゴリ

作業は以下の順で実施する。

前に作成した論理的機能構造図より、各機能で何をするのかを転記する。
各カテゴリ毎に名前をまとめる。
- カテゴリ毎に１つにまとめられない場合は複数になっても良いが、多すぎるのはNG
  - 細かすぎる名前にはしない！
- カテゴリ名は「~する」と言って違和感がない名前にするのがよい
- 貯蔵のところをデータの種類でまとめるのはNG。データが増える度に観点追加になってしまう。

ちなみにワークでは以下の名前にした。

入力調整 → 入力チェック
出力調整 → 表示
変換 → 計算
貯蔵 → データ操作

起こりうる不具合の検討

定義したテストカテゴリのイメージについて、チームメンバー間で認識の齟齬がないように、各テストカテゴリで起こりうる不具合を出し、共通認識を図る。
メンバー間での認識齟齬を防ぐことが目的。書いている内容をメンバー間で合意できればよい。正式ドキュメントにはしない。

f:id:mokky14:20210530031108p:plain — ワークで作成した起こりうる不具合

ワークでの気付き。

不具合は抽象的なものより、ある程度具体化した方がよい
- 抽象的な内容だと具体性がないため、後で認識違いが出る可能性がある
- "意識合わせのため"の中間生成物なので、不具合を網羅する必要はない
単体テストレベルの不具合は考えない方がよい

仕様項目の作成

テスト対象の機能ごとに、「何をテストするか」をテストカテゴリ毎で具体化する。

f:id:mokky14:20210530031404p:plain — ワークで作成した仕様項目

注意点とワークでの気付きなど

仕様項目に書くのは「システム」の仕様 (カテゴリに閉じた仕様ではない！)
- 自分の成果物見たら、検索結果が0件のときの仕様として、データ操作に「データなしの結果を返すこと」と書いていたが、これはデータ操作カテゴリの単体レベルの仕様なのでNG。
- 単体テストレベルの仕様は書かないよう注意する
  - システムテストで単体テストレベルの確認はやらないので
  - フォーマットがカテゴリ毎になっているため、カテゴリレベルの内容を記載してしまいそうになるので注意する
一つの要件に対する確認方法は一つとする
- ワークの中で「検索結果が６件以上の場合にページングする」という要件の確認方法として「進む・戻るが動作すること」「各ページに表示されるデータが正しいこと」と記載していたが、２つ目は「検索結果が表示される」という要件に対する確認になる
  - 観点が別であれば分けておき、テスト実施時にまとめられるのであればまとめて実施する
システム仕様のレベルでまとめるので、同一仕様を複数カテゴリに入れないようにする
- どのカテゴリに入れるかの考え方は (2021年版) ソフトウェアテストの上流設計-8 仕様項目のピックアップとテスト分析マトリクス｜Tsuyoshi Yumoto｜note に書いてた。
テストカテゴリ単位で確認するものがなければ「なし」とする
ここまで抽象的に作っていたものを具象化するため、結構混乱する
仕様項目をどれくらい具体的に書くか悩んだ。これは元にする仕様書のレベルに合わせるのがよいかな
ワークでやってない「サポート」は自分でやるとき混乱しそうな気がする

ピボットテーブルの作成

作成した仕様項目から、機能とテストカテゴリでどの程度テストを行うかを確認する。ここで全体のバランスを見て、項目数に違和感がないかを確認する。バランスが悪いものは仕様項目の粒度が他と合っていない可能性があるので、内容を確認する。

f:id:mokky14:20210530031659p:plain — ピボットテーブル

ワークでは仕様項目は検索機能しか作ってないので、検索だけカウントされてる。他の機能の「１」は「なし」がカウントされているだけ。

テスト分析はこれで終了。

感想

演習について

具象と抽象の行き来は割と出来た気がする
- JaSST東北2016でのVSTeP演習で、特定試験のパラメータばかりを深堀りして、全体的な検討をおろそかにした失敗経験が活きた気がする
- 経験大事
仕様書をベースに成果物を作成するので、開発現場にも導入しやすい気がする
- ゆもつよメソッド知らない人にも説明ができる
- テストカテゴリは１回作成したら、同じプロダクトの中では使いまわしていけそう

オンライン開催について

マルチモニタ必須
- Discord、仕様書、ワークの成果物(スプレッドシート、Miro)を開くので、モニタ1台はキツイ
  - 更にtwitterもあったけど、今回は諦め
  - PC2台用意できるなら、そちらの方がよいかも
ネットワーク品質、PC スペック大事
- 当たり前だけど、オンラインなのでネットワークが高速安定してないとキツイ
  - ワークの操作や会話が途切れると集中が切れる
- DiscordはPCのスペック求められる。共有された画面見てる間、PCのファンがずっと回ってた。
顔出しするか悩んだけど出さなかった
- Discordは背景変えられないので、後ろの洗濯物とか見えてしまう！
- 普段の仕事でもオンライン会議で映像は付けてないので、個人的にやりづらさはなかった
19:30からのアフターはムスコからNG出たため参加できず。残念
きっと主催者は準備大変だったと思う
- 本当にお疲れ様でした

現場導入への課題(自分メモ)

自分の前提：開発とQAが分かれておらず、開発者がテストも行う体制

どの工程でやるのが適切か？
- 案件の不明瞭さを確認できるというメリットがあるので、上流工程で実施するのが良さげ
どのレベルの規模の案件からやるか？
- 小規模な案件だと、テスト分析の工数が開発コストに見合わない可能性あり
「ゆもとさん」という神様がいない現場環境での落とし所の調整
- 意見が分かれたときは判断する人を決めるしかないかな
論理的機能構造図とI /O関連図の住み分け
- 論理的機能構造図は、開発で作るI/O関連図と内容が一部被ってる
  - 開発する側からすると、同じような内容のドキュメントを複数作らせるのは嫌がられそう
- I/O関連図と置き換える形で、開発ドキュメントにできるか？