【JaSST'20 Kansai】参加しました：テストのための分解と再構築
こんにちは、とのの（@tonono2587）です。
Tokyo以外のJaSSTに初めて参加したので記録します。
今回のテーマ：【JaSST'20 Kansai】に参加しました
2020年9月12日(土) ＠オンライン開催 JaSSTソフトウェアテストシンポジウム-JaSST'20 Kansai-開催要項
参加背景
開催概要を読んで、テーマにひかれました。
レビューしてもらっていたテストがレビューするテストになって、
無意識でやっていたことを言語化しないといけなくなってきました。
そのヒントになりそうかも、と思ったことが一番の参加動機です。
その他には、
- オンライン開催で移動時間ゼロ
- ゆもつよさんの講演があるー！
みたいなことが参加しようと思った理由です。
メモと思ったこと
基調講演
s1-1 見えないものと取っ組み合う
- テスト分析をするときに、文書の記述を読むとなんとなくわかったようになるが、実はイメージがつかめていないことが多い
- 見えないまま扱うのではなく、見えるようにする
- その手段のひとつとして、「テスト視点でのモデル化(視覚化)」 がある
- 視覚化することで理解が進むし、共通理解も得やすい
- ただし、モデル化はハードルが高い。。
- あまり構えずにとにかくつかってみましょうよ！
□感想
モデル化のススメ という感じでした。
読むだけでは実はイメージがつかめていないことが多いので、モデル化して可視化してみよう！
モデル化するためには、取り扱える大きさまで分解する必要がありそう
描いてみてわかることがあるので、とりあえず描いたらわかる、というのが刺さりました
何から手をつけたらいいかわからない人にこういう話はよさそうです。
s1-2 テストの視点でシステムを分析する
- ビジネス戦略からシステム要求がつくられていくから、顧客をビジネス視点で分析したらテスト要求にも繋がるはず
- 方法1：ビジネスモデルキャンバスや、PEST分析
- 方法2：USDM（要求仕様記述手法）によって整理しテストをつくる（再構築する）
- USDMの教え：要求は日本語で表現できるものではならない、「言葉で書けないものをつくってはいけない」
- 方法3：リスク分析からテストをつくっていく
- 方法4：過去の問題分析、テキストマイニングで俯瞰的に見て、主観を除いて新たな気付きをえる
□感想
知らない手法をたくさん教えてもらいました。
USDMを型通りやる時間はなさそう、と思ったものの考え方はとてもためになりそうだと思ったので調べてみよう
いままで気にしてなかったけど要求の整理はしっかりやったほうがよさそう
s1-3 テストの視点でシステムを分析する ~アジャイル開発を例に~
- 要求がテスト可能な状態になっていない現状
- 複数のシステムを組み合わせた「サービス」としての提供になった
- 従来の仕様ベースのテストだけは不十分になった
- 上流工程から「品質」を考えるようにする
- 要求の「完成」を定義して、受け入れ条件を決めて、それを整理する
□感想
上流から品質について決めておくことは大事なので、
アジャイル開発での例を見ながらその決め方を知る
決めた品質に対して、テストをつくっていく…？
自分の中での置き換えや抽象化が難しくて全然噛み砕けていません。。
招待講演
ゆもつよメソッドによるテスト分析の成り立ちと狙い
- 分析結果は客観的、「これだよね」ってなるもの。ひとつしかないし、答えは同じにならないといけない
- 設計結果は主観的、「私はこれだ」ってなる。いろんなアイデアがある
- 要求分析をして要求をちゃんと理解したあとに、それをおこしたものが仕様
- テスト設計とは、テスト条件を網羅するためのテストケース設計モデルの選択をすること
- どこを何でモデル化するのか、そのモデルを決めることが設計
- モデル化 とは、必要なものを取り出し、不要なものを削ること
- テスト分析はドメイン知識、テスト設計はテスト設計スキルが要る
- テクニックを知っているほうがテスト設計はうまくできる
- 両方100％持っている人だけを集めるのは難しいので、適性に応じて役割分担する
ーー
◆ゆもつよメソッドのメリット
- 最も大きなメリットは、（大きく捉えて）テスト対象を網羅しているかがわかりやすいこと
- 当たり前すぎる仕様はドキュメントに書かれないことが多いので、仕様書を細かく見ているだけだと当たり前なテストは漏れる
- 可読性アップ
- どこに何が書いてあるかわかると読みやすい
- テスト設計技法利用度アップ
- 解釈のブレ度合いダウン
- ドキュメントフォーマットと実施順序のルール化
- 複数人でテスト設計をするとき、記述内容をあわせる
- 書く項目に対して何を書くかルールがある
- お互いにレビューしやすくなる
- 設計の守備範囲がどこからなのかわかるし、設計するときも分析結果を見ながらできる
ーー
- テストカテゴリーをつくりたいから、もう少し抽象的な示し方が「論理的機能構造」
- 自分のプロダクトはよく知ってるし、パターンはある程度決まっていた
- でもコンサルやるとなると、経験したことのないドメインに対して、これらを適用しないといけない
適用できるようになってないといけない
とにかく大事なのは、何を確認したいテストなのかがわかること
- どんなテストをしたいかわからないと、レビューもできないし
ーー
◆ゆもつよメソッドの変遷
- ドキュメントフォーマットを決めた
- 論理的機能構造からテストカテゴリーをつくるようにしていった
- 仕様項目の特定パターンを研究中
ーー
- どんなテストをしたいのかわかるようにする
- どんな結果を確認したのかわかるようにする
- どれくらい広く、どのくらいのバリエーションでテストするのかわかるようにする
□感想
テストを分担するときに、テストケースはいきなりレビューできないし、
でもいきなり「設計して」とも言えなくて試行錯誤していました。
わたしが確認したかったのはテスト分析結果だったのか、と気付きました
モデル化によって認識合わせがしやすくなるのも、必要なものが取り出されているからなのだとわかりました。
（ログ型のメモを貼り付けるタイプだけどそうじゃないようにしていきたいな。参加レポの書き方知りたい）
まとめ
無意識でやっていたことの言語化のヒントになりました。
- 分析結果はバラバラにならない
- 設計はいろんなアイデア
- すり合わせにはモデル化がいい
- モデル化するには必要な情報を取り出す作業が要る
- ”分解”されるので、扱いやすくなる
テストの勉強をすすめるうちに、人類にソフトウェアは大きすぎる
と思うようになりました。
ソフトウェアというか、ソフトウェアテストをするには扱う情報が大きすぎる
大きいものを扱うためにまず小さくすること、いかにうまく小さくするかがポイントなのかなと思いました。
集中してきいたのであいだは結構つかれていましたが、
外出せずに勉強できて、黙々と聴けたのがよかったです。
おつかれさまでした。
