読者です 読者をやめる 読者になる 読者になる

JaSST'16 Tohokuに参加してVSTePについて体験してきた #JaSSTtohoku #JaSST

JaSST 勉強会 技術

告知ページ

JaSSTソフトウェアテストシンポジウム-JaSST'16 Tohoku

当日のツイートまとめ

togetter.com

基調講演「VSTePによるソフトウェアテストの開発」

VSTePの対象組織

  • 「このままでいいや、とどこかで思っている組織」はVSTePに取り組み価値が無い組織
    • 標準に沿っているから良いやと考えている組織
    • コンサルに全ておまかせしちゃえば大丈夫と考えている組織
    • 既に社内標準がしっかりしていて変えづらい状況の組織
      • しっかりしていること自体は良いことなので、わざわざ変える必要がない
  • 「このままじゃダメだ、と強く思っている組織」はVSTePに取り組み価値がある組織
    • 「仕様が無いので何をテストすれば良いか分からないからヤバい」と思っている組織
    • 「社内標準は既にあるけど、意味が無い」と感じている組織

VSTePとは

  • テスト観点を基盤としたテスト開発のための記法とテスト開発プロセス
  • 参考資料
  • テスト観点図、テストコンテナ図、テストフレームをつくることで、質の高いテストケースやテスト手順を作成する方法
  • 網羅性については考えていない
    • この作業をやって出てこなかった内容は、今の自分(チーム)の限界ということであり、漏れていたと把握できる状況にすることが大事

VSTePの構成

テスト観点図
  • テストケースごとのテストの意図を示したもの
  • テストケースの一部を抽象化したものになる
テストコンテナ図
  • テストレベルやテストタイプ、テストサイクルをまとめたもの
テストフレームとは
  • テストケースの雛形となるもの

VSTePのワークショップ

VSTePの進め方

  1. 仕様書を読む

    • どんな動きなのか把握するだけ
  2. 仕様書を読んだ感想や気になったところを一人ずつ喋ってもらう

    • あくまでもキッカケ作りなので、ここで色々議論する必要はない
  3. 付箋に観点となりそうなものを書き出す

    • これ以降は仕様書を閉じる!
    • 皆に聞こえるように喋りながら付箋に書く
      • 付箋に書いた内容が、別の内容を付箋に書くキッカケになるかもしれないため
    • 付箋に書いたものに対して詳しく聞いたり、ツッコミを入れるようなことはしない
    • 「これはテストする段階で行うものではなく、開発者が気にすべきところだから…」とか考えずに、思ったことはどんどん書く
  4. 書きだした付箋を見て、似たような内容(似たような意図で書かれたもの)をグルーピングする

    • その時、曖昧な言葉で記載していた場合は、「どういう意図で記載したのか」を書いた人に質問する
      • もしも、自分と認識が違った場合は、違う認識の点も付箋に貼る
        • 実際にワークショップ内であった例として、「メモリ」と書いた付箋に対し、「メモリ使用量」というパフォーマンス観点と「メモリ不足」というエラーの原因についての観点が出てきた。これらから、「メモリ」という付箋は捨て、「メモリ使用量」と「メモリ不足」の付箋を加えた。
      • 全員が同じ意図と理解するまで議論する。
        • 全員が理解し共有できていることが大事。
  5. グルーピングした付箋について、それらをまとめた(抽象化した)言葉を付け、ツリーを作成する。(テスト観点図の作成)

    • 例えば、「パスワード付きファイル」や「圧縮形式ではないファイル」については、「解凍するファイルの種類」とまとめた。
      • 先ほどの「メモリ不足」や「メモリ使用量」を「メモリ」とまとめることはしない。なぜならば、それぞれで意図が異なっているからである。
        • これを「メモリ」とまとめてしまうと、文字を見てまとめただけであり、綺麗なものにしようとしているに過ぎない(パット見て綺麗にすることが目的ではない)
    • 当日作成したテスト観点図 f:id:nihonbuson:20160524214341j:plain

      f:id:nihonbuson:20160524214419j:plain

      f:id:nihonbuson:20160524214449j:plain

    • 当日作成したテスト観点図をマインドマップで描き直したもの f:id:nihonbuson:20160523221445p:plain

  6. テスト観点図のトップノード(一番上の抽象化した言葉)を用いて、テストコンテナを作成する。

  7. テストコンテナを時系列で並べる
    • 当日作成したテストコンテナ図 f:id:nihonbuson:20160524214546j:plain

      f:id:nihonbuson:20160524214620j:plain

      f:id:nihonbuson:20160524214640j:plain

      f:id:nihonbuson:20160524214717j:plain

      f:id:nihonbuson:20160524214803j:plain

      f:id:nihonbuson:20160524214834j:plain

      f:id:nihonbuson:20160524214901j:plain

    • 当日作成したテストコンテナ図を描き直したもの f:id:nihonbuson:20160523221513p:plain

追加課題
  • このワークショップの最後に、「もしも圧縮機能を入れたら」という話になった。
  • これについては、「このコンテナの部分は再利用できるよね」「この観点図の部分は付箋が追加されるよね」と、一から作り直す必要もなく、メンテナンスしやすい形になっていることが実感できた。

復習

  • シンポジウムの翌日、復習を兼ねて、当日と違うグループの人と同じ課題(+Lhaca)でVSTePを行った。

成果物

  • 付箋にどんどん記載した時点の画像 f:id:nihonbuson:20160523221534j:plain

  • グルーピングした時点の画像

    • 一部ツリー化しており、この点は失敗している f:id:nihonbuson:20160523221612j:plain
前日との比較
  • 前日と違う観点が出てきた
  • しかしトップノードは似たようなものになることが多かった。
  • 途中で作業を抜ける人がいる場合、書いた意図が分からない付箋が存在することになった。
    • その際は、思い切ってその付箋を無くすことにした。
      • その付箋は抜けた人がいたからこそ出てくる項目であり、抜けたあとのチームの限界を超えているため
  • 復習会では、付箋を動かしやすい人と動かしにくい人が発生していたため、グルーピングがうまく行かなかった

感想

  • 事前の予習では、どのように観点図を作成すれば良いのか考えることが多かったが、実際に参加してみて、深く考えることなく(抽象度を気にすること無く)どんどん書いていけば良いと分かった。
  • 始める前は仕様書を見なくて書けるのかと疑問だったが、実際やってみると仕様書に書かれていないことがどんどん出てきた。