ソフトウェアテストをする際に、どうテストをしていくか話をしているときに「この言葉が出てきたら要注意」っていうワードがいくつかあります。要注意っていうか、話している人も当然のように言ってくるけど、実は人それぞれの解釈をふわっといい感じにまとめる言葉なので誤解のもとになるし、後で「あれ、そういうことなの？」って感じで、想定していることが全く違ったって話になりかねないことがとっても多いです。本当に気をつけてたほうがいいです。私が独断で選ぶ要注意ワードTOP3は、以下になります。

テストの要注意ワードTOP3

3位　正常系(付随する言葉として異常系、および準正常系)
2位　観点、およびテスト観点
1位　網羅　(網羅的とか、全網羅とかも含めて)

例えば、こんなテストの指示されたらやばいと思った方がいいです。

正常系と準正常系の観点に関してはちゃんと網羅的にテストをしてね。

ハァ（ため息）...なんかね、これら3つの言葉を使うと、なんとなくテストが詳しそうだし、「みんなが当然知ってるよね？」って感じで会話の中で出てくるから...やっかいです。

第3位の「正常系」に関してはsuhahideさんの以下のnoteで書かれてるのでぜひ読んでください。

第2位の「観点」については、またどっかでnote書きます。

（11/26追記）観点について書いたのでリンク貼っときます。

第1位の「網羅」なんですけど、そもそも本当に全部網羅するなんてできるわけがなく、だからこそテスト設計するんだよ！っていうことが簡潔にわかりやすく書かれたnoteを見つけたので以下にリンクしときます。

このnoteにもリンクされている「フカシギの数え方」って動画も名作なので大好きです。

「全数テストは不可能」って原則をわかりやすく教えてくれます。要はできないことをできるといってはいけないわけです。なのに網羅という言葉には恐ろしい魔力みたいなものがあり、まるで全数テストしてないといけないことをしたかのような錯覚に陥ります。テスターの仕事を責める時も一言でトドメを刺すような破壊力があります。

また、「２機能間網羅してます！」とか言われちゃうと、なんかすごい網羅してるなぁと思ってしまい、それだけですごいかのように錯覚してしまうこともあります。

これは全て、引用したnoteのタイトルである、「これ以上バグを見つけれらないことの証明しかテストはできない」ってことそのもので、「欠陥がないことを証明できない」ってテストの大原則をわかっていると納得できる話なのかと思います。

まぁ、2位の観点と1位の網羅は、私自身、曖昧に使ってしまうことがあるし、気をつけなきゃなって思います。

なので、以降は、第1位の「網羅」についてもうちょっと考えてみます。

対象をモデル化して、決めた基準で網羅する

ソフトウェアテストでは、網羅っていうのは「対象をモデル化して、決めた基準で網羅する」ってことです。これに関しては、最近Twitterの中でブロッコリーさんと辰巳さんがやりとりしてて、その中で以下のスライドを紹介してたので読んだんですが、そのものズバリが書いてあったのでこれも以下にリンクしときます。

スライドに書いてある内容によると、ソフトウェアテストの世界では、どんな基準で網羅すべきかっていうのは長い間研究されてるけど、それらの研究の成果は以下の4つのどれかのモデルに対する網羅基準であるってことのようです。

1. Graphs 
2. Logical Expressions
3. Input Domain Characterization
4. Syntactic Structures

理論的な説明は、私がなんか言うよりもスライドを参考にしてもらえれば大丈夫そうです。ここでは実践として、「網羅しろ！」とか、「網羅しました」とか言われたらどう返答すべきか考察してます。

経営者から「QAが網羅的にテストできてなくてねー」と言われた場合

あなたがQAチームの立ち上げをして欲しいとか、今あるQAチームの課題を解決して欲しいとか言われた時が相当すると思います。

そんなときはこんな感じで逆に質問するのがいいかと思います。

今問題だと考えられている「網羅」ってどういうものでしょうか？どうすれば網羅できてると考えられるでしょうか？

ここでちゃんと返してくれる人か、適当な返しをしてくる人かで対応を変えた方が良いです。ちゃんと返してくれる人に対しては、漏れているテストケースの原因がパラメータの選び方なのか、テスト条件の選び方に課題があるのかを話し合うのが良いでしょう。判断するために今やっているテストケースを見せてもらってもいいかもしれないです。適当に返してくる人には、勇気を出してこう言うのがいいと思います。

問題はそこじゃないと思いますよ、ただ網羅ってだけ言っていると、何をテストすべきなのかが曖昧になって、無駄にコストがかかる上に効果が見込めないと思います (`･ω･´)ｷﾘｯ.

この後は、どうすれば良いかと言ったことまでちゃんと話して、実行に移す気概がないと言うだけ番長になってしまうので気をつけた方が良いです。けど、言われっぱなしで「うー、網羅どうしよう」とかなると本当にろくなことにならないので最初にはっきりいうのが吉です。

先輩から「ちゃんと網羅しろ！」って言われた場合

先輩というか、現場で一緒に仕事している中で、立場が同等、もしくは上の人から言われた場合を考えてみます。開発プロジェクトのPMとか、スクラムチームの中のリード的立場の人とかに言われる場合も同様に考えて良いと思います。

一緒に仕事しているときにあまり関係性が悪くなってもいけないので、否定から入らず、こう言うのがいいでしょう。

何をテストしてるか整理してくるので一緒にチェックしてください！

ここで細かいテストケースではなく、30分とかで説明し切れるわかりやすい形に整理して何をテストしようとしているのか説明できることが大事です。箇条書きでポイントを１ページにまとめるとか。表とか提示するにしても、すごい細かいのは圧がすごくて見れないので、箇条書きでポイントを示す資料を作った上での詳細情報となるようにしましょう。そして簡潔に自分で説明できるよう自分でもどこが大事なのかを自問自答しましょう。そこまではこちらの責任です。

話のわかる人であればちゃんと整理してきたものを一緒に見てくれるでしょうし、ちゃんと自分の意見も言ってくれるはずなので、取り入れていけば良いです。で自然にこう言えるでしょう。

助かります！参考になりました！

見てくれない人は、きっとどう話してもわからないからほっといてあなたがちゃんとテストすれば良いかと思います。あまり口論しあってもろくなことないので結果で示しましょう。

テストベンダーから「全網羅するにはこれだけテストしないといけません」って言われた場合

これは先輩から言われる上のパターンの立場が逆になった状況です。感覚的になんか物凄い量のテストしているけどなんでだろうと思ったら、最初に正直に言ってしまいましょう。

うーん、なんでこんなにいっぱいテストするのか全くわからない。具体的にどういうテストするのか説明してもらえませんか？

ここで、もし細かいテストケースの一覧とか、網の目のようなマトリクスで作られたパターンとかがでてきたらこう言いましょう。

これ見てても細かくて目がチカチカするから、要はどういうテストをしてるのか簡潔に説明して欲しいです。

ここで説明できなくなってくると、多分わかってないでいっぱいテストすればよいってなってる可能性大です。

あと、気をつけた方が良いのは自分の頭で考えなくて、はなから「どこをテストすれば良いでしょうか？」とか、こういってくる人たちです。イラッときますよね？わかります。けど、すぐ怒らないようにするためにまずは深呼吸して、6秒たってからこう言うといいかと思います。

それだと順番が違うので、自分で考えてきてください。

要はテスト対象を理解してるかどうか

テストするにはまずはこれです。どうやって使うものなのか、何が便利なのか、ユーザーが感激するポイントがどこなのか、とか。そう言う感じでテスト対象を理解してないと何をテストして良いかわかるはずはないです...それだけです。網羅とかそういうこと以前にそこでしょ！って感じです。

的を射るテストをするために、どんなことができないとユーザーは困るのか？とか、（システムの構造や、これまでのバグの傾向から）どんなところがバグが出やすいと思っているのか？といったことを加味してテストを設計していれば、それらを説明できるはずで、説明できれば安心かなと。

その上でのどんな網羅基準を適用してるか？って話になります。

これも全て、テストでは「欠陥がないことを証明できない」って原則をわかっていると納得できる話なのかと思います。