2016/5/20(金)のJaSST東北2016のレポート。
今年のJaSST東北2016はVSTeP(ブイステップ)祭りだった。
基調講演 VSTePによるソフトウェアテストの開発 ー 西 康晴 ー
VSTePとは?
テスト設計の技法の一つ。
(他のテスト設計技法は、HAYST法、ゆもつよメソッドがある)
VSTePの流れ
- テストケースをざっくり考えてから具体化する
- いきなり細かく考えると抜け漏れが発生しやすくなる
- まずは「負荷」とかざっくりした観点で考えて、具体化していく
- 全体像を把握するための図を描く
- Excelの表だと全体像の把握は難しい
- 図の形式やツールにはこだわらない。全体像を把握するのが目的
テスト要求分析
テスト観点図を作成する。
- テスト観点を思い浮かべて、線でつなげる
- 観点を詳細化していく(親観点から子観点を引く)
- 関連する観点を線でつなぐ
テスト観点図の作成方法は、トップダウン型とボトムアップ型の2種類がある。
地図見るのが得意な人はトップダウン、苦手な人はボトムアップてやるのが良い(らしい)。
実際にはトップダウンとボトムアップを循環させながら進める。
テスト観点を導き出した理由・意図を明確化することが大事。
意図が分かっていれば、意図が間違っていたのか、意図通りに行かなかったのかが後から分かる。
テストコンテナ設計
テスト観点をグルーピングする。
コンテナはテストのカテゴリを示す(機能テスト、負荷テスト、セキュリティテストなど)。コンテナは単数または複数のテスト観点をグルーピングしたものとなる。
- コンテナを設計し、テスト観点と対応させる
- テストコンテナ図を作成し、各コンテナの実施順序(テストの順序)を検討する
テストの順序はテストの戦略になる。
テストフレーム設計
テストケースのひな形(骨組み)を作る。
テストケースを実施するために、どの観点を組み合わせて試験を行うかを設計する。具体的な値は詳細設計で考えることとし、ここでは観点の組み合わせのみを考える。
テスト詳細設計、テスト実装
普通のやり方でよい
- テストケースのひな形に具体的な値を入れる
- 値を入れたひな形を手順に具体化する
導入にあたって
- いきなり全部導入するのではなく、自分が困っているところに入れてみるのがよい。
とりあえず導入してみて、ダメなら止めればよい。 - 最初から完璧を目指してはいけない。
大事なのは困ること。困ったことを自覚して、図にして、直して、納得すること。 - 観点の抜け漏れはしょうがない。それが自分達の現在の技術レベル。
- 観点網羅を目的にしない。観点が「もう出ない」ことをチームで合意する事が大事。
- 観点として必要だと思わないものも観点として明示した上で「不要」であることを合意する。
- 「これさえあれば、何も考えなくても作業できる」とかはない。単純作業したい、自分の頭で考えない、言われたからやる、というような人や組織では導入しない方が良い。
演習
Lhaca+の解凍機能を題材にしたワークショップ。
以前のソフトウェアテスト勉強会でもやった題材。
テスト観点図
自分らのチームで作成したテスト観点。
ファイルのパターンを重点的に抽出。それ以外は、パラパラと出ていたテストケースに対して、ボトムアップで観点を付けた感じ。
何だか網羅性がなくて気持ち悪いと思っていたら、その不安が後で的中する形に。
テストコンテナ
写真撮り忘れた。
うちのチームでまず作ったのはこんなコンテナ。
- 解凍テスト
- コンテナに含めた観点
- (インプットとして)圧縮ファイルバリエーション
- (実施手順として)人による操作
- (アウトプットとして)出力先
- コンテナに含めた観点
実際にテストするときは、ファイルパターン×解凍機能の呼び出しパターン×出力先のバリエーションでの組み合わせテストになると考えて作ってみたけど、こんなんで良いのかとモヤモヤして、西先生に助言を頂くことに。
西先生からは「何をテストしたいのか?」「コンテナに入れる観点は、テストしたいもの。実施手順は観点ではない」というコメントを頂きました。
このコメントを受けて作りなおしたテストコンテナ。
- 解凍テスト
- コンテナに含めた観点
- 圧縮ファイルバリエーション
- コンテナに含めた観点
「解凍ソフトとして、色々なバリエーションの圧縮ファイルの解凍ができる事」を確認するテストとして、コンテナ作成した。 演習はここで時間切れ。
振り返り
- ファイルの観点を先に深堀りしたのは失敗だった(と思う)。
ファイル観点を深堀りしただけで満足してしまい、それ以外の観点をあまり考えないままテスト観点の作成を終えてしまった。
- テストコンテナの作成では、深堀りしたはずのファイル観点は入れる事すら出来なかった。
- そもそも、ファイルの種類が重要な観点だとは考えてもいなかった
- テスト観点の全体像を作成して、重要と思う観点をチーム合意して、その観点を深堀りするよう進めた方が良かったかも。
- テストコンテナの作成では、深堀りしたはずのファイル観点は入れる事すら出来なかった。
- チームの意識が、観点の抽出よりも、細かいテストパターンを出す方に意識が行っていたと思う。
テスト観点の抽出に意識を向けるよう、ファシリテートする技術が必要。 - 「プロダクトとして大切なのは何か」をチーム内で合意出来てなかった。 それぞれが、考えがバラバラなまま進めてた。
- VSTePを使うには慣れが必要。
- 自分のチームではテスト戦略まで考えられなかったが、他のチームが言っていたテスト戦略は興味深かった。テストの順番がテストの戦略という事がよく分かった。
- 性能テストは早い段階で実施する。理由は、性能に問題があった場合、改修が大変なので。
- 製品の品質を上げる事が先なので、製品の魅力テストは「当たり前品質」を確認した後に実施する。
感想など
去年のソフトウェアテスト勉強会でやったゆもつよメソッドと比べると、ゆもつよメソッドは仕様書をインプットにして観点上げるのに対して、VSTePは仕様書をインプットとせずブレストで観点上げる形なので、現場導入のハードルは高いように思う。
一方、他のチームで出ていた「魅力テスト」というコンテナとかは、仕様書からは絶対に出てこないテスト。これは「仕様書を見ずに観点を上げる」事による効果だと思う。
とは言え、プロジェクトにも寄ると思うが、仕様書見ないでテスト項目上げるのは、実業務ではハードル高い。
むしろ、設計入る前とかのブレストの方が使えるかも知れない。
あと、設計が実装に寄りすぎて「そもそもこのプロダクト何したいんだっけ？」な開発では有効かも知れない。(そもそもそんなプロジェクトは炎上案件だけど)
あと、現場導入時はファシリテート出来る人がいないと崩壊するのが目に見える。
幸い、ソフトウェアテスト勉強会でまた実施するそうなので、引き続き実践してみる。
リンクなど
VSTeP
当日のToggtter
JaSST'16 Tohoku ソフトウェアテストシンポジウム 2016 東北「テスト開発しちゃいなよ！～テスト設計との違い～」 #jassttohoku - Togetterまとめ
