はじめに

こんにちは、本田技研工業遠野です。
ソフトウェア内製化チームでQAエンジニアをしています。（QA＝Quality Assurance、品質保証）

先日、ソフトウェアテストのシンポジウム”JaSST'24 Tokai”へ参加してきました。
こちらはワークショップに関するレポートです！

ワークショップ：【テスト設計初心者向け】テスト観点からテストケースを作ってみよう！

VSTePてなに？
- テスト観点図
  - マインドマップを使ったり
- テストコンテナ図
- テストフレーム
テスト観点ってなんだ？
- 具体化するとテストケースの一部になるような情報
- テスト対象のテストすべき側面、テスト対象の範囲やつくり、テスト対象が達成すべき性質
- 参考：観点出しの方法
  - 8〜9割のひとがよく使う
    - マインドマップ
    - 組織の観点リスト
  - 意地悪漢字
  - Ostrandの4つのビュー
  - 品質特性
VSTePでの観点の出し方
- 観点図からいきなりテストケースをつくるのではなく、テストフレームをいったんかませる
- 観点が出た状態で、テストフレームやテストケースをつくっていくのが今日のスコープ
テストフレームのつくりかた
- テスト観点図から必要なものをコピペしてもってくる
- つなげる

VSTePの考え方では、テストフレーム作成時は関連するものは並べるにとどめる
テストケース化するときに具体化する
たくさんの観点が並んでいるとき、ケースがそれを網羅しているかわからないからフレームにする

■テストフレームの大きさ・抽象度の判断はどうなる？

■この工程はプロセス上のどの段階にやること？

■青い付箋(観点/機能/パラメータ…)どうしの関連、依存関係はいつ議論するのがいいか

テストケースに落とし込むときには必ず必要
バランスどうやってとる？
設計の段階的詳細化と同じかも
- 入力/出力がパキッと決まっているときはそこまでフレームは要らない
- テストフレームを何段階かかませて決める場合もあるので、ドメインによるのではないか
- わかっていれば、テストフレームを書く必要はないのでは？

便利だけど、再現性はあまりない
新人が見逃しそうな観点がピックアップされていて、結構役に立ちそう

単に仕様書をかませるだけだとあまりいい結果がなかった
今日は表形式で出力された
これが正しいか、見極める必要がある
出力自体は簡単にできる
こちらも再現性の確保は難しい

合っている合っていないを人間が判断しやすいので、これは使いやすい
（感想より）漏れている、抜けている観点は合意の問題なので、そこの合意が抜けないといいな
→プロンプトがシンプルなので縛りがなかったが、実際使うなら◯◯の観点で評価して、というところも必要かも

支援があってもスキルの重要性はかわらない
制約を与えて使う必要があるのではないか
レビューに対しては有効な支援だと感じている

VSTePを使って手を動かしてみるのは初めてで、特にテストフレームをつくる部分は難しく感じました。
手が止まってしまったので、フィードバックがもらえる状態で試せたのがよかったです。

VSTePを上手く使えたとは正直思いませんが、実務をするうえでのヒントにはなったと感じています。
具体化していく作業に対して、「いい感じの大きさで上手くまとめる」ような抽象度をあげる向きは
テストでは難しい作業なのかもしれないと思いました。

厳しい現実が刺さったり、事例から学んだり、1日よいインプットになりました。
個人で手を動かしスキルアップしつつ、組織で大きいことを達成していけるよう動いていけたらと思います。

参加レポートは以上です、ありがとうございました！