テストケースのないソフトウェアテストについて考えてみる
どうも、お久しぶりです。
なそです。
追記：文章内で「テストケースのないソフトウェアテスト」＝「アドホックテスト」と定義していましたが、JSTQBの用語との乖離があるとの指摘を頂いたので、修正しております。
さてはて、ひさびさの投稿ですが、今回はこの話題について考えてみようと思います。なにかと話題に上がるテストケースのないテストの話ですが、下記の記事でも取り上げています。
この記事では「アドホックテスト」として、話を進めていますので、私もそれに則って、「テストケースのないソフトウェアテスト」＝「アドホックテスト」としていきます。行きません！！
この記事では、アドホックテストとしていますが、JSTQBの用語集では、アドホックテストは以下のように定義されています。
アドホックテスト：非公式に実施するテスト。公式なテストの準備をせず、実績のあるテスト設計技法を用いず、テスト結果も予測せず、毎回、テスト方法が変わる。
また、他にも、探索的テストがあります。
探索的テスト：非公式なテスト設計技法の一つ。テストを実施する過程で、テスト担当者かテスト実施情報を活用しなからテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する。
このブログは、ほぼアドホックテストになるので、アドホックテストとして話を進めますが、JSTQBの用語と違うのは、下記の赤字部分です。
- 非公式に実施するテスト
- 公式なテストの準備をする場合もある
- 実績のあるテスト設計技法をもちいない
- テスト結果を予測する
- 毎回、テスト方法が変わる
ここで、私がアドホックテストを考えるときは2つのポイントに注目します。それは、「テストする人」と「動機」です。アドホックテストで不具合を見つけたいのはもちろんですが、何かしらの不安があるのでテストすると思います。それぞれ考えてみましょう。
1. テストする人：どんな人がアドホックテストを行うのでしょう？
- とにかくたくさんの業種を問わない人たち
- 何度もリリースに立ち会い、いろいろな問題を解決してきた人たち
- テスト実施は何度も行なっているが、このシステムは未経験な人たち
- 新卒
- 上司に言われたからやる人たち
- よくわかんないけど、藁にもすがる思いの人たち
とかとんとんですね。
もちろん、それぞれで一つではなく、複数のテストする人がいることもありますし、5のようになぜかやることになっているからやるということもあるでしょう。6の人たちは、テストの勉強をしてもらいたいですが、そんな時間がないくらい切羽つまっているかもしれないですね。 また、テストする人たちも様々ですね。テストする人たちをもう少し大きく分類します。それは、アドホックテストの準備がどのくらい必要かということです。
この3パターンに分かれると
自立型は、期間とシステムと仕様書があれば、アドホックテストを実施できます。補助型には自立型と比べると、ヒントとなるものが必要になります。それがあればアドホックテストを実施できます。指示型は具体的な確認したいことやシステムの使い方があればアドホックテストを実施できるはず。
もちろん、どのパターンでもフォローは必要になります。
なその経験では、補助型や指示型に思いがままにアドホックテストを実施してもらうと重要度の低い不具合が上がることが多いです。特に画面表示に関する不具合が多い気がしています。
例えば、とある家計簿アプリのアドホックテストをしてもらったときに
- 家計簿アプリの金額欄に1000兆円入れたら、金額の欄の上2桁が表示されない
- 金額入力欄に小数点が入力でき、金額が小数点を考慮した計算がされる
一回の買い物で1000兆円使えるユーザーが家計簿アプリをアプリを使う確率は物凄く低いと思います。(っていうか、何を買えば1000兆円になるんだ！？) また、計算結果にエラーが出るのであれば大問題ですが、この場合であれば入力できるのが間違いという不具合になります。そして、このような問題は他の数値が入力できるところでも同じ問題が出る可能性が高く、不具合が大量生産されます。不具合は上がるに越したことはないかもしれませんが、このような不具合を大量に上げることによって確認で開発者の手を止めるのもまた私にとっては不本意でもあります。
では、補助型や指示型のパターンにはどういう実施をフォローをしていくべきかというと。補助型には、テストで確認してほしいポイントを渡すようにしています。
これを私が所属するところでは「テスト観点」と呼んでいます。粒度は細かいです。テストケースの一歩手前くらいの記述内容ですね。複数の業種のシステムを構成する要素を抽象化してまとめたものになります。って言っている自分が混乱しそう……。
例を挙げると、テキストボックスだったら
- 入力文字種(半角、全角、数値、記号等)が入力できること
- 入力桁数が入力できること。入力桁数＋1が入力できないこと
- 禁則文字が入力できないこと。Copy&Pasteでも入力できないこと
- ……
とかですね。もちろんシステムの表示部分だけではなく、見えないところのテスト観点もあります。
このテスト観点という言葉、色んな人によって考え方が違っていて曖昧な言葉でもあるので、私のテスト観点と読者のテスト観点が違うものになるかもしれません。
テスト観点に興味のある方はぜひ、テスト観点を語る夕べにご参加ください！ 一緒に語らいましょう♪ 次は2018年5月29日(火)です。語る夕べの雰囲気をお知らせしますね
指示型には、自立型の人と一緒にテストを体験してもらうのが良いと考えます。(その人が何も知らない状態でシステムを触ることで見えてくる課題があるとも思いますが、それはアドホックテストで確認することではなく、ユーザビリティテストで計画した上で実施するのが望ましいです。望ましいんですよ！！)
一緒にテストやってもらうといろんなことが起こるんです。テスト設計等の話でペアテストをやってもらったときのことをまとめてますので、よかったら参考にしてください。
補助型や指示型の人を参画させると余計な工数が取られてしまい、十分なアドホックテストができないと思う方もいらっしゃいますが、後続を育てる意味でも参画させる必要があると思います。(この辺も語りだすと止まらなさそうで本筋から外れるのであまり語りません)
次に動機について考えていきましょう。
2. 動機：なぜ、アドホックテストを行うのでしょう？
- アドホックテスト以外のテストでは詳細な手順を記載するが、記載しきれない仕様の不具合を見つけたい？
- 仕様に書かれたテストは十分だが、人の感覚や経験に基づく不具合を見つけたいから？
- 過去の不具合を参考にテストをしたいが、過去の不具合が資料として残っておらず経験者にも診断してもらいたいから？
- テストした環境とリリースする環境の不一致があり、不一致部分の不具合を見つけたいから？
- テストケースを作る工数がなく、なんでも良いから不具合を見つけたい？
- 気が進まないが、上司からやれと言われたから？
- なんかやればよいことがあるらしいから？
何をしたいのかはプロジェクトによって異なりますが、 それが定まっていないプロジェクトもありそうですね。何をしたいのかはしっかりと定めて不具合を狙いに行きたいです。
仕様書から作っただけのテストケースでは、当たり前品質の確認しかできないかもしれない。魅力的品質も含めて考えた場合、それはテストケースにも現れてくる。何を魅力的品質とするのかは組織やチーム、個人によって異なるので、ここではあまり触れない（というか触れたくない((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ）
1は仕様書を中心にテストしていく確認作業に近いですね。2はフローやデータのつながりを考えながら実施したほうが良さそうです。3は経験者や第三者検証に依頼したほうがよいです。4は以前やったテストを使いまわしても良さそうですね。5はそう思っているなら今すぐテストケースを書くための努力をしてくださいToT 6や7はアドホックテストで何がしたいのかをもう一度熟考してもらいたいです。何かしらの不安点があってこそのテストなので。会社に決めているからと言っても無駄な工数を使うためではなく、一番最初にはなにかの課題をクリアしたかったはずです。
で、こういうことを言っていると、「あ、じゃ、アドホックテストだけでよくない？」とか言う人がいるんですけど、ドキッとしたそこのあなた！その考え方は危険です。どうしてもアドホックテストだと、テストケースを使用したテストに比べて情報が残りにくいということがあります。残りにくいのは品質の測定のための情報です。この情報がないと次に繋がる一歩に繋げることができません。なぜかというと、どうしても直近のよかったことや困ったことはよく覚えているのに、数週間前や数ヶ月前の記憶は曖昧、もしくは忘却されてしまうからです。不具合として残る情報以外が闇に葬られてしまいます。
なその所属するテストチームは２週間単位で振り返りをしていますが、それでも直近数日の話が振り返りに上がることが多いですという経験則もありますし、皆さんはどうでしょうか？（チームの話は語り出すと止まらないので、別途記事にしたいと思います）
最後に第三者検証会社にいるとどうしても思った以上に品質が悪いという状況になってから参画することが多いです。「予定したテストを行ったが……」その状態から入ったときはアドホックテストを行うことが大半です。しかし、最初はアドホックテストを行い、並行でテスト設計を行ったうえでアドホックテストの比率を落としていく等の対策はもちろん行っています。ゼロにはならないんですけどね。
アドホックテストだけではなく、テスト設計をしたテストを行うことでお互いの良いところを掛け合わせて品質を高めていけます。アドホックテストと言う名前のテストを設けたからと品質が高まるわけではなく、それで何がしたいかどんな人をアサインできるかとかまで考えないともったいない工数になってしまいますねということで今回は締めさせてもらいます！
それでは、今回はテストケースのないソフトウェアテストについてお送りしました！
http://jstqb.jp/dl/JSTQB-glossary.V2.3.J01.pdf
