大中小項目のナンバリングについて
1-1-1
1-1-2
2-1-1
とかいうあれです。
※ テストアイテムIDとかの話じゃないです。
もうNo.1,2,3…だけでいいじゃん!とかあると思うんですけど、
実際にNo.1,2,3…しかないテスト仕様書もあると思うんですけど、
あると便利です。というかちゃんと意味があります。
それは「変更管理に強くなるから」です。
例えばテストケースをNo.1,2,3…だけで管理しようとすると、
項目を途中に追加するとそれより下の項目のNo.がすべてズレてしまいます。
そうすると変更履歴でこのNo.を変更しましたと書いてもズレちゃってるわけですから
あれれ?となるわけです。
一方、大中小項目でナンバリングすると
1-1-1
1-1-2
とあるところにテスト目的(中項目)を追加する場合は
1-2-1
テスト条件(小項目)を追加する場合は
1-1-3とすればいいわけです。
※ 1-1-1と1-1-2の間に無理に追加しようとしなければOK
■ まとめ
大中小項目でナンバリングすると変更管理が楽
大中小項目に何を書けばいいのかについてはこちらをどうぞ
vhu.hatenablog.com
テストの優先度のつけ方をフローチャートにしてみた
■ はじめに
テストの「優先度」や「重要度」などで検索した内容を僕なりに咀嚼したものです。
なので、だいぶ簡略化しています。
テスト設計の優先度をつけるために使用することを想定しています。
なので、骨子(大項目、中項目)はできているものとします。
すでに作成されているテストケースに優先度をつけることにも使用できますが、小項目については考慮されていません。
■ 解説
・大項目について
ここではその機能がメイン or サブなのかを判断します。
その製品 / サービスが何を売りにしているのかが理解できていれば、迷うことはほぼないと思います。
オプション的なものは「優先度底」に分類します。
・中項目について
ここでは仮にその製品 / サービスが全く動作しない場合を考えます。
顧客の業務が完全に停止してしまう / セキュリティ事故になるようなものは「優先度高」に分類します。
業務は継続するもの(代替案があるもの)は「優先度中」に分類します。
ex) ○○を作成する機能
作成できなかった場合、その業務が完全に停止してしまう。
⇒ 「優先度高」
○○を更新する機能
更新できなかった場合、最悪、作成し直せばいい。
⇒ 「優先度中」
○○を削除する機能
削除できなくても、業務を止めるわけではない。
⇒ 「優先度中」
■ まとめ
テストは抜け漏れなくといいますが、全数テストは現実的ではありません。
何を重点的にテストするのかを考えることで、そこにテスト戦略が生まれます。
テスト戦略が生まれると、テスト設計が単なる作業ではなくなります。
そうなると少し面白くなるような気がします。
効率の良いテスト設計とは
■ はじめに
前回の記事から1ヶ月経ってしまったので、頑張って書こうと思います。。
今回は「効率の良いテスト設計」についてです。
そんなものあったら円満してるわ!という声もあるとは思いますが、
僕なりの経験からまとめてみました。
■ 効率の良いテスト設計は、試験勉強に似ている。
試験で良い点をとるためには、ただガムシャラに勉強しても、思うような結果はでません。
特に試験まであまり時間がない場合は、何をやる/やらないかを見極める必要があります。
手順にすると、
1. 試験範囲を確認する
2. 試験に出そうなところに山を張る
3. 勉強計画をたてる
4. 勉強する
みたいな感じでしょうか。
「効率よく」勉強できない人は、ろくに計画も立てず、試験範囲の最初のページからやりますよね?
↑をテスト設計に置き換えると、
1. テスト範囲を確認する
2. 優先度を付ける
3. テスト設計計画をたてる
4. テスト設計する
となります。
「効率よく」テスト設計できない人は、ろくに計画も立てず、仕様書の最初のページからやりますよね?
■ まとめ
いかがだったでしょうか。
仕様書を渡されてすぐに着手という人は意外と多いと思います。
終わりが見えないの辛くないですか?
時間なくて後半のテスト薄くなってませんか?
残業してでも納期までに終わらせたって本当に成功体験ですか?
本エントリーがテスト設計する上で何かのヒントになってくれれば幸いです。
テストケースの大中小項目に何を書けばいいのか
何となく大きなものから小さなものへという感じで埋めていたのですが、3レイヤーに収まらなかったり、見づらかったり、フィルタリングしづらいといったことがありました。
例えばこんな感じです。
■ Before
大項目 | 中項目 | 小項目 |
アカウント一覧画面 | ID | 閲覧 |
メールアドレス | 閲覧 | |
アカウント名 | 閲覧 | |
検索 | 前方一致 | |
中間一致 | ||
後方一致 | ||
完全一致 | ||
CSV出力 | ||
CSVファイル | ID | 閲覧 |
メールアドレス | 閲覧 | |
アカウント名 | 閲覧 |
上の例では、何をテストするのかはわかりますが、中項目でフィルタリングしようとすると、レベル感がバラバラです。ここから整理して何となく揃えることもできますが、時間がなかったらそのままになります。。
そこで、何となく埋めているところを、きちんと定義してみました。
■ 定義
大項目 | 中項目 | 小項目 |
テスト対象 | テスト目的 | テスト条件 |
大項目について
ここにはテスト対象を記載します。テストケースの主語になります。品詞でいうと名詞が入ります。注意点というかコツは、ボタンなどの小さなものは書かないことです。大項目にミクロなものを書いてしまうと、中項目と小項目にはさらにミクロなものを書くことになります。そして大項目を洗い出すだけでもかなりの時間を費やすことになります。画面だったり、機能を記載するのがいいと思います。
中項目について
ここにはテスト目的を記載します。少しわかりづらい表現ですが、テストケースの述語になります。品詞でいうと他動詞が入ります。ただし、見やすくするために「~する」の「する」は省略します。例えば、「閲覧する」だったら「閲覧」に、「追加する」だったら「追加」みたいな感じですね。
小項目について
ここにはテスト条件を記載します。テストケースの修飾語になります。修飾語なので、テストの粒度によっては省略可です。パラメータだったり、状態遷移のテストだったら前状態が入ったりします。
※ 大中小項目を見直してみて、それが手順になっていたらアウトです。粒度が細かすぎます。
この定義を基に作成するとこんな感じになります。
■ After
大項目 | 中項目 | 小項目 |
アカウント一覧画面 | 閲覧 | ID |
メールアドレス | ||
アカウント名 | ||
検索 | 前方一致 | |
中間一致 | ||
後方一致 | ||
完全一致 | ||
CSV出力 | ||
CSVファイル | 閲覧 | ID |
メールアドレス | ||
アカウント名 |
中項目でもフィルタリングしやすくなりました。
どのレイヤーに何が書いてあるのかわかると可読性があがりますね。
■ まとめ
いかがだったでしょうか。
例が適当じゃなかったかもしれませんし、何となくやってもこうなるよ!という人もいるかもしれませんが、テストケースの量が多くなればなるほど、レイヤー間のズレは大きくなっていきます。そうならないためにも、テストケースの大中小項目に何を書けばいいのかを一度定義してみると良いかもしれません。