テスターのテストによる開発者のためのテストスマートフォン用の表示で見るテスターのテストによる開発者のためのテストシステム業界で思ったことをそのまま言葉にしよう2018-04-28テストケースのないソフトウェアテストについて考えてみるどうも、お久しぶりです。追記:文章内で「テストケースのないソフトウェアテスト」=「アドホックテスト」と定義していましたが、JSTQBの用語との乖離があるとの指摘を頂いたので、修正しております。はて、ひさびさの投稿ですが、今回はこの話題について考えてみようと思います。なにかと話題に上がるテストケースのないテストの話ですが、下記の記事でも取り上げています。tech.nikkeibp.co.jpこの記事では「アドホックテスト」として、話を進めていますので、私もそれに則って、「テストケースのないソフトウェアテスト」=「アドホックテスト」としていきます。行きません!!この記事では、アドホックテストとしていますが、JSTQBの用語集では、アドホックテストは以下のように定義されています。アドホックテスト:非公式に実施するテスト。公式なテストの準備をせず、実績のあるテスト設計技法を用いず、テスト結果も予測せず、毎回、テスト方法が変わる。他にも、探索的テストがあります。探索的テスト:非公式なテスト設計技法の一つ。テストを実施する過程で、テスト担当者かテスト実施情報を活用しなからテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する。このブログは、ほぼアドホックテストになるので、アドホックテストとして話を進めますが、JSTQBの用語と違うのは、下記の赤字部分です。非公式に実施するテスト公式なテストの準備をする場合もある実績のあるテスト設計技法をもちいないテスト結果を予測する毎回、テスト方法が変わるここで、私がアドホックテストを考えるときは2つのポイントに注目します。それは、「テストする人」と「動機」です。アドホックテストで不具合を見つけたいのはもちろんですが、何かしらの不安があるのでテストすると思います。それぞれ考えてみましょう。上司に言われたからやる人たちよくわかんないけど、藁にもすがる思いの人たちとかとんとんですね。それぞれで一つではなく、複数のテストする人がいることもありますし、5のようになぜかやることになっているからやるということもあるでしょう。6の人たちは、テストの勉強をしてもらいたいですが、そんな時間がないくらい切羽つまっているかもしれないですね。テストする人たちも様々ですね。テストする人たちをもう少し大きく分類します。それは、アドホックテストの準備がどのくらい必要かということです。指示型この3パターンに分かれると自立型は、期間とシステムと仕様書があれば、アドホックテストを実施できます。補助型には自立型と比べると、ヒントとなるものが必要になります。それがあればアドホックテストを実施できます。指示型は具体的な確認したいことやシステムの使い方があればアドホックテストを実施できるはず。どのパターンでもフォローは必要になります。その経験では、補助型や指示型に思いがままにアドホックテストを実施してもらうと重要度の低い不具合が上がることが多いです。画面表示に関する不具合が多い気がしています。とある家計簿アプリのアドホックテストをしてもらったときに家計簿アプリの金額欄に1000兆円入れたら、金額の欄の上2桁が表示されない金額入力欄に小数点が入力でき、金額が小数点を考慮した計算がされる一回の買い物で1000兆円使えるユーザーが家計簿アプリをアプリを使う確率は物凄く低いと思います。計算結果にエラーが出るのであれば大問題ですが、この場合であれば入力できるのが間違いという不具合になります。このような問題は他の数値が入力できるところでも同じ問題が出る可能性が高く、不具合が大量生産されます。不具合は上がるに越したことはないかもしれませんが、このような不具合を大量に上げることによって確認で開発者の手を止めるのもまた私にとっては不本意でもあります。補助型や指示型のパターンにはどういう実施をフォローをしていくべきかというと。補助型には、テストで確認してほしいポイントを渡すようにしています。これを私が所属するところでは「テスト観点」と呼んでいます。テストケースの一歩手前くらいの記述内容ですね。複数の業種のシステムを構成する要素を抽象化してまとめたものになります。言っている自分が混乱しそう......。)が入力できること入力桁数が入力できること。入力桁数+1が入力できないこと禁則文字が入力できないこと。Copy&Pasteでも入力できないこと......とかですね。システムの表示部分だけではなく、見えないところのテスト観点もあります。このテスト観点という言葉、色んな人によって考え方が違っていて曖昧な言葉でもあるので、私のテスト観点と読者のテスト観点が違うものになるかもしれません。次は2018年5月29日(火)です。語る夕べの雰囲気をお知らせしますねtogetter.comtogetter.com指示型には、自立型の人と一緒にテストを体験してもらうのが良いと考えます。(その人が何も知らない状態でシステムを触ることで見えてくる課題があるとも思いますが、それはアドホックテストで確認することではなく、ユーザビリティテストで計画した上で実施するのが望ましいです。望ましいんですよ!!)一緒にテストやってもらうといろんなことが起こるんです。テスト設計等の話でペアテストをやってもらったときのことをまとめてますので、よかったら参考にしてください。devtest.hatenablog.com補助型や指示型の人を参画させると余計な工数が取られてしまい、十分なアドホックテストができないと思う方もいらっしゃいますが、後続を育てる意味でも参画させる必要があると思います。(この辺も語りだすと止まらなさそうで本筋から外れるのであまり語りません)次に動機について考えていきましょう。それが定まっていないプロジェクトもありそうですね。何をしたいのかはしっかりと定めて不具合を狙いに行きたいです。仕様書から作っただけのテストケースでは、当たり前品質の確認しかできないかもしれない。魅力的品質も含めて考えた場合、それはテストケースにも現れてくる。何を魅力的品質とするのかは組織やチーム、個人によって異なるので、ここではあまり触れない(というか触れたくない((((;゚Д゚))))ガクガクブルブル)1は仕様書を中心にテストしていく確認作業に近いですね。2はフローやデータのつながりを考えながら実施したほうが良さそうです。3は経験者や第三者検証に依頼したほうがよいです。4は以前やったテストを使いまわしても良さそうですね。6や7はアドホックテストで何がしたいのかをもう一度熟考してもらいたいです。何かしらの不安点があってこそのテストなので。会社に決めているからと言っても無駄な工数を使うためではなく、一番最初にはなにかの課題をクリアしたかったはずです。いうことを言っていると、「あ、じゃ、アドホックテストだけでよくない?」とか言う人がいるんですけど、ドキッとしたそこのあなた!その考え方は危険です。してもアドホックテストだと、テストケースを使用したテストに比べて情報が残りにくいということがあります。残りにくいのは品質の測定のための情報です。この情報がないと次に繋がる一歩に繋げることができません。いうと、どうしても直近のよかったことや困ったことはよく覚えているのに、数週間前や数ヶ月前の記憶は曖昧、もしくは忘却されてしまうからです。不具合として残る情報以外が闇に葬られてしまいます。その所属するテストチームは2週間単位で振り返りをしていますが、それでも直近数日の話が振り返りに上がることが多いですという経験則もありますし、皆さんはどうでしょうか?(チームの話は語り出すと止まらないので、別途記事にしたいと思います)最後に第三者検証会社にいるとどうしても思った以上に品質が悪いという状況になってから参画することが多いです。「予定したテストを行ったが......」その状態から入ったときはアドホックテストを行うことが大半です。最初はアドホックテストを行い、並行でテスト設計を行ったうえでアドホックテストの比率を落としていく等の対策はもちろん行っています。ゼロにはならないんですけどね。アドホックテストだけではなく、テスト設計をしたテストを行うことでお互いの良いところを掛け合わせて品質を高めていけます。22:58テストケースのないソフトウェアテストについて考えてみるTweet広告を非表示にする関連記事2019-12-20テストの諸々のドキュメントをテキストベースで作ってみるにはどうすれば良いかを考えてみた。Calendar」12...2017-11-14木テクにて突撃LTをさせてもらいました!!こんにちは、なそです。2018夏に参加してきました。読者になる検索リンクはてなブログブログをはじめる週刊はてなブログはてなブログPro最新記事テストの諸々のドキュメントをテキストベースで作ってみるにはどうすれば良いかを考えてみた。windows編システムを把握する3つのコツテストラジオを動画にしたよ九州ソフトウェアテスト勉強会の勉強会でワークショップの実験をしてきました!月別アーカイブ参加グループプログラミングはてなブログをはじめよう!DevTestさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。