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

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

なわとびから考える情報の仕分けとソフトウェアテスト

 レビューの難しさの一つに、「レビューする側とされる側で、感じる重みにギャップのある指摘」問題があります。
 特に、「レビューする側は大事な問題だと思っているのだけれど、される側はそう思っていない」ものが厄介です。このような場合、される側は「そんな重箱をつつくようなことを言わなくても・・」と感じているので、小手先の修正に終わってしまい、次回もまた同じことをやってしまいがち。

 その種の指摘の例として、「列のタイトルとデータが整合していない表」があります。

 「いやそんなことある?」って思われるかもしれませんが、「最初に列タイトルをつけてからデータを入れていったところ、タイトルとあまり関係ない情報も出てきた、でも列を分けなかった」みたいなものはちょいちょい見かけます。この手の表は、書き手が思っている以上に、読み解きの難易度が上がると感じます。

 ちょっと例がアレですが、イメージはこんな感じ。

メトリクス 計算式
テストケース密度 テストケース数 / 開発規模
欠陥密度 欠陥数 / 開発規模
※n件/ks以上を目標値とする

 「計算式」の列に、計算式以外の情報を入れんでくれ~
 目標値を書きたいなら、「目標値」って列を作ってくれ~

 でふと思ったのですが、「たくさんの情報があるときに、それを仕分けして、適切な列名を定めて表に落とし込む」って、実はそこまで簡単なことではないんだよなと。

突然のなわとび

ということで今日は、「情報の仕分け」を考えてみましょう。お題はこれです!

ジャーン

 これはわたしの次男が学校からもらってきた、「なわとびけんてい」の表。各「種目」で何回飛べたかに応じて色塗りをしていくことで、自身の成果と成長を見える化する、素敵なプリントです。

 この表自体に特に問題があるわけではない(ただし通番と種目の列は分けてほしい、通番の数字は半角にしてほしい、数字は右揃えにしてほしい)のですが、種目を眺めていると、「なわとびの種目は、いろんな概念が組み合わせられている」と感じませんか? これを紐解いていきましょう。なわとびだけに。

1. 要素に分解する

 名前からしてすでに組み合わせが発生している種目を、要素に分解していきます。

  • 前とび → 前
  • かけ足とび → かけ足
  • 後ろとび → 後ろ
  • あやとび(前) → あや × 前
  • 交差とび(前) → 交差 × 前
  • かけ足あやとび → かけ足 × あや
  • あやとび(後ろ) → あや × 後ろ
  • かけ足交差とび → かけ足 × 交差
  • 前ふりとび → 前ふり
  • 交差とび(後ろ) → 交差 × 後ろ
  • 二重とび → 二重
  • 二重とび(後ろ) → 二重 × 後ろ
  • あや二重とび → あや × 二重
  • 交差二重とび → 交差 × 二重
  • 三重とび → 三重

 以下のような要素がそろいました。意外に少ないですね。

前、かけ足、後ろ、あや、交差、前ふり、二重、三重

2. 要素を仕分けする

 集まった要素を仕分けて、カテゴリーにしていきます。
 仕分けの一つの手がかりとして、「似ているもの」があります。たとえば「前」と「後ろ」は真逆ですが、「回転の方向」を語っているという意味で似ています。

 結果として、以下の4つのカテゴリーとなります。

  • 回転の方向: 前、後ろ
  • 足の動き: かけ足、前ふり
  • 腕の動き: あや、交差
  • 回転の回数: 二重、三重

 表の話に戻ると、「回転の方向」などのカテゴリーが列名となり、「前」「後ろ」といった要素がデータの種類になります。

3. 要素の過不足をチェックする

 さて、要素はこれで十分でしょうか?
 いいえ、足りていないものがありますね。最初の「仕分け」は名前を元に行ったので、名前に明示的に現れない要素が抜けているのです。たとえば「足の動き」は「ノーマル」、つまり単純にジャンプ→着地するものがありますよね。

 これらを加えると、以下のようになります。

  • 回転の方向: 前、後ろ
  • 足の動き: ノーマル、かけ足、前ふり
  • 腕の動き: ノーマル、あや、交差
  • 回転の回数: 一重、二重、三重

 以上の要素を組み合わせることで、最初の種目すべてを表現できるようになりました。

# 種目 回転の方向 足の動き 腕の動き 回転の回数
10 交差とび(後ろ) 後ろ ノーマル 交差 一重
01 前とび ノーマル ノーマル 一重
16 さいきょう 後ろ 前ふり 交差 三重

 いや~ このように整理できると気持ちがいいですね! ぼくの考えたさいきょうのなわとび種目もすぐ作れるわけです。

4. 新しい要素を考えてみる

 さて、この整理をすると、もう少しできることがあります。

 確かに、最初に提示した種目はこれですべてカバーできるのですが、各列に足せる要素はないでしょうか?
 そうですねー、たとえば「腕の動き」。
 あやとびではジャンプのたびに腕の交差と解放を繰り返しますが、「1回のジャンプで交差と開放をする”ダブルあや”ができないか?」みたいな感じです。
 これは、「腕の動き」というカテゴリーで列名が付いていることにより、考えやすくなっています。

 「回転の回数」なら、単純には「四重」が考えられますし、「1回ごとに回転の回数が変わる飛び方」というのも発想できるかもしれません。

5. 新しいカテゴリーを考えてみる

 さらに、カテゴリーに何か追加できないか考えてみます。
 「足の動きと腕の動きがあるから・・・腰の動きってどうだ? ジャンプごとに、腰を左右に捻る!これは腹筋に効くぜ・・・!」みたいに。

 これも、カテゴリーの名前が適切に付けられていることが、発想の源となります。

おわりに

 最初の話からだいぶズレてきました。

最初に言いたかったこと

 表を作るなら、列名とデータの内容を整合させよう。

今言いたいこと

 適切なカテゴリー名を付けて分類することは、要素だけでなく、そもそもの分類の軸であるカテゴリーの過不足を検討するためにも、とっても大事なプロセスである。

 QAエンジニアの方なら、「何か、デシジョンテーブルテストとか組み合わせテストやるときに似てるな」と感じたかもしれません。
 その通りです! これらの表を作る時も、軸と選択肢の洗い出しと仕分けが重要なんですよね。実は最初は「なわとび直交表」を作ろうと思ったのですが、いつの間にか全然違う話になってしまいました。

 無理やりテストの話に持ち込んだところで、今日の雑談は以上です。今年の目標「三重とびをマスターする」を掲げて、今日も練習してきます。

Generated By Dalle

2023年後半に読んで特によかった本

2024年になりました。新年、あけましておめでとうございます!
2023年の後半に読んだ本を振り返って、よかったな~と思うものを記録しておきます。

ソフトウェア開発

システム障害対応の教科書

ITシステムの障害対応は、「有期であり」「ユニークである」という特徴を考えると、プロジェクトの一種として捉えることができます。しかし、通常のプロジェクトと大きな違う点があります。それは、「納期が、”とにかくできるだけ早く”である」という点です。
この性質のために、中堅が若手に「じっくり教える」「やらせてみる、失敗も経験させる」というトレーニングが難しい。また皮肉なことに、安定しているシステムであればあるほど、システム障害を経験する場には恵まれないという逆説的な状況になります。

では、徒手空拳で体当たりするのか。それでは、「プロジェクト成功」は望めませんよね。 『システム障害対応の教科書』では、大きな障害が起きた時にどのように対応すべきかを広く説明しています。

広く、といっても、当たり障りのない表面的な情報の羅列ではありません。
たとえば、「事態が終息したら、顧客にも対応メンバーにも明確に宣言して解散する」といった地味ながら大事な話が、しっかりと書かれています。
リーダーの中では終息していても、その感覚は意外に、個々のメンバーには伝わっていないもの。リモートワークならなおさらです。そしてメンバーからは「もう終わりでいいですか? 寝たいです」なんて言いづらい。リーダーや他の人が言い出すのを、ひたすら待っていたりするんですよね。

このような、ある意味小さな、でも重要なことも含めて、ノウハウが詰め込まれています。システム障害の現場での深い経験を持ち、多くの成功と失敗をしてきたのであろう人だからこそ書ける、良書だと思います。

プロジェクトのトラブル解決大全

『システム障害対応の教科書』がOperationに当たるとすると、Developmentのトラブルにはどう対処すべきでしょうか。
『プロジェクトのトラブル解決大全』があります。

このところ、「大全」という言葉がマーケティング目的で付けられているようで敬遠しているのですが、この本はとても好きです。
一歩間違えたら「根性論」「昭和」「ブラック」と指弾されてもおかしくないことを、恐れずにしっかり書いている。トラブル解決は、そのくらい大変なんですよね。

この本が教えてくれることを3つ挙げるとすると、以下です。

1. 炎上プロジェクトは、平和なプロジェクトの延長線上にある

著者自身が書かれていることですが、本書で説明されていることの多くが、炎上「前」からやっておくべきことです。炎上してから急に必要になるスキルがたくさんあるのではなく、そもそも炎上させないようにするスキルが、炎上の現場ではより強く求められるということなんですよね。

平和なプロジェクトに、ポツポツとボヤが起こり始め、それを放置すると本格的な炎上になる。その前に、小さなボヤを、ボヤのまま鎮火するためのスキルが、本書には書かれています。

2. 根性論・精神論と言われようとも、「腹をくくる」のが第一歩である

本書で説明される「火消術」は、進捗管理やプロジェクト管理といった、ある意味ペーパーワーク的なものだけではありません。人と、その気持ちありきです。炎上プロジェクトに関わる人たちの中に飛び込み、協力をとりつけ、モチベーションを平常レベルに戻す。そのために何ができるかということが、事細かに説明されています。

3. リーダーのゴールは、メンバーに好かれることではない

リーダーも人間ですから、できればメンバーと仲良くなり、明るい雰囲気で仕事がしたいもの。「好かれたい」「嫌われたくない」という気持ちはどうしても消せない。でも、それだけでは炎上プロジェクトは(そして普通のプロジェクトも)うまくは回らないんですよね。

終盤に書かれた以下の言葉も、とても身に沁みます。

いくつもの炎上プロジェクトを経験してきて私が思っているのは、
・ミラクルはない
・飛び道具はない
・地味なことを地道にやるしかない

社会

軌道

今年は「失敗」についての本を何冊か読んだのですが、その過程でお勧めいただいた本です。

JR福知山線の事故を、組織の問題ではなく個人の問題であるとし、企業の責任を認めようとしないJR西日本。一方、個人や会社の誰かを罰するためではなく、二度と同じことが起こらないようにするために「何が起きたのか」「何が原因だったのか」を突き止めようとする遺族。意見の相違ではなく、目標とするところがまったく食い違っている中で、「根本原因の究明」「再発防止策の特定」のために粘り強く戦う姿が描かれています。

正直、読んでいてとても苦しくなる場面もあれば、胸が悪くなるような描写もあります。遺族の心情を追体験させられているようで、読んでいてしんどいものがあります。
それでも、結果や成果だけを情報としてキレイに整理して渡されても、組織に文化を、中でも「失敗を教訓として生かす文化」を定着させることの本当に難しさは、その断片すら理解できないのではないかと思います。

失敗の科学

失敗の科学

失敗の科学

Amazon

「失敗」全般を学ぶ本としては、なぜ失敗が起こるのか、その失敗をなぜ生かせないのかについての幅広い研究をまとめた、『失敗の科学』をお勧めします。
面白い見解やエピソードが満載なのですが、たとえば第4章は、人がミスを認めない理由について扱っています。

「ミスを認めない」というと、その人の不誠実さだったり不勉強に起因するものと思ってしまいがちなのですが、そもそも人間には「最初に信じていた意見から離れることが難しい」という性質があるそうです。
無実の人間に対して、有罪と信じた司法長官が、「無実の容疑者は少ない。無実なら、そもそも容疑者にはならない。よって容疑者は有罪だ」という無茶苦茶な論理を押し通そうとする例や、大洪水の予言を外したカルト教祖に対し、信者の信仰がより深まる例などが紹介されています。

失敗の性質について広く学びたい方は、ぜひ。

学問

言語沼

わたし、専門外の学問を一般の人向けにおいしく味付けしてくれたような本に弱いです。
実際の言語学(というか学問全般)は地味で地道な仕事・調査の連続なんだろうけれど、『言語沼』その一番おいしい上澄みのところを堪能できます。

特に気に入ったのは、第6章の格助詞ネタです。

  • 「平和な現代を生きる」
  • 「平和な現代に生きる」

この2つを比べると、後者の方がしっくりこないでしょうか? 一方で

  • 「食うか食われるかの乱世を生きる」
  • 「食うか食われるかの乱世に生きる」

だと、前者の方がしっくりきませんか?
一体どのように説明できるのか、気になる方はぜひ本書を! 素晴らしく面白いです。

なお同じ言語学関連で、ネタも若干かぶるのですが、『なぜ、おかしの名前はパピプペポが多いのか?』は小学生向けの説明のためにポケモンやプリキュアを題材にしている点で、別の面白さがあります。

文学

茨木のり子詩集

すべての作品が大好きというわけではないのだけれど、ハッとさせられる力強い言葉が多いです。何となく、生きることが惰性になってしまっているこの歳だからこそ、読んでよかったなと感じます。

異色なのは、先に亡くなった夫への気持ちを綴った詩集、『歳月』からの歳月。他の詩集はどちらかというと、「強い女」としての茨木を感じるのですが、『歳月』だけは「夫の対となる妻」としての茨木なんですよね。
胸に迫るものがある詩が多く、詩集自体がほしいのですが、新品は出回っておらず、中古でも5,000円近くするのですね・・・。

ビジネス

採用基準

採用基準

採用基準

Amazon

湯本剛さんが講演で言及したこともあり、QA界隈で俄かに人気が急上昇した『採用基準』。

たしかに採用についての本ではあるのだけれど、軸にあるテーマは「リーダーシップ」だと思います。
企業面接で「あなたがリーダーシップを発揮した場面を教えてください」ってありがちで、あまり好きではなかったのですが、なぜそれを企業が求めるか少し理解できたように思います。

「リーダーシップとは、一握りのカリスマだけでなく、構成員みんなが具えているべき能力である」というのが主張の根幹。「これは自分の役割ではない」と「役割」にこだわって、文句だけ言っているような人ばかりだと、成功にはおぼつかないと断じています。

卑近な例がすごくわかりやすいです。
会議で持ち寄ったお菓子が多少余った時に、「お子さんのいるご家庭など、持ち帰りたい方はいますか?」と提案したり、タクシー待ちの長い行列で「同じ方向の方乗り合いしません?」と声を上げたりすること。これがリーダーシップ。

こんなのリーダーでも何でもないと感じるでしょうか?
「なるほど」となった方にも、「え?」となった方にも、ぜひ読んでいただきたい本です。

フィクション

三体0【ゼロ】 球状閃電

三体3部作のメインキャラである科学者の若い頃を描いたもの。本編がすでに完結しているだけに、そこまで期待していなかったのが正直なところですが・・・
魅力的なガジェットが全編を通して主題になっているとともに、本編にしっかりつながる伏線。「その話につながるのか! やられた!」となりました。
SFの一番おいしいところを堪能できる作品だと思います。

また、分厚いSFなのに読みやすい。原著者の文体と翻訳者のなせる業ですね。ありがたいことです。

ダーウィンズゲーム

スマホに突然届く「ダーウィンズ・ゲーム」の招待状。高校生・カナメは、わけもわからぬまま異能バトルに巻き込まれていく・・・というあまりにド定番な導入
異能バトルモノに弱いわたしは、主人公補正の強さや能力のバランスの悪さを感じながらが淡々と読み進めていたのですが・・・、途中から様子が変わってきて、後半から「え? これこういう展開になるの!?」となっていきます。

2023年の秋に完結したようですが、まだ読み終わってません! 残りを読むのが楽しみです。
やっぱり、異能バトルものには男子の夢が詰まっているよ。

おわりに

2023年もけっこういろんな本を読んだなーと思いますが、やっぱりどこかで視野が狭められているんだろうなと思います。
突拍子もないところから本を勧めてくれるサービスとかあったら楽しそうですね~。
今年も読書を楽しみます!

Generated By Dalle

ChatGPTで、語幹から英単語を辿り続けるチャットボットを作ってみた

作ったもの

語幹を元に、英単語を辿り続けるチャットボット「ミキータ」です*1

https://chat.openai.com/g/g-fqzH1mgRr-mikita2

できることは、以下の3つだけです。

  1. 英単語を指定すると、その単語の意味を説明したうえで、語幹に分解して提示してくれます。
  2. 提示された語幹の1つを選ぶと、その語幹を含む英単語を3つ提示してくれます。
  3. 提示された英単語の1つを選ぶと、1.と同じことをしてくれます。

使用例

カバは漢字で書くと「河馬」、英語のhippopotamus「河の馬」を表すという素晴らしい知識を持っているため、最初に「hippopotamus」を指定してみます。

hippopotamus

すると・・・

English Word

Hippopotamus

Meaning

カバ

Information

カバは、主にアフリカの河川や湖に生息する大型の陸生哺乳類です。驚くべきことに、カバは馬に近い関係にあります。彼らは水中での生活に適応しており、その巨体にもかかわらず、優れた泳ぎ手です。

Stems

  1. Hippo- : 「馬」を意味する
  2. potamus : 「川」を意味する

語幹に分解してくれました。

では、「potamus」という語幹を含む英単語を調べてみましょう。「2」を入力します。
ちなみにわたしは、Mesopotamiaがその例であり、「2つの川の間の土地」を意味するという素晴らしい知識を持っています。

Examples of English Words Containing -potamus

  1. Hippopotamus ◦ カバ
  2. Potamology ◦ 河川学
  3. Potamophile ◦ 河川を好むこと

1はさっそく最初の単語とかぶってしまいましたが、2と3になかなかマニアックな単語が出てきました。ただ、potamusを知っていれば、実は3のpotamophileの意味は想像できてしまいます。
「3」を入力します。

English Word

Potamophile

Meaning

河川を好むこと

Information

「Potamophile」は一般的に使用される単語ではありませんが、ギリシャ語の「potamos」(川)と「phile」(愛好家)から派生しています。河川や流れる水に対して強い好みや関心を持つ人や動物を指すことがあります。

Stems

  1. Potamo- : 「川」を意味する
  2. phile : 「好きな、愛好する」という意味の接尾語

そう、philは、「好き」「愛」って意味なんですよね。
この語幹を含む単語は・・。

Examples of English Words Containing -phile

  1. Bibliophile ◦ 本好き、書物愛好家
  2. Audiophile ◦ 音響機器や音質にこだわりを持つ人
  3. Francophile ◦ フランスやフランス文化を愛好する人

あれ・・・、philosophyとかphilharmonyとかが出てきてほしかったんだけど、マニアックな単語になってしまった・・・。
英単語のレベルは追加指示でコントロールできそうですが、「聞いたこともない」単語が出てきた方が面白いんじゃないかな。

まあ、こんな感じのものです! ダラダラつなげていると、「え、そんなつながりあったの?」って出会いがあったりします。

作ってみて

GPTsの使い方をちゃんと勉強せず、Trial & Errorで作ってみたうえでの感想です。

所要時間

  • メインの動きの部分: 30分
  • 微調整の繰り返し: その後ダラダラ

わかったこと(推測)

  • こちらが指示を与えると、ChatGPTは裏でそれをInstructionsとして最適化する。この際、こちらが言っていないことも勝手に補足している。 指示を追加すると、Instructionsに反映され、最適化される。
  • 差分で指示を与える形になるので、最初の方の指示が亡きものにされていたりする。毎回全文指示した方がいいんじゃないか?と感じる。
  • いずれにせよ、情報をテキストで単純に扱うだけのツールなら、ものすごく簡単にできてしまう

よくわからないこと

  • こちらが構造化された形で指示を与えても、ChatGPTの中での解釈が同じ構造になるわけではない(っぽい)。なので、Instructionsを直接編集しようとすると戸惑う。
  • 過去のレスポンスをうまく変数として扱うのが難しい。「1つ前」のレスポンスだけを見てほしいのに、それより前のレスポンスを参照して想定外の動きをすることがある。
  • レスポンスの形式を指定する方法に習熟が必要。日本語にしてほしい部分が英語になっていたりする。「毎回のレスポンスにこういうメッセージを入れてほしい」みたいな固定値の指定方法もよくわからない。
  • 指示のスコープが意図通りにならないことがある。たとえば

(1)3つの情報A、B、Cを出力して

と指示した後に、

(2)情報Cは英語で出力して

と指示すると、情報C「だけを」英語で出力して、情報A・Bを出力「しない」動きになったりする。

感じたこと

次のポストで書きます。

Generated By Dalle

*1:最初に公開した「ミキータ」は、改良をしていたつもりが次第にまともに動かなくなり、最終的にはこちらの指示が全部エラーになってしまいました・・・。あらためて「2」を作ったのでした。

「シナリオテスト」とは一体、何なのか - その6・ユースケーステストのカバレッジ

「その6」は、3年以上前のこちらです。 www.kzsuzuki.com


Twitterで交わされていた「ユースケーステストのテストカバレッジ」という言葉が気になったので、考えてみました。

もしかすると、同じようなこと(というかもっと優れたこと)を言っている文献があるかもしれませんが、調べていません! 議論のきっかけになり、ついでに良い資料なども知ることができればなと他力本願です。

またこの記事では、ユースケース、パス、シナリオ、フローといった言葉を、きっちり定義・区別していない点にも注意してください(開き直っている)。
用語定義の考え方については、以下のスライドが1つの提案として面白いです。

www.slideshare.net

ユースケーステストの定義

おなじみ、JSTQBのテストアナリストシラバスから引用してみます。

3.2.7 ユースケーステスト
ユースケーステストは、ユースケースで具体的にした、コンポーネントまたはシステムの意図される使われ方をエミュレートするトランザクションベースおよびシナリオベースのテストを可能にする。何らかのゴールを達成するために、アクターと、コンポーネントまたはシステムとの間の相互作用の観点でユースケースを定義する。アクターとしては、ユーザー、外部ハードウェア、またはその他のコンポーネントやシステムを挙げることができる。

正直、文章で理解するのは困難ですね・・・。
まず、ユースケースから押さえていきましょう。

ユースケース

『UMLモデリング入門』では、「ユースケース」を以下のように定義しています*1

アクター(行為者)が仕事を遂行するために使用する手段であり、アクターと「システム」との対話として表わしたもの。

ポイントとなるのは、「システムの機能」ではなく、「アクターとシステムの対話」に注目していることです。

次に、『はじめて学ぶソフトウェアのテスト技法』の第9章、「ユースケーステスト」で提示されるユースケース記述の例を見てみます。

ただし説明の都合上、一部を簡略化・改変*2しています。

ユースケースの構成要素 説明
ユースケース名 科目への登録
主アクター 学生
事前条件 なし
成功時の事後条件 学生が当該科目に登録される
失敗時の自己条件 学生が当該科目に登録されない
トリガー 学生が科目を選択し、「登録」する。
主成功シナリオ
 A: アクター
 S: システム
(1)A: 「科目の登録」を選択する
(2)S: 科目の一覧を表示する
(3)A: 科目を選択する
(4)S: 受講可能なクラスを表示する
(5)A: クラスを選択する
(6)S: 選択したクラスの曜日と時間を表示する
(7)A: 受け入れる
(8)S: 科目・クラスを学生の科目リストに追加する
拡張シナリオ (3a) 科目が存在しない
S: メッセージを表示し(2)に戻る
(5a) クラスが存在しない
S: メッセージを表示し(4)に戻る
(5b) クラスが定員いっぱい
S: メッセージを表示し(4)に戻る
(7a) 学生が受け入れない
S: メッセージを表示し(2)に戻る

この例からもわかるように、アクターとシステムの相互作用が表現されています。
また、一番メインと考えられる「主成功シナリオ」に加えて、それ以外の「拡張シナリオ」が記載されています。後者は、サブ的な成功シナリオである「代替シナリオ」や、失敗にぶつかる「例外シナリオ」に分けて記述されることもあります。

これらのシナリオをテストしていくのが、ユースケーステストということになります。
たとえば、主成功シナリオを(1)から(8)まで通すのが、ユースケーステストにおける1つのテストケースと言えます。

ユースケーステストのカバレッジ

では、ユースケーステストのカバレッジを、どのように考えていけばいいでしょうか。
ここでは、2つに分けて考えてみます。1つは、データレベルのカバレッジ。もう1つが、シナリオレベルのカバレッジです。
なお、この辺はわたしの独自定義です。厳密なものではないので、雰囲気で読んでください。

データレベルのカバレッジ

「ある1つのシナリオに対して、必要となるデータセットのうちどれだけが実行できたか」が、データレベルのカバレッジです。

『はじめて学ぶソフトウェアのテスト技法』を再度引いてみます。「カバレッジ」という言葉は直接は出てきませんが、以下のように説明されています。

この実装をテストする基本的なルールは次の通りです。すなわち、主成功シナリオに対して少なくとも1つのテストケースを作成し、拡張のシナリオのそれぞれに少なくとも1つのテストケースを作成することです。

ここで「少なくとも」という言葉が出てくることに注意しましょう。

ユースケースは入力データを規定していないので、テスト担当者がそれを選択する必要があります。通常は、ここまでの章で紹介した同値分割と境界値分析の技法を利用します。

シナリオを、ハイレベルテストケースと考えるとわかりやすいでしょう。主成功シナリオは1本ですが、そのシナリオを通すためのデータのバリエーションは1つではなく、そのバリエーションごとにローレベルテストケースを作成できる、ということになります。

シナリオレベルのカバレッジ

「ある1つのユースケース記述に対して、必要となるテストシナリオのうちどれだけが実行できたか」が、シナリオレベルのカバレッジです。

では、「必要となるテストシナリオ」はどのように定義すればいいでしょうか。

いくつかのレベルに分けて考えていきます。
(3)以降は、コードカバレッジからの連想でユースケーステストのカバレッジ基準を考えた、思考実験に近いものです。コードカバレッジについては以下の記事を参考にしてください。 www.kzsuzuki.com

(1)主成功シナリオ

カバレッジの分母は、主成功シナリオの数です。原則として1個。
もっとも弱いカバレッジ基準と言っていいでしょう。

(2)主成功シナリオ+拡張シナリオ

カバレッジの分母は、主成功シナリオおよび拡張シナリオの数です。今回の例では、主成功1+拡張4で、5個のシナリオが対象になります。
ユースケーステストにおいて、最低限のカバレッジ基準です。
拡張シナリオを代替シナリオと例外シナリオに分けて、基準を区分してもいいかもしれません。

(3)条件判定網羅的なシナリオ

カバレッジの分母は、主成功と拡張の分岐における判定の組み合わせの数です。
わかりづらいですね。具体例で考えましょう。
今回の例をフローチャートにすると以下のようになります。

フローチャート (ChatGPTとAI Diagramsプラグインで生成)

4つの分岐があるので、判定の組み合わせは24=16のパターンがあります。そのうち5つは、(2)ですでにカバーされています。

カバーされていないのはたとえば、「選んだ科目が存在しなかったので戻って科目を選び直し、新しく選んだ科目から選んだクラスが存在しなかったので戻ってクラスを選び直し、そのクラスが満員だったのでさらに別のクラスを選び直し、最後の確認画面で受け入れなかったので最初に戻る」というシナリオです*3
このように、このカバレッジ基準では、「複数の代替パスを通る」ようなシナリオをカバーすることができます。

(4)経路網羅的なシナリオ

カバレッジの分母は、基準とするループ回数の数です。
今回の例ではFOR・WHILE的なループはないのですが、前方に戻るIF文があるので、これをループを見なしましょう。

ループ回数の基準を「2回」と決めたとすると、4つのある分岐でそれぞれ「戻らない」「1回戻る」「2回戻る」シナリオがありうるので、4×3=12のパターンがあります。そのうち8つ*4は、(2)でカバーされています。

カバーされていないのはたとえば、「選んだクラスが満員だったので別のクラスを選んだら、そのクラスも満員だった」というシナリオです。 このように、このカバレッジ基準では、「同じ代替パスを複数回通る」ようなシナリオをカバーすることができます。

(5)さらに複雑なシナリオ

(3)と(4)を組み合わせることで、複雑なシナリオは無数に生成することができるでしょう。
ただ、そのカバレッジを高めても、費用対効果は低そうです。

ユースケーステストは「きれいなシナリオ」?

さて、ここまで見てきたシナリオはどれも、「整理された無駄のないユースケース記述から機械的に導出可能な、きれいなシナリオ」のように思えます。これでシナリオは十分と言えるのでしょうか?

JSTQBシラバスでは、以下のように言っています。

ユースケースは、ガイドラインとしてとらえるべきであるが、要件のセット全体を明確に定義するものではない可能性があるため、テストすべき内容を完全に定義するものとはならない

また秋山浩一さんは、シナリオテストの説明において、このようにおっしゃっています。

上述のユースケース記述の例でも「シナリオ」という言葉が出てきますし、「ユースケースシナリオ」という用語もあったりするのでややこしいのですが、ユースケーステストとシナリオテストは別モノであるとされることが多いように思います。たとえば、以下のTogetter。 togetter.com

以上をまとめると、「ユースケーステストからシナリオを導くことはできるが、シナリオテストで行うべきシナリオとしては不十分」という、面倒な話になります。

Michael Bolton氏の『Scenarios Ain’t Just Use cases』というブログ記事では、Cem Kaner氏の言葉を引いています。翻訳はわたしによるものです。 developsense.com

a scenario test has several characteristics: it is motivating, in that stakeholders would push to fix problems that the test revealed; credible, in that it not only could happen, but that things like it could probably happen; that it involves complexity in terms of use, environments, or data.

シナリオテストにはいくつかの特徴がある。
・そのテストで明らかになった問題は、ステークホルダーも修正を推すだろうと意味で、モチベーションを与える。
・単に「起こる可能性がある」というだけでなく、「おそらく起こるだろう」と言えるという意味で、信頼性がある。
・利用方法、環境、データの観点から、複雑さを有している。

この2点目、3点目に注目してください。氏は、ユースケースから直接得られる「手順1→手順2→手順3→手順4→手順5」のようなものを「シナリオ」と呼ぶのは、シナリオの可能性を狭めているとしています。
では、彼のいう現実世界のシナリオとはいかなるものか。その例が、以下です。

  • do 1
  • start 2
  • respond to one email, and delete a bunch of get-rich-quick offers
  • resume 2
  • take a phone call from the dog grooming studio; Fluffy will be ready at 4:30
  • realize they’ve lost track of what they were doing in 2
  • go back to 1
  • restart 2
  • look up some figures in Excel
  • place a pizza order for the lunchtime meeting
  • finish 2
  • go to 3

(以下略、全56行)

本質的にはたった5つしかない手順なのに、それを達成するためのステップが50以上もあるのです。しかも、「作業中に電話がきて」とか「ピザを注文して」とか、一見システムとは何の関係もありません。が、「おそらく起こるだろう」「複雑な」シナリオと言えるでしょう。
ピザを注文している間に、手順2の画面がタイムアウトしているかもしれません。そこまでの入力は、どうなっているのでしょうか? 何か問題が見つかるかもしれません。でもこのようなシナリオは、単純にユースケース記述をカバーするだけでは出てこないのです。

秋山さんのツイに通じるところのあるこのようなシナリオは、ユースケース記述から論理的に導けるものではないですし、カバレッジを考えることも難しいでしょう。
やはりわたしたちには、シナリオテストを設計するための方法論が必要ということになります(結論)。

Generated By Dalle

*1:なお本書では、ユースケースが非常に多彩な記法があることにも触れています。

*2:たとえばオリジナルでは、拡張シナリオの分岐に入ると「メッセージを表示し終了する」となっていますが、この記事では前の画面に戻るようにしています。

*3:この例では、分岐というよりループ的になっているので、LCSAJの考え方を使った方がいいのかもしれない。

*4:主成功シナリオで4つの「戻らない」をカバーし、4つの拡張シナリオでそれぞれ「1回戻る」をカバーしてる。

共感的テストとは何か

ソフトウェアテストエンジニアの仕事というと、どうにかしてバグを見つけること、つまり「プロダクトをどう壊してみせるか」が重要だと思われがちです。『How to Break Software』という本もあるくらい。

それだけに、テストエンジニアは開発者から、自分の作品を傷つけにくる「破壊者」として敵視されるリスクもあります。JSTQB Foundation Levelのシラバス(の1つ過去のバージョン)には「テストの心理学」という節があり、このように述べられています。

テスト担当者およびテストマネージャーは、欠陥、故障、テスト結果、テストの進捗、リスクの情報を効果的に伝えることができ、同僚と建設的な関係を構築するための優れた対人スキルが必要となる。

いわゆる「コミュ力」は、テストエンジニアにとって重要な資質ですよね。

ただ、この「わたし作る人」「わたし壊す人」という素朴なパラダイムも、少しずつ変わってきているのかもしれません。大きく2つの理由があります。

1つ目は、アジャイル開発の普及により、開発者とテストエンジニア*1の距離がずっと近くなり、テストエンジニアが「開発の後半で現れる人たち」ではなくなってきているという点です。たとえばシラバス(の最新版)には、以下のような記述があります。

テスト担当者、ビジネス側の代表者、開発者は、実例マッピングに一緒に取り組み、ユーザーストーリーを共同で書き、バックログリファインメントセッションにおいて協力し、ユーザーストーリーと関連作業成果物が、定義された基準、例えば「準備完了(Ready)の定義」を満たすことを確認する。

最近は「シフトレフト」という言葉もよく聞かれますが、単に「誰かが作ったものの欠陥を早い段階で見つける」だけではなく、「最初から共に取り組む」という意志が感じられます。

もう1つは、テストエンジニアのミッションが「バグを見つける」こと(だけ)ではなく、「ユーザにとって価値があるかを調べる」ことでもあると考えられるようになってきた点です*2
価値というのを「長所が多いこと」「短所が少ないこと」と雑に分けると、「バグが少ないこと」は後者を語るにすぎません。長所が多いことを、テストの段階になってから調べるのでは遅いので、開発の最初の段階から一緒に入っていくわけですよね。

では、テストの段階では何ができるでしょうか。

「共感的テスト」(Sympathetic Testing)というアイデアが、この記事で紹介されています*3

www.satisfice.com

この記事によると「共感的テスト」とは、プロダクトの価値を理解するために、(プロダクトに挑んでいくのではなく)「このプロダクトがどう素晴らしいのか」を問いながら、肯定的にテストすることを指しています。これは単に「ハッピーパスのテストをする」ことではありません。
その目的は、学習を通じて、プロダクトに対する豊かなモデルを心の中に構築していくことととされます。より良いテストをするための前準備ともいえ、もしかすると、探索的テストの前段階にあたるプロセスと言えるかもしれません。

共感的テストというアイデアは、ソフトウェアテストを直接的に改善するようなものではないでしょう。
ですが、QAにとって「壊す」作業は、「価値を確認する」という、より大きな目的のための1つの手段でしかなく、それ以外にも採るべき手段があるのだということを再認識させてくれる概念だと思います。

補記

最近は、「テストエンジニア」よりも「QAエンジニア」という言葉の方がポピュラーですね。
ですがこの記事では、にしさんのこの意志に敬意を表して、「テストエンジニア」としました。

*1:このようにロールを分けること自体が適切でないかもしれませんが。

*2:念のためですが、「壊す」能力は依然として貴重で希少なものであるとわたしは考えています。

*3:ただしこの記事では、共感的テストが何かを説明することが目的というよりは、このアイデアが誰に帰属するかについて述べることが目的のようです。筆者のJames Bachは、Cem Kanerたちの影響を受けながら再発明した概念、としています。