見出し画像

58号：テスト実行

Kouichi Akiyama

≣ はじめに

「ASTERセミナー標準テキスト」の39ページについてです。

（手動の）「テスト実行」は最も好きなプロセスです。
仕様書だけでは分からない実際の動きを見ながら、「こうしても大丈夫かな？」と気になる点をつついて、バグが見つかるとうれしいものです。
（逆に、自分がテストした範囲に見落としがあって、リリース後にバグがみつかると、とても悔しいですし、凹みます。）

『ミッケ！』という絵本をご存知でしょうか？　見開きでたくさんのアイテムが書かれたカラーの絵（シリーズによっては写真）があり、そこに「ｘｘを探して」（実際にはこんな直接的な書き方ではなくて、それ自体、ちょっと謎めいたワクワクする問いかけになっています）という問題があって、ｘｘを探すという単純なものです。
『ウォーリーをさがせ！』の探す対象が色々版というと伝わるでしょうか。
お医者さんの待合コーナーの絵本置き場にあることが多いので探してみてください。（大型書店の絵本売り場には何冊もあります）
さて、『ミッケ！』ですが、3歳くらいの子供から楽しめるんじゃないかなあ。親子で競争して、案外子供の方が見つけるのが早かったりして、楽しい絵本です。同じように、ソフトウェアのテストでもバグを見つけるとうれしいものです。
ところで、『ミッケ！』ですが、テストのノウハウを使うと、グンと早く見つけることができるんですよ……。でも、その方法は秘密です。おもしろくなくなってしまうから。（笑）


≣ テスト実行の心得

今どき、精神論かよ、と思われるかもしれませんが、

「テストとは、エラーを見つけるつもりでプログラムを実行する過程である。」 （1979年）　　by G.J. Myers

を思い出しましょう。

私は、かれこれ20年以上テストをしていますが、Myersのこの呪文すごいです。ぼけーっとテストして手だけ動かしているとテスト手順書の実施消化率は上がるのですが、あまり、バグは見つかりません。一方で、この呪文？を唱えて気合を入れてテストすると、あら不思議、たくさんのバグが見つかります。
だまされたと思ってお試しあれ。

「エラーを見つけるつもりでプログラムを実行する」について、さらに具体的にいえば、いつも、「こうなるだろう」と期待結果を想像しながらテストすることです。そうすると、バグ検出の感度が上がるような気がします。


≣ テストの目的を意識する

とくに、テスト設計者（テストケースやテスト手順書を作る人）とテスト実行者が異なる場合には、「このテスト（ケース・手順）で何を確認したいのか？」がテスト実行者に伝わっていることが大切です。

あんがい、「テスト（ケース・手順）」をみただけでは、そのテストがなんで必要なのか、第三者には分からないものです。

例えば、昨日、執筆された「『ソフトウェアテスト技法 練習帳』を解きながら、自分の考え方も整理していく。」というブログは、とても素晴らしい内容ですが、その発端となったツイート

のそれぞれの行が「何を確認したいのか？」、「どのような目的を持った行なのか」をブログを読まずにテスト実行者が理解することは困難です。（Twitterの文字数制限もあるので、カズさんが悪いわけではありません。誤解なきようお願いします）

ツイートの方でも、各行の右端に、「80判定上限」、「エラー」、「入力可能上限」などの目的が書いてありますので、注意深い人なら分かりますが、それでも「80判定下限」が2つある理由などはドメインテスト技法を知らない人には、ピンとこないように思います。

≣ 偽陽性は気にしない

COVID-19ですっかり有名になってしまった偽陽性（検査結果はCOVID-19に感染していると出たけど、感染していなかった状態を偽陽性と呼びます）ですが、テストにおける偽陽性とは、「バグと思ったけど、バグじゃなかった」です。きちんと書けば、

偽陽性　＝　誤った失敗結果（FALSE-fail result）：
　　　実際には、欠陥による故障ではないもの。（仕様の勘違いなど。）

です。

上に例として「仕様の勘違い」が挙がっていますが、他にも、

・　間違いやすい仕様
・　操作ミス
・　他責の問題
・　制限事項としてマニュアル等に記載済みのもの

なども、偽陽性の原因となります。偽陽性の不具合票はリジェクト（却下）されてしまうかもしれません。

制限事項についてリジェクトするかどうかは議論になるかもしれません。個人的にはリジェクトしない方が良いと思っていますが、「制限事項をバグとして報告されると頭に来る」と言っていた開発者さんもいたので、気をつけた方が良いでしょう。本当に制限事項に当てはまるのか迷う現象もありますし。
また、別の現象（故障）が、同じ欠陥がもとで発生している場合、一つの不具合票にまとめるべきかどうかについては、テストを実行する前に決めて、関係部門と合意しておく必要があります。
※　テスト中の故障については同じ欠陥であれば一つの不具合票にまとめ、リリース後の故障については別の不具合票で（同じ欠陥であってもまとめずに）管理することが多いようです。

テストをして、気になったこと（＝自分の知見や経験から逸脱していること）は、全て不正（anomaly）です。このアノマリーのなかには、欠陥（defect）由来のものもあれば、上述した偽陽性のものもあります。
たとえ、偽陽性だったとしても、その数が多く、見過ごせない状況にあれば、それは、お客様からのクレームにつながることが想定されますから何らかの対応が必要です。
テスト担当者は、偽陽性であることを懼れずに遠慮なく不具合票を挙げるべきです。また、テストマネージャーはテスト結果報告書を書く際に、偽陽性だった（リジェクトされた）不具合報告についてもう一度目を通し、問題のないことを確認した方が良いでしょう。

上に「気になったこと（＝自分の知見や経験から逸脱していること）」と書きましたが、しっかりした根拠を示せなくても構いません。「違和感を覚えた」とか、「なんか違う気がする」といった感覚的なもののなかに、重大な問題の種があることがあります。なお、違和感に対して「納得するまでテストを続ける」のも良いですが、「周りの開発者に見てもらって意見を聞く」ことも勉強になります。周りに開発者がいないときにはテストリーダーや同僚のテストエンジニアに聞くのもアリです。
ところで、リリース後にお客様先で不具合が発生したときに、その内容についてテスト担当者に「テスト中に起こらなかった？」と聞くと「起こりましたよ」という返事が返ってくることがあります。「発生したけど、テスト手順書に書いてあるチェックポイントではないから報告しようか迷っているうちに、ま、いいかってなりました」と言うのです。
これも、広い意味では偽陽性を気にしすぎたことの悪影響かもしれません。


≣ 終わりに

同じテスト手順書を使っていても、テスト担当者ごとに、テスト実行結果は異なります。バグを多く見つける人もいれば、一つも見つからない人もいます。鋭敏な観察眼の有無や、注意深さの違いもあるのですが、繰り返しになりますが、「こうなるはずだ」という想像をしてから操作をしているかどうかの差が大きいと思っています。

また、折角見つけているのに、偽陽性を気にして報告しないのはもったいないですよね。テスト担当者に悪気はなくても、「テスト手順書を進めること」が仕事の目的と思い込んでいるのと、報告後に無駄な作業を発生させたら申し訳ないという優しい気持ちからだと思います。何を報告して何は報告しないかについては、質問することが難しいのと同じくらいに難しいと思います。上手くやるには、経験を積むしかないのかもしれません。経験とはテストの経験だけではなく、コンピュータの経験等々、様々な経験を含みます。

最後になりますが、キャッチイメージの2行目に「テスト実行スケジュールに従ってテストスイートを実行する」とあるように「スケジュールに従うこと」も大切です。

スケジュールに従わせるためには、テスト手順を単純作業レベル、つまり、「誰が行っても同じ効果を得ることが出来る」ように書いておく必要があります。そうすれば、スケジュールに余裕がなくなったときに、手が空いている誰かをテスト実行のための成員として投入することでスケジュールを守ることができるからです。自動テストスクリプトの場合はテストを自動実行するためのPC等の機材を増やしても良いですね。

上記でスケジュールに従わせる方法について書きました。しかし、テストは実行中でないと分からないことが多いので、人が実施する「テスト手順書」を詳細に書くことを私は推奨しません。
できるだけ、粗く書き、足りない部分についてはテスト実行前に十分な教育をする方が良い欠陥を見つけることができると信じているからです。

この記事が気に入ったらサポートをしてみませんか？