見出し画像
Photo by kyrie_jpn

「テスト観点が...」って言われたときはどうするか？

Tsuyoshi Yumoto

先日、JaSST東北2021に参加してきました。ゆもつよメソッドを題材に選抜された8名のエンジニアがテスト分析を実践しながら、イベント参加者は、実践している様子を観戦しながらDiscordで質疑していくという、とてもインタラクティブな場でした。わたしは解説者として参加しましたが、とても有意義な体験をすることができて、オンラインのイベントがオフラインを超える可能性さえ感じました。本当に実行委員の人たちの準備の結晶とも言える素晴らしい会でした。

会の中でこんな質問がありました。

初歩的な質問かもですが、ゆもつよメソッドでテスト観点という言葉が使われないのは「観点」自体の認識が人によって違うからでしょうか？

あー、これちゃんと説明しなきゃって思いました。で、会の中では、ホワイトボードに書いて説明をしました。

テスト観点の何について書けばイイの？

以下のnoteで、テストで要注意ワードTop3の第2位に入れといて、「観点については別途書くよー」と宣言してました。

このnoteを読んでいるみなさんもぜひ「テスト観点」でググってみてください。結構な数の記事がヒットして、記事の中でテスト観点について書いています。そして、ほぼみんなが「テスト観点」は曖昧な言葉だから、ということを書いています。

これらの記事があれば、私がわざわざnoteに書く意義は何か？とか考えてしまい、いくつか文章を書いては「あー、イケテナイ」と思い、ボツにしてました。

要は、私が書くのであれば何を書けばよいのか？がかわからなくなっていました。

しかし、JaSST東北でこの質問を受けてホワイトボードで書いて解説したら「わかった！」と答えてくれた人が多かったので、これを書けばシンプルでいいじゃん！って思いたちました。なので忘れないうちに書いときます。

ゆもつよメソッドで「テスト観点」を使わない理由

観点は汎用的な言葉です。「観察・考察する立場。見地。見かた。
」などのことを表す汎用的で抽象化された言葉です。何にでも当てはまります。例えばアーキテクチャ設計に関する標準であるISO/IEC/IEEE 42010では、記述する際に厳密に定義を与えていて、いろいろな言葉の意味や関係性を定めていますが、ある意味アーキテクチャー設計の観点を整理したものといえます。

テスト観点もそういうの必要かも？

なので、ゆもつよメソッドを使わせてもらっちゃいます。ゆもつよメソッドではテストケースを作るまでの静的構造を定義しています。現れる要素の全てがある意味「テスト観点」です。

テストケースの静的構造

画像1

（フィーチャーセットは、ゆもつよメソッドでは通常「機能項目」と呼んでるものです。）

この静的構造の中に出てくる要素の意味は、ゆもつよメソッドの解説を読んでもらうとわかります。

私の記事は有料で長いので、代わりにJaSST東北2021のレポートページであれば無料で解説が読めます。

全部がテスト観点と言ってもいいものなのですが、全部同じ言葉で話をしていると、どの話をしているかがわからなくなります。それがテスト観点という言葉を使わない理由です。

テスト観点とは具体的に何のことを言ってるか確認しよう

実際に私が使わないと言っても、使う人もたくさんいるので、私は、実際に現場で「テスト観点が〜」って話す人がいるときは、聞き返して、具体的に何を言いたいのか教えてもらい、上記の静的構造でいうと、どの話をしているのかを理解するようにしています。そうすれば、自分はその話をどう受け止めれば良いかも判断できるし、次のアクションも考えやすいからです。具体的に言えない場合は、その人もまだフワッとしてるんだなと判断します。

そこで！　そのテスト観点って具体的に言うとどういうことですか？って質問した時の回答例ごとに整理してみます。

お題として、商品を購入するWebサイトで商品一覧検索画面のテストを考えてる状態を使いましょう。

商品一覧に条件通りの検索結果が出るか確認しなきゃ！

この場合は、どんな目的のテストをしたいか？ってことを話していますよね。こんな回答が返ってきた時は、テストカテゴリに属するテスト観点だなーって判断します。

スクリーンショット 2021-05-30 17.16.24

私がよく「テストの目的を細かくしてくと仕様項目を特定できる」とか言ってるのはこの観点です。

ゆもつよメソッドではテスト目的の分析としてテストカテゴリを作成します。

商品マスタにデータ登録直後に検索したらどうなるか？

この場合は、どんな条件のパターンテストをしたいか？ってことを話していますよね。こんな回答が返ってきた時は、テストパラメータ（この場合は事前条件）に属するテスト観点だなーって判断します。

スクリーンショット 2021-05-30 17.33.30

私がよく「P-Vのバリエーションの広がり」とか言ってるのはこの観点です。

ゆもつよメソッドではテスト設計の時にパラメータを特定します。

売り切れの商品が一覧に出ちゃったことがあるんだよねー、あれもテストしなきゃ！

この場合は、どんなバグがでるかな？って想定して話してますよね。テスト対象のことを知らない人でもこの観点はどんどん言ってきてくれます。ただし、これは最終的には上記の二つのどちらかにたどり着きます。

スクリーンショット 2021-05-30 19.14.15

ゆもつよメソッドだと、テストカテゴリを具体的に理解する時に使います。テスト対象のことを知らないときの観点出しはここに当てはまります。

ただし、故障や欠陥を想定するのは、よく知らないときの想定だけでなく、分析してる時や設計しているとき、テスト実行始めてからとか、あらゆる場面で思いつくものです。なので、上記のように三箇所に丸をつけてみました。

例えば、「境目のあたりをテストしなきゃねー」とか、「繰り返して見ると何かあるかも」とかは、そのあたりがいつどんな時でもバグが出そうって思ってるから言うわけですが、これは、「境目のあたり」が入力の境界値なので、テストパラメーターですし、「繰り返し」は事前にも同じことをしているという事前条件なのでテストパラメーターです。「売り切れの商品が一覧に出ちゃった」はもうちょっとテスト対象のことを知ってる人の発言なので、テスト分析してる時に言いそうですが、事前条件として商品を売り切れにするので、テストパラメーターです。「エラーハンドリングでコケる可能性かるから見ておいた方が良い」とか言いだす場合は、論理的機能構造のサポートに属するテストカテゴリに分類できる仕様項目をちゃんとテストしようと言ってます。

それぞれのテスト観点を活用するタイミングが異なる

テスト観点と呼ぶものは大きくわけると、「目的になるようなこと」、「P-Vになるようなバリエーションの広がり」、「想定できる欠陥」の3つのことを言ってることが多いというのが私の経験則です。（たまに違う時もあるからなおさら注意して聞いた方が良いですが）

さらに言うとその多くは、P-Vのバリエーションの広がりのことを言うことが多い気がします。（統計を取ったわけではないのですが、感覚的にそう思うって話です。異論ある方もいるかもしれません。）

P-Vのバリエーションの広がりは、テスト設計で本格的に考えることなので、テスト分析している最中から、P-Vのバリエーションの広がりにばっかり着目するとテスト分析が進みません。

逆にテスト設計しているときに、テストカテゴリとして出したいようなことが抜けてたら、テストが丸ごとズボッと抜けます。抜けてたことが気付けば大丈夫ですが、他のテストケースの中に入れ込んでくと、テストケースの構造が崩れて、どこで何のテストをしてるかが無法地帯になります。

無法地帯のようなテストケースのセットのままにしておくと、どこまでテストが終わって、後どのテストをやればよいかがテストケースを見渡してもわかりづらくなります。これが無駄にテスト工数が増えたりする原因になります。

テスト観点リストが欲しいと言われたら

この記事をアップしたら、偶然にもにしさんとブロッコリーさんがテスト観点についてツイートしてて、なるほどと思ったので備忘兼ねて貼っときます。まとめにもここから得られた言葉を追加しました。ありがとう！

あー、これあるなって思ったらブロッコリーさんが引用リツイートしてて、

私は目的のテスト観点なら、実は1:1になるようなものの方が多いって思ってます。ただ、テスト設計した方が良いものもありますのでそこはちゃんと設計しようって心がけてますし、メンバーにも言ってます。確かにP-Vの広がりのテスト観点を1:1にしてると「うーん、訳わからん」ってなります。

確かに、この勘違いをしてる人がものすごく多いです。

これも確かにです。これはにしさんが言うから響く言葉だなーって思う。

私だったら、「テスト観点リストがあればテストできるのではないので、自分でテスト対象を理解しましょう。」って言おうかな。

そもそもテスト観点とは？をにしさんは↓のように書いてました。抽象化したものだって一言が私の文章には足りなかったなって思いました。（なので本文も若干修正しました）

で、これですね。

確かにVSTePってそうだった。「オブジェクト指向設計」っていうのと同じレベルの用語で「テスト観点によるテスト設計」なんですね。

なるほど！気付きだな！テスト観点リストってナンセンスだっていうのはこう例えればいいんだって思ったので私もツイートしときました。


まとめ

・テスト観点と呼ばれるものは、汎用的で抽象化された言葉なので、テストケースを作るまでの静的構造のどの要素でも当てはまってしまう。（つまり、どれのことがテスト観点だと言われても、それが間違いとは言えない）

・テスト観点の話が出たら、聞き返してみよう。そして、具体的なことで説明してもらおう。

・具体的に聞いてみるとだいたい３つの要素のどれかのことを言ってることが多い。（たまに違うこともあるので要注意）

・更にいうと、それは2つに集約できることがほとんど。

・テスト観点と言っても、分析でやることと設計でやることがあるのでちゃんと分けましょう。

・テスト観点ってオブジェクト指向設計をするときのオブジェクトと同じようなレベルの言葉で、実際にはクラス、多重度、関連などの要素を整理しないといけないし、インスタンス化してるのかどうかとか整理して話さないと何話してるかわからなくなりますよ。

・誰かからもらったクラスリストがあればソフトウェア設計ができると言う話を聞いたことがないのと同様で、誰かからもらったテスト観点リストがあればがあればテストできるのではないです。自分でテスト対象を理解しましょう。

以上

（今回はnoteのみんなの画像っていうのをカバーに使いました。テスト観点といってもいろいろあるのがいろいろな具があるパエリアに似てるかなと思ったので。無理矢理感があるけど（笑）ありがとうございました。）


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