ソフトウェアの品質を学びまくる2.0

ソフトウェアの品質、テストなどについて学んだことを記録するブログです。

「シナリオテスト」とは一体、何なのか - その5

Kufi Script, 9-10th cent., qur'anic verse 3

 シナリオテストについての覚書。
 シナリオテストについては何度もオレオレ定義を書き散らしてきて、今回もその類なのですが。
 「その4」は、コチラ。

www.kzsuzuki.com

 シナリオテストを行ううえで、大きく2つのことを意識しているなと考えたので、メモです。
 2つというのは以下です。

  1. ソフトウェアの利用のEnd to Endを意識する。
  2. ソフトウェアを使う人を意識する。

1. ソフトウェアの利用のEnd to Endを意識する。

 テストシナリオ、つまり「ユーザがソフトウェアを利用する流れ」は、どのように考えるとよいでしょう。

 ソフトウェアが提供する機能から考えると、開発者目線に偏りがちになるように思います。
 シナリオを考える際には、機能からではなく、「ユーザが達成したいこと」を起点にするのがよいでしょう。
 「ソフトウェアが提供する機能を組み合わせて何ができるか」ではなく、「ユーザが達成したいことを、ソフトウェアが提供する機能はサポートできるか」で考えるというか。
 前者だと、当該ソフトウェアの外にあるもの、たとえば他のソフトウェア・ITシステム、物理的なモノ、人間系、時間の流れといったものが見落とされがちです。

 「達成したいこと」は、ソフトウェアだけで実現するとは限りません。ユースケース同士を、人間系でつなぐこともあります。ソフトウェア的には、先のユースケースの出力と、次のユースケースの入力が、いったん断絶することになります。
 ユースケースの間にある人間系で、その断絶が正しく埋まっているのか。これは個々のユースケースの確認だけでは検証できないんですよね。

 なお、「その1」では、「テストシナリオ」を以下のように位置づけていました。

テストシナリオとは、「テストケースの部分集合に順序をもたせたもの」である。

 今ではやっぱり違うかなと思っています。上述の「ユースケースの間」が無視されているように見えるためです。

www.kzsuzuki.com

2. ソフトウェアを使う人を意識する。

 ソフトウェアで複数のロールを扱っていて、ロールごとに持つ権限が異なる場合。
 権限そのものに関するテストでなければ、ついつい最強の「管理者」的なロールでテストをしがちということはないでしょうか。権限の限定されたロールだと、テストの準備のために権限を切り替える必要があったりと、ちょいちょい面倒が出るためです。
 このやり方だと、弱い権限のロールに、ソフトウェアの何が見えないのかが隠されてしまいます。

 また、たとえ持つ権限が同じであっても、ロールが異なれば見えている世界が違うはずですが、機能の入出力に注目するテストでは、この点も見過ごされがちに思います。

 シナリオテストにおいては、このロールと権限を常に意識する必要があります。
 そのロールのユーザが、何を知っていて、何を考えていて、何を求めているのかを意識しながら、ソフトウェアを触る。シンプルな入力系の画面でも、「この情報はこのロールの人は知っているものなのか」「この用語はこのロールの人にとって理解できるものなのか」を考える。このような視点は、入力値のバリエーションとその出力を検証する機能テストではあまり現れません。

 突き詰めると、「この人は、このソフトウェアを、自然に使えるか」ということを検証したいんですね。
 よってシナリオテストの各ステップには、「どのロールとして行うか」を明記して、テストをする人はそのロールになりきる努力が必要です。

あとがき

 シナリオテストにおいて意識するとよい2つのことについて、書きなぐりました。
 もう少し、具体的なソフトウェアを例にとって述べられるといいのですが、本業に抵触すると面倒なので、抽象的な話になります。。。

 シナリオテストは、テストの中でも特に面白いと個人的には思うので、もう少し方法論作られたらいいなあ(ずっと言ってる)。

探索的テストのPQIP

France-001675 - Maze

 「ASAP」といえばできるだけ早く、セキュリティ業界の「PPAP」*1 といえばパスワード付きZIPファイル添付メールですが、探索的テストのPQIPというのを知ったので紹介します。

探索的テストのPQIP

 「PQIP」は、Simon Tomesさんの「Three Digestible Diagrams to Describe Exploratory Testing」(探索的テストを説明するためのわかりやすい図)という記事で紹介されています。

www.ministryoftesting.com

 キッカケは、手動テストケースに対する「passed」「failed」というチェックに対し、誰かの注意を引くのが failed ばかりで、passed では何かしらの共有したり議論したりする機会を逸しているとTomesさんが感じたこと。

 PQIPは、探索的テストの中で見出したものをチームに共有するガイドです。
 テストというと「不良を見つける」ことに傾きがちですが、そこにとどまらず、開かれた会話を促進するための機会にしようということですね。

 以下が、PQIPの図です。

f:id:kz_suzuki:20200922122806p:plain
credit: https://www.ministryoftesting.com/dojo

 PROBLEMSは、いわゆる不具合・バグと思われるものを報告するものです。テストにおける「アウトプット」としては一番わかりやすいですね。

 QUESTIONSは、よくわからない点を明確にするためのものです。
 探索的テストに限らず、テストの結果って実は pass / fail にさくっと割り切れるものではなく、むしろ「これってどうなんだろ」「どういう理屈でこう動くんだろ」みたいな「質問」が多かったりもしますよね。

 IDEASは、探索の中でひらめいたアイデアです。
 テストは、仕様をその通りになぞって適否を判断するだけのものではなく、「こうしたらもっとよくなるのではないか」というフィードバックをもたらしていくものなんですね。仕様を検討している人、実装している人からは見えづらくなっている発想が、テストから生まれることもあります。

 PRAISEは、称賛。テスト対象について、素晴らしいと感じたことを伝えるということです。
 Tomesさんのいう通り、テストにおいては failed ばかりが注目されがちだし、場合によってはテストは「常に凶報をもたらすアクティビティ」というネガティブなイメージにもなりかねません。良くない点を伝えるばかりでなく、良いと感じた部分を積極的に、意識的に出す。これは素敵な活動ですね。

 『英語の品格』(ロッシェル・カップ、大野和基・著)*2では、日本人の成果物評価について、以下のように述べています。

 日本の会社で働いたことがあるアメリカ人は異口同音に、「会社に感謝されていないと感じる」と言います。それはなぜでしょうか。日本人は、評価するときに問題だけを指摘するからです。その裏には、「指摘されていないところは問題ない」という暗黙の了解があります。アメリカ人は通常、先に良いところをほめてから本題に入るので、日本人の指摘の仕方に慣れておらず、まるで全否定されてたように感じでしまいます。

 このような国民性(?)から考えても、探索的テストに限らずテスト全般で、「いいところはそれをきちんと伝える」という考え方は有効だと思います。

 元記事の最後では、以下のように語っています。(日本語訳はわたし)

We have a duty to inspire others with an exploratory testing mindset and approach. Let's be bold and share its true value in a way that doesn't overwhelm, frustrate, confuse, devalue, mislead or anger. Let's enhance our exploratory testing techniques by collaborating with others to evolve and improve the practice and mindset.
わたしたちは、探索的テストのマインドセットとアプローチによって、周りを鼓舞しなければなりません。勇気をもって、その価値を伝えましょう。相手を閉口させたり、気持ちを萎えさせたり、混乱させたり、貶めたり、ミスリードしたり、怒らせたりしないようなやり方で。プラクティスとマインドセットを周りの人たちと発展・改善することで、探索的テストの技術を一緒に向上させていきましょう。

JaSSTで探索的テストのセッションが!

 さて探索的テストといえば、オンラインJaSST*3の第2回目(ソフトウェアテストシンポジウム オンライン Bergamot)では、ネモさんによる探索的テストのセッションがあります。

www.jasst.jp

 わたしもさっそく申し込みました。探索的テストをずっと実践しているネモさんのセッション、楽しみにしています!

*1:* Passwordつきzip暗号化メールを送ります * Passwordを送ります * Aん号化 * Protocol
のことです。 www.itmedia.co.jp

*2:この本はとてもお勧めなのですが、自分の英語にとことん自信がなくなる副作用もあります。自分のしょっぱい英語が、ネイティブにどんなニュアンスで伝わっているのかを思うと、身が縮む思いです・・・。

*3:従来の地域JaSSTもオンライン開催しているので、狭義のオンラインJaSSTと呼ぶべきか・・・

自動化によるテスト工数削減をメトリクスで見る場合のトラップ

Eight, going on nine

 テストの自動化を進める際、そのよしあしを確認するために、いろいろなカットからのメトリクスを取ると思います。
 たとえば進捗を測るためには、テストケースを自動化した割合。効率化を測るためには、自動テストによって削減できた時間や、逆に自動テストがもたらしてしまった別の作業時間。安定性を測るためには、自動テストの失敗傾向とその要因分布。
 こういったメトリクスの中で、工数の削減効果をどう表現しようかと検討していた際に、メトリクスの典型的なトラップと言えそうなものにぶち当たったことがあるので、メモしておきます。

工数削減効果をどう測るか

 この記事は、「こういうメトリクスで計測するのがいい」という紹介ではないので、注意してください。
 ともあれわたしは、以下のようなメトリクスを考えました。

工数削減率 = 1 - X / Y
X: 手動テストに要した工数 + 自動テストに要した工数
Y: 手動テストに要した工数 + Xの第2項をテストを手動で行った場合に要するであろう工数

 Yの第2項はちとややこしいですね。具体的な計算例を見てみましょう。

 まず実際のテストにおいて、手動テストに45時間、自動テストに1時間かけたとします*1。この場合、X = 45 + 1 = 46 です。
 次にY。Xでの自動テスト群が実はとても面倒な作業を代替してくれるもので、手でやったら5時間はかかるよ!と想定できる*2のであれば、Y = 45 + 5 = 50 となります。
 工数削減率は、1 - 46 / 50 = 8% という計算になります。

 このような想定の数字を持ち込まくても、たとえば「前のバージョンと比較する」という時系列的な比較も可能ではあります。ただ実際には、バージョンごとに開発内容が違う、よってテストの所要工数も異なり、比較にあまり意味がありません。
 そこでこの時は、「もし自動テストがなかったら」という時間を計上して、比較することを考えました。

 なお、第2項同士を比べると、工数削減率 = 1 - 1 / 5 = 80% となりますが、この条件で「テストの工数を80%削減できた!」というのはさすがにミスリード。手動テストの第1項は落とせません。

「工数削減率」をどう上げるか

 では、「工数削減率」*3を上げるには、どういう方法が考えられるでしょうか。
 計算式の定義上、X / Y をできるだけ小さくすればいいことになります。

分子Xを小さくする

 Xを小さくするには、 「自動テストに要した工数」を小さくすればいいですね。そのために考えられることは、たとえば以下です。

  • 自動テストを実行前の環境のセットアップや、実行後のクリーンアップに人手をかけているなら、そこまで含めて、自動化・効率化を進める
  • 自動テストの結果の検証に、人間の関与ができるだけ入らないようにする
  • 自動テストの失敗要因を分析し、時間ロスの大きいものから対策する

 自動テストの仕組みが未成熟な時期には、このあたりの対策がとれますよね。

分母Yを大きくする

 Yを大きくするには、「手動で行った場合の想定工数」を大きくすることになります。

 急にきなくさくなりましたね。このメトリクスのトラップの1つがここにあります。
 「想定工数」の恣意性が大きいと、出したい数字に合わせて操作できてしまうんですね。 結果ありきの「想定」をしない、誠実な心が求められます。あるいは恣意性を下げるために、想定工数を算出するための基準を作っておくといった手段も考えられます。

 Yを大きくするための本来の方法は、

  • 手動で時間がかかっているテストを優先的に自動化する

でしょう。同じ1時間の自動テストなら、10時間かかるだろうテストより、20時間かかるテストを自動化した方がYが大きくなります。

第1項を小さくする

 X / Yを小さくする今一つの方法は、第1項、「手動テストに要した工数」を小さくすることです。
 上の例の通り、自動テストによって、その部分だけは80%削減できているのに、テストの工数全体で見ると手動テストの方が支配的なので、全体としては8%削減という結果になっています。この第1項の寄与を小さくするにはどうすればいいでしょう。

 まず、2つ考えられます。

  1. テスト全体のうち、自動テストの割合を増やしていく。
  2. テストケースの最適化を行い、対象とするテストのボリュームを減らす。

 1.はそのままですね。テストケースの件数に対する自動化率といった他のメトリクスと合わせてみると、判断しやすいでしょう。

 2.には、メトリクスのトラップ2つ目があります。
 テストを最適化することによって削減されるテストケースは、手動テスト分とは限りません。自動化済みのテストケースが削減対象候補になることもあるでしょう。場合によっては、何も考えず流していた自動テストの方が無駄だとわかって、削減する必要があるかもしれません。今回のメトリクスでは、「正しいことをしたのに、メトリクスは悪化する」可能性があります。

 このような場合に、「メトリクスを維持するために、自動テストの削減をしない」とか、あるいは「メトリクスの値を向上させるために、何も考えずに手動テストの方を削減する」という方向に向かってしまっては本末転倒です。  上の例で、手動テストを2/3の15時間に減らせば、X = 16、Y = 20 で、工数削減率は20%に押し上げられますが、これは本当によい「削減」だったのか、ということですね。

f:id:kz_suzuki:20200913163827p:plain
手動をさぼって削減率アーップ!

 今回のメトリクスは、端的に言うと「手動テストをさぼると値が改善する」という欠陥を持っているので、別の指標、たとえば「工数削減率」ではなく「工数削減時間」の絶対値だとか、テストの網羅性などを合わせてみないと、間違った方向につながりかねません。

メトリクスのトラップ例のまとめ

 この例では、単純なメトリクスを使って、2つの罠について考えてみました。

  1. ほしい結果を出すために、適切でない想定で値を操作する。
  2. ほしい結果を出すために、適切でない行動でパラメタを操作する。

 これを防止するためには、

  • メトリクス自体の妥当性の確認
  • メトリクスの値を改善するための施策の妥当性の確認
  • 別の指標を合わせての評価

といったことが必要ですね。みんな知っていることの再確認でした。

*1:自動なのに1時間もかかるのはおかしい、というご意見もあると思いますが、例です。このあとも、実行時間のオーダーが「時間」ですが、そーいうことです。

*2:必ずしも、もともと手動でやっていたテストを自動化するとは限らないので、手動での工数は想定とせざるを得ない場合があります。

*3:タイトルがカッコ付きになっているのは、真の意味の効果といえないことがあるからです。

『TestSphereの遊び方を考える会』の第1回をやりました!

 こちらで予告した『TestSphereの遊び方を考える会』の第1回をやったので、レポートです。

www.kzsuzuki.com

 付き合ってくれたメンバーは、オムそばさん、ネモさん、ばんさん、リナさん、あさこさんです。ありがとうございます。

f:id:kz_suzuki:20200802212124j:plain

目的

 前回紹介した通り、TestSphereは100枚のカードからなるデッキ。100枚は5つのカテゴリー×20枚からなり、それぞれのカテゴリーに属するキーワードとその説明、プラス3つの事例、という作りになっています。

 使い方が厳密に規定されているわけではありません。テスト計画を使う際のブレインストーミングに使ったり、会話のきっかけに使ったり、ゲームをしたり・・・と、さまざまな使い方のアイデアがあります。
 今回の『考える会』では、オンラインを前提に、どのように遊べるかをみんなで考えよう!ということで企画してみました。

いきなり「??」となる・・・

 上に書いたようなTestSphereざっくり情報をみんなに伝えただけで、「さあどうよ?」って投げだしたわたしのファシリテーションが悪いのですが、遊びを考える以前にいろいろな障壁が明らかになりました。

まず、英語が・・・

 やっぱり英語ですね。さくっと読めない。
 一定量の英文なら多少わからない単語があっても補完できたりするのですが、それぞれが短文なので、一語でもわからないとけっこう厳しい。

 というかですね、文章以前にキーワードの単語自体がわからないこともあるんですよ(恥)。
 たとえば、「感情」カテゴリーの、「TENACIOUS」。  キーワード時点で「いや、何よ?」となると、ゲームの入り口にも立てていないんです。

 なおこの問題はリナさん発案により、Google先生に解決していただきました。  AndroidだとデフォルトでGoogleレンズがついてるんですかね。iPhoneの場合はGoogle翻訳でこれができます。まあ翻訳の精度はいまいちですが、ざっくりわかる。

f:id:kz_suzuki:20200802212023j:plain

キーワードも思いのほかわからない

 100枚あるといっても、テストに関係するトピックなんだから、だいたいはわかるべ!とか油断していると、「パターン」カテゴリーの「IKEA-EFFECT」(IKEA効果)が出てくる。聞いたことある気がするけれど、わからない。
 英語を乗り越えても、次に知識不足にやられる感じです。

 ちなみにIKEA効果とは。

自分が作ったものや関与したプロジェクトに対して、その価値を過大評価する心理効果のこと。 人は手間をかけることで思いや愛着が強まり、自分のみならず他人にとっても高い価値を持つものと錯覚する効果がある。
イケア効果とは 意味/解説 - シマウマ用語集

 なるほどなるほど。
 このカードが属するサブカテゴリーは「Bias」で、心理学的バイアスについてのキーワードがたくさん出てきます。確かにテストにおいては必要な知識ですね。
 ですが、普通に知らないキーワードだらけです。まあこれは、お勉強の一つと捉えればいいでしょう!

カテゴリーに違和感

 「技法」カテゴリーの一つに、たとえば「PAIRWISE TESTING」(ペアワイズテスト)があります。これすんなり来ますよね。
 一方で、「CHARM」(魅力)。魅力? 魅力が、技法? 「KNOWLEDGE」(知識)が、技法?
 これは、カテゴリー「TECHNIQUES」を暗黙の裡に「テスト設計技法」と解釈している自分たちが狭いということで、日本語でいう「テクニック」と理解した方が自然かもしれません。

 「テクニック」には実は3つのサブカテゴリーに分かれています。「プロダクトレベル」「プロジェクトレベル」「個人レベル」。
 プロダクトレベルにはいわるゆテスト設計技法的なものが並んでいます。「個人レベル」は、コミュニケーション能力的な個人の技術が。また「プロジェクトレベル」には、「ペアテスト」「要求工学」といった、それ以外の技術が並んでいます。
 カテゴライズにちょいと癖があるので「ぬ?」となりがちなのですが、それを解釈するのも楽しみの一つです。

 要は、「どんなカードがあって、どんなことが書かれているか」をみんながある程度知らないと、なかなか遊びづらいということですね。
 ということもあって、まずはみんなで、100枚を一通り読んでみました。理解できなさそうなものはさっと飛ばして。すると、各カテゴリーの意味しているところがぼんやりとわかってきて、「まあ、遊べそうかも」という雰囲気になってきます。

どんな遊び方ができるのか?

キーワードを推測するゲーム

 まず、アナログゲームに詳しいオムそばさんからは、「キーワードは隠しておいて、カードに提示された3つの例からキーワードを推定する」という形に基づく遊び方を、2種類していただきました。発想から形にするまでの速度が速すぎる・・・。
 課題としては、(キーワードなどを隠す関係上)物理カードで遊ぶのは難しいというものがあり、電子化が必要かなあという話になりました。で、そうすると権利関係が・・・という課題も出てきてしまいます。物理でも、ちょっと工夫してうまくやれないかな?

「ダウト」っぽいゲーム

 嘘をつく人とそれを見破る人に分かれるゲームです。
 カードを数枚ランダムに選んで、嘘をつく人は「それぞれのカードのキーワードに対し知識や経験を有しているていで」説明する。見破る人は、どれが真実でどれが嘘かを見破る、というものです。
 あるいはゲームにしなくても、キーワードについて「できる」「できない」、「知ってる」「知らない」を話すことで、メンバーがどんなスキルを持っているかの理解にもつながるかなと。

感情の起伏を語る場

 「感情」カテゴリーには、さまざまな感情のカードがあります。この中から、プロジェクト当初に感じていた感情、途中段階での感情、現時点での感情を選んで、なぜそのような変化が起こったかをふりかえりの場などで語る。というものです。ゲームというよりは、コミュニケーションですね。

 また、たとえば「COMFORTABLE」は positive feeling のサブカテゴリーに入っていますが、「comfortable zone」というフレーズの中では negative な意味にもなりえます。それぞれの感情は本当に positive / negative なのか、という観点で意見を交わすのも面白いのではないか、という話をしました。

オーソドックスなゲーム

 1枚めくって、そのキーワード(または三つの例の中のどれか)に絡むエピソードを語る、というものです。
 これは一番直観的でシンプルな使い方だと思います。キーワードを知らなければスキップしてもいいですし、わかる人が教えてもいいですし、みんなわからなければ調べて「あーーー」となるのも楽しい。

 ただこれだと、カードの枚数100枚で同じエピソードになってしまいがち。中級者(何の?)は2つのカテゴリーからそれぞれ1枚ずつをめくって、その2枚の両方の要素を含んだエピソードを語る。これだと、5C2 *20 *20 = 4000パターン(たぶん)になるので、同じパターンが出ることは少なくなるでしょう。

 昨日わたしが引いたのは、探索的テストにおける「TOURING」(ツアー、「テクニック」カテゴリー)と、上述の「COMFORTABLE」(快適、「感情」カテゴリー)です。
 なお「探索的テストツアー」については、以下で記事を書きました。

www.kzsuzuki.com

 探索的テストの実行について以前N社のKさんから「探索的テストをあまり自由にやってもらうと、過去にバグを見つけたときのパターンばかりがんばって、それ以外のことをやらなくなる」というお話を聞いたこともあり、「過去にうまくいっていた快適なやり方を抜け出すために、探索的テストにおける攻め方を分類したツアーって役に立つよね」というお話をしました。まあこれは偶然、うまいエピソードを見つけられましたが、なかなか難しいかもしれませんね。

前の人から話をつなげていく

 こちらは、カード自体は1枚なのですが、代わりに「前の人のエピソードから何か1つ言葉を拾って、その言葉とカードを組み合わせたエピソードを語る」という形です。例を説明したいんだけれど、自分の回答を忘れてしまった・・・。
 2枚引きより自由度が上がりつつ、話がつながっていくということで少しゲーム性もあり。個人的にはこれが一番面白かったですね。

さあ、やってみよう!

 ということで、ちょいハードルはあるけれど、けっこう遊べるんじゃないかなという。

 実際、こんな感じです。まあ、慣れは必要ですね!

 ということで、TestSphereで遊んでみたい方、声かけてください~。5~6人集まったら遊びましょう。流れがきたら日本語化プロジェクトやるか!

TestSphereというカードデッキを買ってみたので、みんなで遊び方を考えよう!

 TestSphereというカードデッキを買ってみましたので、紹介します。
 遊び方を考えたいので、みなさんご協力ください。

f:id:kz_suzuki:20200726153507j:plain
一瞬、ちょい箱ボロいな!?と思ってしまった
f:id:kz_suzuki:20200726153429j:plain
中はちゃんと包装されていた

TestSphereとは

 Ministry of Testingというサイトが開発した、ソフトウェアテストに関するカードゲームのようなものです。

この記事の目的

 TestSphereの紹介ではあるのですが、これを使ってどう遊ぼうか(特にオンラインで!)を考えたいので、みなさん手伝ってください。
 以下の「なぜ、TestSphereを作ったのか」は、公式ページ(https://www.ministryoftesting.com/testsphere)からの翻訳です。

<翻訳> なぜ、TestSphereを作ったのか

 ソフトウェア開発の世界は進化しています。わたしたちは日々、早期のテストを行い、「シフトライト」「シフトレフト」し、かつてよりさらに深く掘り進んで、自動テストを賢く利用しながら、チーム全体が品質にフォーカスしています。
 スクラムチームの中にテストを根付かせたり、アジャイルプラクティスを通して、わたしたちの仕事はずいぶんとよくなっていることがわかります。

アジャイルチームの一員としてのテスター

 テスターは開発の一部です。チームの中で、すぐそばに座っていて、すべてのことをテストします。しかしこれには課題があります。テストの専門家が、様々なチームに分散されているということです。これはつまり、別のロールの人たちとはよく交流できる一方で、話のできるテスター同士の連帯意識を感じることが難しくなっているのです。

孤独なテスター

 チームの中で唯一のテスターにななってしまうことがあるというのが、テスターが直面するもう一つの課題です。作る側のマインドセットにじわじわと吸収されてしまい、テストが浅すぎるものになってしまうこともあります。また、テストを行っている同僚と共有できたはずのナレッジを失い、テストの新しい考え方や直観のひらめきから遠ざかってしまう危険性もあります。
 このような課題に取り組むために、TestSphereは開発されました。

中に入っているもの

 TestSphereのカードパックには、5つのカテゴリーに分けられるカードが100枚入っています。

  1. ヒューリスティックス: 問題に取り組むために考えられる方法
  2. 技法: ありうる問題を見つけるためにテストに用いている賢いアクティビティ
  3. 感情: テストを行うことで引き起こされる感情は何であれ、事実として取り扱われるべき
  4. 品質の側面: 対象のアプリケーションについて、着目するかもしれない側面として考えられるもの
  5. パターン: テストにおけるパターン。ただし、テストにおけるバイアスのように、負の意味をもつパターンも含む

 5つの次元についてそれぞれ20枚のカードがあり、カードがそれぞれテストのコンセプトを紹介しており、各3つの例がそれらのコンセプトに別々の光を当てています
 テストのアイデアを引き出し、話し、学ぶための100枚のカードと300の例というわけです。

(翻訳終わり)

現物はこんな感じ

 5つのカテゴリーごとに、現物を1枚ずつ見てみましょう。

紫 - 感情

 たとえば「ANGER (怒り)」についてはこのような内容になっています。

f:id:kz_suzuki:20200726153440j:plain
ANGER

怒り - ネガティブな感情:
人の気を昂らせるものはたくさんあります。怒りは不合理で、人を冷淡にさせることもあれば、改善のモチベーションになることもあります。

  1. 多額の投資を受けたプロジェクトで長期にわたって働いていると、人はとても感情的になってしまうことがある。彼らのストレスを発散させるには、どのような方法があるだろうか?
  2. あなたとプログラマーは、ディスカッション、拒否されたバグやフィーチャなど、いたるところで激しく言い争っている。
  3. 必要な時にしょっちゅう壊れたり落ちたりしてしまう環境に、あなたはうんざりしている。二度とそれが起きないように、今回はしっかりと対策を用意しておかないといけない。

緑 - 技法

 「ABテスト」の例。

f:id:kz_suzuki:20200726153446j:plain
A/B TESTING

ABテスト - プロジェクトレベル:
1つのコンセプトを、別の方法で行ってみるもの。両方を評価し、ベストのものを選ぶ。マーケティングでよく行われます。

  1. ある企業は、2種類の人のサンプルに対し2つの異なるメールを送る。そしてキャンペーンでは、もっとも反応の良かったものを使う。
  2. 新しいフィーチャーについて、異なるコンセプトに基づく2つ以上ののモックアップを作る。そして、ユーザからの反応がいちばんよかったものを使う。
  3. テストのミッションを達成するために、2つの戦略を提示する。チームやステークホルダーと議論し、彼らの興味をもっともひくものを選ぶ。

赤 - ヒューリスティック

 「説明可能性」の例。

f:id:kz_suzuki:20200726153453j:plain
EXPLAINABILITY

説明可能性 - 一貫性のヒューリスティック:
説明の難しいプロダクトは、ユーザにとって、理解がそうとう難しいかもしれません。

  1. FAQはドキュメンテーションより長くないだろうか。だとすると、アプリが説明困難なものである可能性がある。
  2. あるややこしい振る舞いについて説明してみよう。説明のために妙なモデル、コンセプト、スキームを持ち出さなくてはならないとしたら、その機能自体がうまくなじんでいないのかもしれない。
  3. 製品は、ツールチップやヘルプ機能を提供しているか? それは実際どう役に立っているか?

青 - 品質の側面

 「テスタビリティ」の例。

f:id:kz_suzuki:20200726153457j:plain
TESTABILITY

テスタビリティ - 保守性の側面:
あなたのテストの作業がどれだけ容易か、あるいは困難かに影響を与えるあらゆるものを指します。

  1. ゲームをより簡単にテストする方法として、しばしば「チートコード」というものがある。「最強」の状態をテストしたければ、上上下下左右左右BA、スタート、セレクト」*1を入力するとか。ただこれはショートカットだということを忘れないように!
  2. テストのための環境は十分か? その環境を何に使う? チームメンバー全員に、それが明らかになっているか?
  3. ある特定の時刻にして発生しない機能をテストするために、システムの時刻を操作できるか?

オレンジ - パターン

 「自動化」の例。

f:id:kz_suzuki:20200726153502j:plain
AUTOMATION

自動化 - アプローチ:
ロボット。心や頭脳は持っていませんが、迅速に、素晴らしい計算をこなすことができます。

  1. 同じことを50個同時に実行することのできる、性能テスト用のスクリプト。ベースラインを定めて、耐久性を設定しておくことで、結果を分析するのに役立つ。
  2. 退屈なチェック作業をしなくてはならない? 自動化して時間を作り、新しく面白いテストをしよう。
  3. ロボットは、何かをモニターするのが得意。あなたが働いている時間、寝ている時間、食べている時間、人生を楽しんでいる時間に、トラブルがないか調べてもらおう。

 このようなカードが、全部で100枚あるわけです。けっこう分厚い。

使い方の紹介

 使い方の例を、公式サイトからのかいつまんでみましょう。

1. ナレッジの共有

 引いたカードをトリガーにして、テストに関する話や経験などを話す。

2. リスクストーミング

 プロダクトやプロジェクトについての重大なリスクを洗い出すために使う。

3. TestSphereアリーナ

 基本デッキに拡張パックを追加して、UNO風のゲームに仕立て上げたもの。カードを捨てる際に、そのカードと直前のカードを関連付けるストーリーを話すというゲーム。

4. スプリントプランニング

 カードをベースにして、計画対象のストーリーに対してテストすべきことを考えていく。

5. レトロスペクティブ

 「感じたこと」が置き去りになりがちなレトロでカードを使うことで、人間としての側面も見せられるようになる。

6. インスピレーション

 テストはアートのようなもの。TestSphereを使って、次のテストに向けたインスピレーションを得る、

 また、使い方などが書かれたカードには、「アイスブレイカー」としてこんなことが書かれています。

  1. 孤独なテスターを見つける
  2. 彼らのところに歩いていって、無作為にカードを1枚引く。たとえば「同値分割」。
  3. そのテスターに、「同値分割について、何か話題や経験を教えてくれないか」と尋ねる。

 いや、どんな強メンタルだよ・・・そんなやついるかよ・・・と思いますが。。。

 「ゲーム」はこう。

  1. テスターを集めてグループを作る
  2. デッキをカテゴリーで分ける
  3. 1枚(もしくはもっと)カードをめくる
  4. めくられたすべてのカードに関して紹介できるようなストーリーを考えて、できるだけ早く宣言する
  5. 最初にストーリーを話せた人がカードをとる これを一定時間行って、最後に一番多くカードをもっていた人の勝ち

 前述の「TestSphereアリーナ」を追加してのゲームもそうなんですけれど、「速さを競う」はオンラインと相性悪そうですよね。なので、集まった人が順番になんかしゃべるようなやつにできないもんかなと。

 「ソフトウェアの品質を学びまくる」では、TestSphereで一緒に遊んでくれる人を募集しています!

*1:コナミコマンドというもののようですね。