見出し画像

(2021年版) ソフトウェアテストの上流設計-6 テスト目的の分析とテストカテゴリ

第4回のnoteから、ゆもつよメソッドとして特徴的なテスト分析の説明にはいってます。2021年5月28日に開催予定のJaSST東北2021で行うワークショップとリンクした内容になっていきます。いわばコラボ企画ですね!

今回は、テスト分析のもう一つの軸である、テスト目的の分析になります。テスト分析の流れの図では「テストタイプ特定」という矢羽で描かれてる部分からテストカテゴリ作成のところになります。

テストカテゴリはゆもつよメソッドの1番のポイントになるところです。論文でこの手法について書くときには、ゆもつよメソッドと書いても誰もわからないので、テストカテゴリベースのテスト分析(Test-Categories Based Test Analysis)と説明しています。


テスト目的の分析

テスト目的の分析は、テスト対象アイテムのテストベースからテスト条件とすべき仕様項目をピックアップするときの観点を明らかにするために行います。まず最初に、テストの目的からみて相応しいテストタイプを選択します。そしてテストタイプを具体化したテストカテゴリを決めて行きます。

テストタイプについておさらい

まず、テストタイプとは何か?と、似たような言葉との違いについては、過去に書いた「フェーズ、レベル、タイプ、技法」を読んでもらえるのが良いです。

テストタイプ = テスト実行時にどこに着目しているか?
まず、誤解をしているといけないので最初に書いときますが、テストタイプが違っても、テストの実行ですることは基本的には変わりません。テスト実行はあくまでテスト対象に入力を与えて、出力結果で期待通りかを判断する行為だからです。実行することは変わらずとも確認したいことが違うのです。下の図の例では、ブラックボックステスト(機能テスト)とホワイトボックステスト(構造テスト)についての説明ですが、両方ともテスト対象に対して10を入力値として与えています。出力値は20です。

画像3

機能テストは機能仕様に着目しており、仕様から導かれる期待結果と出力が合致しているかを確認しています。構造テストは出力値が20であることよりも、IF文の分岐のTrue側を通過していることに着目しています。

テストタイプは3種類あり、その3つからまずは選ぶ
システム/ソフトウェアの造りに着目してテストする場合は構造テストを選択します。例えば、複数のサービスがちゃんと繋がるか?といった疎通テストをするときが構造テストです。また、ロードバランサーが適切に処理を振り分けているかをテストするのも構造テストだと言えるでしょう。もっと、システムの内部に入っていき、マイクロサービス間でデータのやりとりができるか確認するときや、コンポーネントのレベルで内部で通過すべきパスを全部通過しているか確認するテストも構造テストです。

スクリーンショット 2021-05-08 16.08.25

出力結果や、それに伴う振る舞いの変化に着目する場合は機能テストを選択します。システムテストのテストレベルで言えば、銀行ATMでカードを入れて暗証番号を入力するとATM端末から銀行のホストに問い合わせがあり結果的に引き出したいお金を引き出すところまでできるようになります。この一連のやりとりの中でお金の引き出しができるかは機能テストです。ログイン画面で認証を行いホーム画面にいくことができるテストも機能テストですし、四則演算するプログラムが2つの数字の入力と足し算引き算の符号の情報で計算結果を出すことを確認するのも機能テストです。

機能がどう振舞うかに着目する場合は非機能テストを選択します。たとえば上記の機能テストの例でATMのお金の引き出しの機能テストの例をあげましたが、このお金の引き出しにかかる時間がいつでも期待通りの時間内で終わるかを確認するのは非機能テストです。

テストタイプを選ぶメリット

テストタイプを選択することにより、各テストの目的を満たすための視点が明らかになります。視点が明らかになるメリットは、テスト設計のときにテストケースの数が発散しないということです。

テストケースの構成要素
テストケースの構成要素について書いておかないとテストケースの数が発散しないメリットの説明ができないので、ちょっと話をそらします。テストケースの構成要素について説明します。

テストケースは、「テストパラメーター」「テストアクション」「期待結果」で構成されています。例えば、3つの数字から三角形のパターンを判断してくれるプログラムがあったとして、判断結果を確認するテストケースで例えると以下のようになります。(知ってる人は知っている、マイヤーズの三角形問題ですね!)


・テストパラメーター:右斜辺、左斜辺、底辺(に入れる数字)
・テストアクション:プログラムのコマンドを実行する
・期待結果:正三角形or二等辺三角形orそれ以外の三角形

テスト実行は、テストパラメーターで決めた数値を入れた場合にコマンド実行をすることで実現します。コマンド実行はテストアクションです。そこで出力された実際の結果と期待結果を比較してOKかNGかを判断します。以下の図のようなイメージですね。

画像6

テスト設計をするときに、テスト分析の結果から「テストパラメーター」「テストアクション」「期待結果」を明確にしますが、作成したテストケースの数はテストパラメーター次第で大きく変わります。テストパラメーターに3,3,3と入れるだけで確認が十分であれば1つのテストケースだけになります。ただ、それだけでは二等辺三角形やそれ以外の三角形のテストはできていません。では、それぞれの辺の入力として1〜9まで入力可能だったとして、全パターンやるといくつになるでしょうか?9の3乗で729のテストケースになります。これは入力可能な数字の場合なので、入力できないものを入れたときのことを考慮するともっと増えます。

テストパラメーターを選ぶ拠り所
1つのテストケースにするか、729(もしくはそれ以上)のテストケースにするかをどう判断するでしょうか。その判断のときにテストタイプが役立ちます。構造テストで言えば、テスト対象の内部的なプログラムが動いてることがわかれば終わりです。ですので1パターンのテストでよいでしょう。(プログラムロジックのパスを通すのであればもっと増えますが...)機能テストであれば、3つのパターンの三角形を判断できるかは必要です。また、エラーハンドリングについてもテストをするのであれば、三角形が成立しないときや、入力を許していないものを入れたときのバリデーションの確認も必要でしょう。応答時間の遅延がないかをみたいのであれば、CPUやメモリ領域が想定通りではないときにプログラムを実行するとか、プログラムの実行を何時間も繰り返し実行し続けて、データが不正に溜まってしまい処理が継続できなくなることがないか、といった非機能テストも必要になります。

(大事なことなので何度も書きますが)テストタイプが違うテストケースは実行するテストアクションは一緒ですが、期待結果が異なります。

そして、テストケースを作る前に、仕様項目と期待結果をテストしたいこととして特定しておくと、その後にテストパラメーターを決める際、なんでもかんでも思いついたことを無駄に多くテストするという状態にならず、テストすべきテストパラメーターと、しなくてもよいテストパラメーターが判断できます。つまり、テストタイプを決めて、テストタイプに相応しい仕様項目と期待結果を明らかにすることで、テストパラメーターを適切な数に収めることができるのです。

典型的なテストタイプ

テストタイプは典型的にはISTQBなどの標準にて決まっている定義を利用するのがメンバー間の意識合わせのためにもよいでしょう。典型的なテストタイプとして下図に列挙したものがあります。

スクリーンショット 2021-05-23 8.57.05

この図のベースはISTQBのテストアナリストシラバスとテクニカルテストアナリストシラバスです。2019年度版のシラバスをベースにして書き出してみました。

ここで理解しておいてもらいたい大事なことが二つあります。

品質特性の全てをテストでは確認できない
品質特性と呼ばれているものでも、テストで確認できる品質特性は限られているということです。テスト対象に入力を与えて、出力結果とその他の方法で行うモニタリングの結果で確認できることがテストです。そのやり方で確認できる特性は、機能適合性、性能効率性、信頼性、互換性、使用性くらいだということです。例えば、テスタビリティが高いかという品質特性をテストするには、できたプロダクトがテストしやすかったかをテストするってなるので、絶対できないことはないですが、そのためにテストのコストをかけるのは得策ではないです。また、保守性が高いことは、ソフトウェアの修正が必要になった時に修正箇所がどれだけ局所的かとか、短時間でできるかと言った観点で確認することになりますが、テストで直接的に保守性を確認するのはできないと思います。

品質特性は目的を分類してるだけで実行方法は一緒かもしれない
テストの実行と品質特性は綺麗に1対1になっているわけではないということです。例えば、負荷テスト、ストレステスト、堅牢性テストなどは、テストタイプは異なりますが、実行方法は大量のアクセスを同時に与える場合があります。セキュリティテストでもペネトレーションテストであれば、実行方法は大量のアクセスを同時に与えるテストを行います。つまり、同じやり方でテストができるし、一回のテストで複数のテストタイプに属するテストケースを確認できる場合も多々あります。機能テストをやることでアクセシビリティテストをしたことにできるテストもありますし、構成テストやセキュリティテストを機能テストと一緒に実行することもできます。理由は実行方法や期待結果の確認方法が何も変わらないからです。違うことは確認したい目的です。

テストタイプ一覧は、自分で使うものを用意しておくと忘れないので安心です。組織やチームでオリジナルの一覧を作ることもありだと思います。その場合は、常に同じ定義で話ができるように定義をまとめるようにしておくと良いです。あとは「〜テスト」という言葉はいろいろなものがあるので、目的を表すものをテストタイプとしておくことです。例えば境界値テストはテストタイプではありません。

テストタイプをさらに具体的にする

テストタイプは、組込みソフトウェア開発、エンタープライズ系開発といったドメインに関わらず、どのプロダクトのドメインでも通用する汎用的な観点であるため、それだけでは具体性に欠けます。

仕様項目(つまり、テストすべきこと)をテストベースから見つけていくためには、「自分がテストしようとしているテスト対象アイテムは、どのような仕様項目がテストすべき事柄として該当するか?」をイメージできる程度にテストタイプを具体的にしたほうがよいです。理由は、実際にテストすべき仕様項目をピックアップするときに、例えば「機能テスト」といった分類では大きすぎて重複や漏れがわからなくなるからです。

ゆもつよメソッドでは、テストタイプを具体化するときに論理的機能構造を使います。ここからは論理的機能構造図をベースにテストタイプを具体化していくことについて説明して行きます。

機能テストを具体化する場合
機能テストでは、「何を」をテストします。「何を」は機能そのものですが、抽象的すぎるので要素を整理して考えます。

機能(フィーチャー)は複数の細かい機能(タスク)の集合で実現しているので、仕様項目のピックアップをする際に、細かい機能(タスク)に着目するようにします。(ゆもつよメソッドでは、フィーチャーへの入力と出力の間でシステム内部で行われてる作業のことをタスクと呼んでます)

ある目的を実現する単位で機能(フィーチャー)を捉えると、フィーチャーの内部で行われていることは前回説明した論理的機能構造で表現できます。 

汎用的な論理的機能構造を手がかりに、機能一覧に列挙されている機能から、仕様項目をピックアップするための具体的な視点を明確にしていきます。例えば、テスト対象が音楽プレーヤーだとして、その製品に「録音機能」というものがあったとします。録音機能に関する部分で、テスト条件をピックアップするときに録音機能のどのような仕様項目(テストすべきこと)をピックアップして行けばよいでしょうか?下図の論理的機能構造を手がかりに考えてみましょう。

画像4

「入力調整」:録音設定入力や、録音ボタン押下(イベントを受け付けること)を確認
「変換」:録音そのものができていることを録音後の再生で確認
「サポート」:録音中は再生できないことを確認
「貯蔵」:録音データがファイルとして格納されていることを確認

「出力調整」:録音中のLCD点灯や録音時間の表示を確認

と言ったように機能を構成する各要素(タスク)に着目することでどんな仕様項目がピックアップしようかがわかってきます。「機能テスト」のようなテストタイプよりもっと具体的な観点で仕様項目をピックアップすることで、複数のテスト設計者によるピックアップの結果に抜け漏れがないかをわかりやすくすることができます。

機能テスト以外を具体化する場合

非機能要件のテストタイプなどで使う、その他のテストカテゴリに関しては、機能テストのテストカテゴリとは定義の仕方が異なります。非機能要件のテストカテゴリの説明は、ゆもつよメソッドの適用事例は基本的に機能テストであるためにまだ私が明快に言語化して説明できないことと、JaSST東北のワークでは機能テストに焦点を当てるためにワークの前提知識として必要ないことから、ここでは省略します。おまけコーナーでがんばって説明するようにします。

テストカテゴリとは?

論理的機能構造の要素である、「入力調整」「変換」「サポート」などの言い方ではソフトウェアの機能を表すには表現が違いすぎます。また、言葉が汎用的すぎて自分たちがテストするシステムやソフトウェアのどこの要素が自分たちがテストしたいこととして当てはまるのかで意見が割れる可能性もでてきます。

スクリーンショット 2021-05-18 8.12.38

各要素に対するテスト対象から見た適切な名前付けしたものを、ゆもつよメソッドではテストカテゴリと呼びます。テストカテゴリは、自分たちがテストする対象でイメージできる名前にします。

前述した音楽プレーヤーの機能テストに対するテストカテゴリを作り、論理的機能構造にマッピングした例が下図になります。

スクリーンショット 2021-05-16 22.35.56

複数のテスト設計者が、論理的機能構造の各要素に対してイメージがブレず、一貫性のある解釈をできるようにすることでテストカテゴリを命名する目的が達成できます。イメージがブレないようにするため、そのテストカテゴリで見つける可能性のある故障/欠陥を、テスト設計を担当する人たちでディスカッションすることでテストカテゴリの解釈に対する合意形成を行い、テストカテゴリの付随情報として追記していきます。

テストカテゴリ一覧
テスト目的の分析結果として、テストカテゴリ一覧を作成します。テストカテゴリ一覧を作成する際には、テストタイプとテストカテゴリの二階層でも構いません。そして、テストカテゴリから想定できる欠陥や故障を追記することでテストカテゴリに意味付けを行います。

スクリーンショット 2021-05-22 9.22.21

ものすごく厳密に定義をしたい場合は、品質特性(テストにて確認したい品質)、テストタイプ、論理的機能構造、テストカテゴリの四階層で階層化しますが、実務で使うときにはそこまでしなくても良いと思います。

特に意識して欲しいのはテストカテゴリの数です。テストカテゴリは、全ての機能一覧の最下層項目に対して突き合わせを行い仕様項目の有り無しを検討していくため、数が多すぎるとその数の多さでまた混乱してしまうからです。実際の数がいくつまでという定義はありませんが、後述するテスト分析マトリクスの列として表現したときに1ページに収まる程度にカテゴリ数を押さえるようにして、ぱっと全体像が見渡せるにするとよいでしょう。

今回はテストタイプとテストカテゴリについての考え方の解説でしたが、次回はこの考え方に基づいてテストカテゴリを作成する実践方法を説明します。

おまけ 非機能テストのテストカテゴリに関して

今回のおまけは非機能テストについて書きます。前述したように体系的な言語化がまだできてないので、2010年頃にコンサルしていたときはクライアントとの対話の中でやり方を具体化させていました。できる限りうまく説明できるよう頑張ってみます。

続きをみるには

残り 2,575字 / 3画像
この記事のみ ¥ 300
期間限定 PayPay支払いすると抽選でお得に!

サポートありがとうございます。これをカテにこれからも頑張ります。