WACATE2016夏に参加して、成長しそうな予感の私のテスト
6/18土,6/19日に「WACATE2016 夏」に参加してきました。
2日間にわたり、テスト分析、テスト設計を体験するという、たいへん良い体験をしてきました。
しかし、テスト分析についてはモヤモヤしたままになっていた点があったので、振り返りることにしました。
自分なりにうまく消化することが出来たので、忘れないうちにまとめておきます。
自分はこう考えているーという方は、コメントやリツイート頂けると幸いです(^∇^)
また、WACATE的に不味そうな点は訂正しますので、ご指摘ください。
テスト分析
「テスト要求、テスト対象を分析して、テストしたいことを洗い出すこと」
セッションで福良さんは、このように紹介してくれました。
WACATEに参加するまで、私はテスト分析で何をするのか理解できていませんでした。
ですから、「テスト条件」を「テストしたいこと」ーと言い換えたり、その成果物イメージを掲載してくれていたことにより、私にはスッと入ってきたのでよかったです。
この２つが無ければすんなり理解出来なかったでしょう。
分析の手順
やり方を以下のように、実行可能な作業単位に分けられていた点も、とてもありがたかったです。
何をすれば分析出来るのかすぐに分かりました。
- 分析方法を決める
- 情報を整理する
- 成果物を確認する
- 顧客の要求（テスト要求）を分析する
- 設計書（テスト対象）を分析する
- 分析結果を整理する
分析方法を決める
私は3色ボールペンしか知らなかったので、それを選びました。
一方で、ほとんどの皆さんはマインドマップを使われていたようです。
「マインドマップってつかえて当たり前なんだ・・・」と少しカルチャーショックを受けました(^-^;
マインドマップを覚えたら便利そうですね。
他のグループの発表やチームメンバーの発表を聞いて、そう思いました。
以前Naitで池田さんの本を勉強されていたようなので、ポチって使えるようになりたいなと思ってます。
テストしたい「こと」？ テストしたい「ところ」？
テスト分析の手順を振り返っていて、混乱してしまったのがここでした。
- "システム"（ドキュメントすべて）に対して分析をしたら、テストしたい"こと"、"ところ"って粒度が異なる"こと"、"ところ"がたくさん出るよなあ
- 粒度の違うテスト条件、どうやって整理するんだろう？
- 粒度が異なるから、それぞれの粒度か、テスト条件が一度にたくさん出てきてしまい、まとめきれないんじゃないの？
などなど
情報（分析する対象）の整理
ここで、この混乱を解く為に重要な鍵となるのが「情報（分析する対象）の整理」でした。
ここでの分析対象は、配布された資料です。
当日、テスト分析、テスト設計の為に配布された資料(顧客要求、仕様書)はたくさんありました。テスト設計まで行うので仕方のないことです。
ですが、これらを整理すると、いくつかに分類できることに気づきます。
- 新旧業務フロー画面遷移図
- 各種定義書
- テストに関する顧客要求
テストし易い単位から分析すれば、その単位（同じ粒度）でテスト対象を洗い出せるのではないか、ということに気づきました。
分析対象が何かというと、上記の整理した資料です。ですから、同じ分類や粒度が同じ分析対象を、一つずつ見ていけば良かったのです。
落ち着いて考えれば当たり前なことでしたが、情報を整理しないと、こういう混乱を招くという良い教訓になりました。
いきなりすべての資料(システム全体)に対して、分析をするのではなかったのです。分析対象が大きすぎますしね(^-^;
また、これに関連して気づいたのは、テストレベルが対象とする単位、粒度で考えてもよかったなということです。
V字モデルではテストをする順番は単体（単機能）テスト、統合（複数機能）テスト、システム（機能全体）テストですから。
しかし、私はやはりテストレベルから考えるより、分析対象を整理してから、その整理した情報ごとに分析をしていく方がしっくりくるようでした。
テスト設計技法が適用できるテストレベルはある程度示されていますが、テストレベルに対応するテストタイプは、テスト対象によるーとなってしまうと思うからです。
限定された業界や業務ならば、後者の考え方でテストタイプを限定しても良いかもしれません。
分析をすることのメリット
ただ、やはり分析をすることにはメリットがあります。
グループワークの発表や秋山さんの講義でも紹介されていましたが、どうやってテスト対象を導きだしたのか考え方を人に伝えられる、という点です。
「ちゃんとテストした？」と聞かれる人(私を含め)には、とても効果的だと思いました。
テスト分析の結果として、やるべきテストが決まる
昔「やるべきテストはテストレベルごとに決まっている」と私は思っていました。そういうものだと、思い込んでいました。
などなど
何をテストしたらいいのか分からないのは、テスト分析ができていないから
ここまでくると自分が何をすべきかは、もう分かります。
分析が上達すれば、テストするところはここだよって言えるようになるわけです。
ですから、私のテスト上達の鍵はテスト分析が上達することだと分かりました。
WACATEに参加した一番の収穫です。
振り返りしなかったら気づけなかったと思います。やっといてよかった。
分解
テスト分析の上達の為に大きなヒントになりそうな手法が、「分解」です。
秋山さんが講師として紹介してくださいました。
講義では要求が大きい場合、分解を利用して、具体的な要求を引き出していくと良いと教わりました。
USDM のような思考のフレームワークを使うと、上手に分解できるそうです。
例）USDM
- 時系列
- 構成
- 状態
- 共通部分
分解した結果を説明できるように一枚にまとめる
振り返っている今だから分かるのですが、テスト分析結果がこれに当たるのかなと思いました。
例えば、「画面定義書」を構成の観点で分解すると、色々な要素が出てきます。
など
これらに対して、確認したいことを書き出していきます。
例えば、
などなど
次に、確認したいこと毎に、具体的な確認対象を明記します
例えば、テキストボックスなら
- 氏名
- 住所
など
そして、これらを確認する観点を洗い出します。
テキストボックスで見ると、
最小文字数、最大文字数、全角、半角など
どんな文字が入力できるかで分解するといいです。
要素種類で分解するのがミソですね。
個別の要素を見ないので、要素種類に共通してテストしないといけないことが分かります。
いきなり具体的な要素名から見ていくと、共通のテストしないといけないことを、個別の要素ごとに考えることになるので大変です。
この辺の手順はテスト分析の効率に影響するので、大事だと思いました。
成果物の確認
以上の分解によって成果物が出来上がります。
テスト分析の成果物は、テスト設計のインプットとなります。
あとはテスト分析の成果物に対して、テスト技法を適用してテストを設計（テストケースを作成）していくだけです。
ここまでで、テスト分析がテストの質を左右することが容易に分かりますね。
これをテスト計画やテスト者への指示に反映することで、チームとしてより良いテストが出来そうだと思いました。
チームの方への感謝
グループワークの最後に細川さんから、「テスト分析、テスト設計出来た？」という質問がありました。
私たちのチームは、テスト設計は「う～ん」でしたが、分析は「出来たと思う」人がほとんどでした。
テスト設計は個人ワークにして、やりきることを考えていたからだと思います。
逆に、細川さんが仰っていましたが、沢山議論が出来ていたから、分析については納得感があったのだと思います。
２日間を振り替えるとチーム内では、初対面ながら沢山話をしたなあと思います。進行も円滑でしたし、みなさん、コミュニケーション能力の高い方たちだなーと思いました。
テスト技術を学びに来たわけですが、みなさんのおかげで良いチームワークでよい学習が出来ました。
本当にありがとうございました。
SNSで繋がっていますので、今後ともよろしくお願いします(^∇^)
成長しそうな予感の私のテスト
2日間のワークとその振り返りを通して、私の考えた"ちゃんとしたテスト"は少し成長しようとしています。ちゃんとしていなかった点が分かったからです。
これからは「ちゃんとしたテストした？」と聞かれたら、
「これがテスト分析結果です。これを元にテスト設計をしました。分析対象は◯◯工程で作成した設計書です。」
と、言えるようになっていると思います。
成長させるのは自分次第なので、バシバシ手を動かしていきたいと思います。
WACATEに参加して良かったです。
運営の皆さん、参加者の皆さん、どうもありがとうございました。
