nemorineのブログnemorineのブログ読者になるnemorineのブログこの広告は、90日以上更新していないブログに表示しています。23日目(実質29日目)です。https://www.amazon.co.jp/dp/4274227944自分が担当した20章「ソフトウェアテストー統合レベルー」にに書かれている良いテストの特性を考えてみようと思います。良いテストは、高い確率でエラーを発見できるテストである良いテストは、高い確率でエラーを発見できるテストであるこの目標を達成するために、テスターはソフトウェアを理解し、どのようにソフトウェアが失敗するかを頭の中でイメージしなければならない。個人的に良いと思うのは、「テスターはソフトウェアを理解する必要がある」ということと、「失敗をイメージしないといけない」ということです。「ボタンを連打してみた」ではなく、特定の狙い(イメージ)を持ってテストをするのが良いと思います。バグが出やすい操作はありますが、「イベントが短時間で連続で発生したときに制御されていないかもしれないので、ボタン連打をする」というところまでイメージしながらテストできると良いと思います。テストはイメージの世界です。良いテストは、冗長ではない良いテストは、冗長ではないテストの時間とリソースは限られている。2つのテストケースを同じ目的で実行しても意味がない。すべてのテストは、たとえそれが微妙な違いであっても、それぞれが異なる目的をもつべきである。試験書などに書き起こしても、テストの目的が書かれていないことがあります。これはとても勿体ないですし、レビューなどで重複を取ることが大変になるので常にテストの目的を書いておきたいところです。探索的テストなどでガリガリ動かすときも、テストの目的を考えておくのはいいですよね。最初に述べた「失敗のイメージ」にもつながる話だと思います。良いテストは、「ベストオブブリード(最高の品種)」であるべきである良いテストは、「ベストオブブリード(最高の品種)」であるべきである時間やリソースに限りがあるときは、目的の似たテスト群の中から特定種類のエラーすべてを発見できそうな「最高の品種」といえるテストのみを実行するのがよい。テストというと「網羅網羅」というようなモウラ星人が多いのですが、早くフィードバックし、早くテストを終わらせてプロダクトをリリースするにはテストの網羅も考えつつ、数を減らさないといけないです。ここでいうような良いテストをデザインする力が必要になります。良いテストは、単純すぎても、複雑すぎてもいけない良いテストは、単純すぎても、複雑すぎてもいけない複数のテストケースを1つのテストケースにまとめてることができる場合もあるが、副作用が発生してエラーの存在が隠れてしまうこともある。一般的には、各テストは独立して実行するのが良い。3つ目からの続きになりますが、色々なエラーを取れるようなテストケースをデザインしてもそれによって隠れてしまうエラーがあっては本末転倒になります。前のテストが後のテストに影響するようなこともありますので注意が必要です。Timely)と言われるように、どのテストでも独立性は重要になってきます。まとめこんな感じでチームの中で「自分達の考える良いテスト」って何だろう?って話ができれば良いと思っています。探索的テスト探索してますか?最近は色々なところで探索的テストの話を聞くようになりました。個人的に少し気になることがあるので、書いてみようと思います。「チャーターだけに沿った探索的テストをしていませんか?」ということです。探索的テスト≠チャーターを使ったテスト探索的テスト=チャーターを使ったテストみたいな認識になっている気がしていて、それはちょっと違うかなと思っています。探索的テストはあくまで目の前にあるソフトウェアから得た情報をもとにテスト設計、実行をしていくテストだと思っています。慣れていないと事前に記述するチャーターを細かく設定することが多く、それはほぼ抽象度の高いテストケースになります。それがある程度網羅されていると、それをなぞるのに精いっぱいになったり、網羅することで満足してしまいます。「チャーターに沿って探索しましたが、バグは出ませんでした。手順がないテストケースだけを実施して満足したいわけじゃないんです。オポチュニティそこで重要になってくる考え方が「オポチュニティ」です。Testing(RST)に記述されている探索的テストの1つであるセッションベースドテストの報告項目には以下が含まれています。*1チャーター/オポチュニティ(トータルセッションに対する割合。オポチュニティはチャーターには当てはまらないが、有用なテスト作業である)チャーターに80%、チャーターに沿わない時間(=オポチュニティ)が20%の場合は80/20みたいな形です。このオポチュニティと全体に対する割合が定義されていることが重要だと考えています。図で書くとこんなイメージです。チャーターとオポチュニティチャーターに沿った場合は、チャーター付近のバグ(小赤星)は気付くと思いますが、奥深くにあるバグ(大赤星)を見つけることはできません。チャーターから外れて奥を探索することで(=オポチュニティ)奥深くに存在するバグを見つけることができます。秋山さんから質問があったので、自分なりの答えを書いてみます。常にオポチュニティが0(図でいうと緑のところが一つもない)というのは避けたほうがよいと思っています。いうより90/10や80/20みたいな形がいいのだろうと思っています。割合はソフトウェアの作り、テスターのスキル、チャーターの抽象度などによると思っているので、理想は80/20みたいなものはないと思っています。「2割くらいはチャーター外れていきましょう!」というようなチームの目標値は個人的にはありだと思います。この式に「検出したバグの数や種類」が現れていないのも気になります。RSTにはバグの報告の記述はありますが、チャーター/オポチュニティによるバグの数や種類の分類はないです。やってみると面白そうな気がしますが、実務的には単純にソフトウェアの機能で分類する方が有益そうだと思います。2021アドカレ!の19日目のエントリです。2021年も残りわずかになりました。11回とはなかなかですね。アジャイル札幌と共に歩んで来たと言っても過言ではないアジャイルジャパン札幌サテライトだと思っています。NEW!ここで企画の一部をお伝えします。今年はオンサイトで実施します。久しぶりの対面でちょっとドキドキしますね。札幌に足を運んでもらい、JOYを広めてもらいたいなぁと考えています。皆さん、久しぶりにリアルで会えることを楽しみにしています。https://www.amazon.co.jp/dp/4274227944自分が担当した16章「レビューの推奨手法」における好きなところを3点書こうと思います。レビューへの向き合い方(P243)作成者ではなく成果物をレビューする。FTRには、人とエゴが関与している。適切に実施されたFTRは、すべての参加者が達成感を感じるものでなければならない。不適切なFTRは審問のような雰囲気を醸し出すことがある。エラーを指摘するときは優しく、ミーティングのトーンはゆるやかで建設的なものにし、恥をかかせたり、貶めたりすることを意図してはいけない。レビューリーダーは、レビューミーティングにおける適切なトーンと態度が維持されるよう努め、レビューが制御不能になった場合は直ちに中止の判断をすべきである。読む前はエンジニアリングということで手法の紹介がメインかと思っていたのですが、レビューへの向き合い方がガイドラインとして書かれています。ともすると人格攻撃になったりするので、ビューの場だけではなく、日常的に気を付けないといけないことだと思います。自分が何かをレビューするときに気にしているところも書いてみます。(できてないときもあるけど意識しようとはしてますw)根拠のない高い期待をしないまず全体を見て、いいところを探す問題を提示する箇所は理由を言う(可能な限り言語化する)好みの場合はオプションとして提示するが決定は任せる(後で文句は言わない)レビューは時間を...するもの(P239)「レビューは時間を奪うものではなく、時間を節約するものである。言われてみると当たり前なのですが、レビューに時間を奪われていると感じる人が多いのも事実だと思います。「レビュー工数が組み込まれていない」とか「レビューが一人に集中する」とか「定型的に10人が見るようになっている」とかではないでしょうか?自分達のプロセスに合わせて柔軟に変えていきたいところです。図を見るとレビューの有無によって工数に違いがあります。マズいものは早めにフィードバックする。アジャイルテスティングの本質にも通じることだと思います。アジャイルのレビュー(P244)スクラムのフレームワーク(3.4節)を詳しく見ると、非形式的レビューと形式的レビューが行われる場所はいくつかあることがわかる。スプリントプランニングでは、次のスプリントに含めるユーザーストーリーをレビューし、優先度にしたがって順位付けをする。見ることができ、(後略)インスペクションレビュー以外はレビューとして認めないという原理主義みたいな方もいますが、あらゆるところにレビューはありますよという話がここにキチンと書いてあります。インスペクションの良さを否定するつもりはありませんが、日常的に対話をしながら、問題が小さいうちに摘み取ったり、チームとしての共通認識を育てていく方が自分は好きです。まとめ今回はレビューの章を紹介しました。分厚くて堅い本と思われますが、結構いいこと書いていますので是非ご一読ください(宣伝レビューの向き合い方に関してはこの記事もおススメです。