「テストに興味がある」という点から、JaSST東北メンバーは一般的な開発者よりはテストに詳しい(ことが期待される)のですが、今回の準備会ではいろんなところでハマりました。今回は私たちがハマったポイントをピックアップしてみます。
ツリー構造の整理方法
状況
今回の勉強会に先立ち、事前にJaSST東北メンバーでツリー構造を用いたテスト観点整理演習を行っていた。できたツリーは機能の下が操作やデータになっており、統一感がないツリーになっていた。思いつくものは出したつもりだったが、見返しても十分洗い出せたか分からず、もやもやが残ってしまった。
症状
ツリー構造で整理しているのに対して、適切な上下関係になっていなかったり、同階層の要素が揃っていなかった。そのため、MECEになっているかが設計者が自信を持てていなかった。
解決
ツリー構造で整理する場合、上下関係や粒度が妥当かを意識すると良い。
- 上下関係であれば、inheritance*1かcomposition*2で整理すると良い。一般的にはcompositionの方が網羅しやすい。
- 同じ階層に並ぶ要素の言葉は合わせると良い。例えば、「設定反映」と並ぶ言葉は「設定画面」より「設定表示」の方がしっくりくる。
技術者は細かいところを気にするのは得意なので、気になったところを納得がいくように変えていくと良い。良い構造になっていると、抜け漏れに気づきやすくなる。
感想
ツリー構造による整理はテストに限らず良く使っている。しかし、事前の演習では上手く整理することができなかった。上手く整理できないときは、完成形のイメージを持たないことによる不安が根本にあると感じた。今回、納得できる整理の仕方を学んだことで、完成形のイメージを持たない「未知の対象」に対しても自信を持って整理できるのではないか、と期待している。
何をテストしたいのか
状況
テスト観点の洗い出しを行った後、テスト観点を整理していた。例えば、解凍機能を持ったアプリケーションのテスト観点で「操作」が上位階層に出てきて、その下に「ダブルクリック」や「ドラッグ＆ドロップ」が連なっていた。テストで確認したいものは「ダブルクリック」や「ドラッグ＆ドロップ」なのか？
症状
テスト観点で洗い出したものをグルーピングはしていたが、何のためにグルーピングをしていたのかが抜け落ちていた。
解決
テスト観点を整理するときは何をテストしたいのかを常に確認すること。例えば、「操作」そのものを確認したいのではなく、その「操作」を通じて別のモノを確認したいはず。
感想
観点の洗い出しさえ済んでしまえば、グルーピングはほぼ考えずにできると思っていたのが甘かった。「今自分は何のために作業しているか」は意識しておく必要がある。各作業の意味や前後の工程とのつながりを作業前にメンバー間で確認しておくと良いかもしれない。
モデリングと現実
状況
テスト観点を整理した後に、テストコンテナ設計を実施した。テストコンテナをテストを実施する時系列順に並べて、メンバー全員でできたモデルに納得していた。にしさんに確認してもらったところ、「実務でホントにこの順番でテストするの？」との指摘を頂いた。
症状
技術的な観点では作成したモデルに全員が納得していた。しかし、経験的、実務的な観点では作成したモデルは納得できないものだった。
解決
モデリングの演習などをしていると、直観からは離れたモデルになる場合がある。モデリングに慣れていない場合は、自分達の直観に合っているかをよく検討する必要がある。逆に慣習のような利点のないデザインパターンによるモデルが構築される場合がある。良いモデリングを追及すると利点のないデザインパターンを改善できる場合がある。
感想
「練習のための練習」は本番に役に立たないことが多い。新しい技術を学ぶ場合、その技術を理解することに注力するあまり、「実務に沿っているか」から意識がずれやすい。今回、現実に沿わないモデルを作ってしまい「ﾔｯﾁﾏｯﾀ」って思った。
