2016.12.11 Sunday
テストカタマリーの紹介1:カタマリーの概要
こちらは「ソフトウェアテスト Advent Calendar 2016」の記事として書いてます。
※…といっても、テストカタマリー紹介記事の連載第1回目だったりしてますが。 今回は、久々の技術投稿かもしれません^^ 「テストカタマリー」と呼ぶ謎の記法を用いたソフトウェアのテスト設計における整理・表記方法を考えてみましたので、その内容についてまとめてみます。 全5〜6回程度を予定しており、今回は概要として「テストカタマリー」をざっくりと紹介してみます。
※注意事項
・本記事ではテストカタマリー「記法」に対する説明を優先しております ・テスト設計の手順を紹介するものではありません 関連記事のまとめはこちら ■テスト設計の簡単なイメージ まず、テストカタマリーを使用する対象となるテスト設計について。 ソフトウェアのテスト設計を進める場合の個人的なイメージですが、以下のようなものと考えております。 最初に何となくの範囲(スコープ)があるとして… 1.対象のテストスコープ全体を特定する 2.全体を分割しつつ、確実にやる・優先度を下げる部分の分類を決める ※なお、この分類は組織やドメインにより変わります 3.分割範囲を詳細化(テスト詳細設計)してテストケースへ 「塗り絵」のようにソフトウェアテストを例えている方もおりましたが、上記のイメージも同じような捉え方をしております。 ■テストにおける気がかり事項 ここでテストをレビューしたり流用したい場合を考えてみると… 要求1:テストケース1つ1つの抜けを確認したいです。 ただ、テストケースは細かく、ねらいも沢山あります。 例(iPhoneの「時計」アプリのテストケース例): ・アラーム登録の確認 - 曜日繰り返し設定の登録 - サウンド選択の登録 … ・アラーム編集の確認 … ・アラームデータ登録最大数の確認 … 要求2:全体的に大きく抜けが無いかどうかも確認したいです。 ここで、上記の例のような細かいテストケースが並んでいる状況ですと、大きい抜けが確認しづらいです。例えば、「互換性」といった大きな検討抜けが発生していると、後ほどの問題につながる可能性も大きいですよね。 つまり、上記の要求1の細かい部分も確認しつつ、要求2の全体的な抜けも確認したくなります。ジレンマな感じがします。 ■テストカタマリーの概要 さて、最初に紹介した図の「分割範囲」を考えてみますと、一連のテストケースの「塊」となっているとも言えます。 ここで、テストケースの「塊」サイズの表現を上手に用いることで、全体的に「塊」で抜けがないコトを確認しつつ、それぞれの詳細を検討することは出来ないでしょうか。 このテストケースの塊を安直に「テストカタマリー」と呼びつつ、記法を考えて見ます。 この「テストカタマリー」の名前を適切に設定(画面名や機能で分けるなど)し、上手く整理することで、とあるプロダクトのテスト設計結果を類似プロダクトのテストへ流用したりすることも可能ではないかと考えております。 ■テストカタマリーの例 今回は概要ということで、iPhoneの「時計」アプリのテスト検討を例としてテストカタマリーを使用した例を1つ紹介します。 「全体を示す図」と「詳細を示す図」の2種類(以上)の階層構造が可能です。 ※具体的な例の説明は次回の記事で紹介します。 全体カタマリー図 ※なお、一部の細かい検討は省略しております。 ※クリックで拡大 詳細カタマリー図 ※クリックで拡大 こちらの図だけで分かるような人は、直感的に判断して頂いて良いです。また、この記法を使いこなすことが出来そうです^^ パターン的な継承、階層構造の表現もやりやすい内容となっております。 ■テストカタマリーの役立ちどころ こんな感じで役立つかも?という内容を箇条書きしておきます。 ・テスト全体像を把握しやすい表現に出来そうです。 ・全体の方針を決めるエキスパートと詳細を作る担当者が分担出来そうです。 ・テストカタマリー単位で作業分担を決めることが出来るかもしれません。 ・テストをリバースして整理する際にも役立ちそうです。 ・流用しやすいような構造の整理をすることも出来そうです。 業務における派生開発のテストのために派生元のシステムのテストを整理するようなシーン、組織のテストの傾向を調べるようなシーンにも使うことが出来ると思われます。 また、「テスト設計コンテスト」と呼ばれるテスト設計を競いあう酔狂な大会^^において成果物を整理するための記法としても使うことが出来るかもしれません。 以上の概要紹介したテストカタマリーの記法について、これから数回かに分けて紹介しておきます。 |