WACATE2024 冬の招待講演セッションにて発表してきました。

けっこう古新聞*1になってしまいましたが、WACATE2024 冬の「招待講演セッション」にて、『テスト設計技法をチョット俯瞰してみよう』というタイトルで発表をしてきました。

wacate.jp

発表の意図

資料はコチラです。 speakerdeck.com

8月のJaSST'24 北海道の基調講演では、『ソフトウェア品質のダンジョンマッピング』という発表をしています。 speakerdeck.com

こちらでわたしの考える品質・QAの世界の広がりを共有したのに対し、WACATEではその中の「テスト設計技法」にフォーカスしています。WACATE本会の中でテスト設計技法がいくつかあったこと、またJSTQB有資格者もいらっしゃるということで、「狭く、チョット深く」を指向したものです。

個々のテスト設計技法についての解説や演習などは、書籍やWeb記事が充実しています。一方で、技法同士の関係や解釈、体系、まだ見ぬ技法、といった観点で語っているものはそこまで多くないのではないかと考え、このような内容を選びました。

発表を通じて

正直、一人よがりな側面があったことは否めません。。テスト設計技法について要求する前提知識が少し高かったかもしれません（こういう書き方をすると、自分の発表のレベルが高いと言いたいみたいで気恥ずかしいのですが）。

ただ、WACATE実行委員会のメンバーの方にも、「こういう世界があるんだというのを感じてもらうのも招待講演の目的なので、いいと思う」と励ましの（慰めの？）言葉もいただき、今回はこれでよかったのだと思うことにしています。

なお、公開した資料を見た有識者の方からも「ちょっと攻め過ぎでは？」と言われました(笑)。特に後半は、自分の中で煮詰まり切っていないアイデアもみなさんにぶつけたりしています。参加者の方で、「招待講演の内容は意味不明すぎた」という方がいたら、すみません。。

いただいた反応

発表後に、質問をけっこういただきました。
何より、「しーん・・」となるのを予期して最初に質問してくださった方には本当に感謝です。おかげで質問のハードルが下がりました。
また「しょうもない質問してしまった」というツイも見かけましたが、発表者にとってはそういう質問も嬉しいものです。ありがとうございます。

また発表後に、何人かの方が感想を伝えに来てくださり、とても嬉しかったです。わたしは初対面の方でいきなり打ち解けるコミュニケーション能力がないので、短時間の会話となり申し訳なかったです。

おわりに

今回の発表内容は、すぐに現場の仕事で使えるようなものではありませんし、生煮えの部分もあります。ですが、ソフトウェアのテスト設計技法をより深く腹落ちさせるためのキッカケくらいにはなるかなと思っています。
ソフトウェアの品質という目的のために使える道具はたくさんあります。そのうちの一つであるテスト、そしてテスト設計技法も、大事な道具として磨けていければいいですね。

2024年の2つのイベントで、自分の知っていることとこれから取り組みたいことを、けっこう整理できました。生成AIという強力な道具もフル活用してこういった分野に取り組み、品質の分野にわずかでも貢献できるよう、2025年も楽しんで頑張りたいと思います。
聴講いただいた方、WACATE運営のみなさま、よい機会をありがとうございました。

自分用メモ: 言及いただいた記事

全部拾えているわけではありませんが、以下のブログで言及いただきました。ありがたや。。

---

note.com

テスト設計技法について深掘りする内容でした。難しかったけど本当に面白かった…！テスト技法同士の関係性って考えたことありませんでした。なぜこのテスト技法を使うのかという目的がブレてはいけなくて、そのためにはテスト技法の事をもっと知らなければいけないなと思いました。最後の未発掘の技法があるかもという話もワクワクしました。まだわからないこともたくさんあるので繰り返しスライドを読んで理解を深めたいです。

いつも思っているのは、品質もテストも「完成された」分野ではなく、常に発展中だということです。最初はその知識を「使う側」だとしても、いつか「作る側」になれたら楽しいよなあというのが持論です。

---

medium.com

テスト技法はたくさんありますが、いつどんな時にこの手法が向いているのか、それぞれ技法のメリットデメリットが明確で非常にわかりやすかったです。2日間通して様々な技法のワークを行っていたので「あ、あのテスト技法はこういう風に使われるのか」と理解がスムーズにできました。

自分の発表をグラレコで表現いただいたのは初めてだったので、新鮮でした！

---

zenn.dev

鈴木さんの発表、当日のお話だけでは消化しきれず（というか飲み込むところでつまづいている）、咀嚼の時間を確保しました。

実行委員の方の記事です。
ものすごく真摯に、わたしの発表内容に立ち向かってくださっていて、こちらも背筋が伸びました。決してわかりやすい資料ではないので、これからもっと具体化・簡易化・完全化(?)していければと思います。

---

note.com

各テスト設計技法同士の関係性についても触れつつ、しっかり回答がスライドに含められていてとてもイメージしやすかったです。
また後半では、これまで紹介したテスト設計技法の網羅性やモデリング技法とテスト設計技法についても触れられていました。

JaSST北海道の方の発表も聴いてくださったとのことで・・ありがたいです。この資料もまだまだ生煮えなところがたくさんあります。聴いた方の異論なども、ぜひ伺いたいです！

*1:この「古新聞」という比喩表現も、最近の若い世代にはピンとこなかったりするのでしょうか？ 古紙回収のトラックとか・・。

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

2024年後半に読んだ本を振り返って、よかったな～と思うものを記録しておきます。

ソフトウェア開発

コード×AI

コード×AIーソフトウェア開発者のための生成AI実践入門

著者の服部さんのご講演を聴いてから読んだのですが、GitHub Copilotを使いこなした方の知恵がひたすらに詰まっていて、本当にいいです。「AIで何でもできる！」ではなく、

• AIがどこまでならうまくやれるのか、人間はそれをどう補完すべきなのか
• 人間によるレビューの必要性を踏まえて、どのような出力をさせるといいのか

というように、AIと人間の組み合わせの最適バランスを探っていく説明がわかりやすい。また、「関心の分離」「DRY原則」といったプログラミングのプラクティスが、生成AIを使ったプログラミングとの相性がいいことにも面白さを覚えました。

今後AIがどう進化していくのか、わたしにはまったくわかりませんが、一瞬で価値を失うようなノウハウ本でないことは確かだと思います。生成AIの使い方に関する本もけっこう読みまして、もちろんいい本もあったのですが、今考えてみるとやはり賞味期限が短い・・・と感じています。

アジャイル品質パターン「QA to AQ」

アジャイル品質パターン「QA to AQ」 伝統的な品質保証からアジャイル品質への変革（CodeZine Digital First）

率直に言って、書かれていることすべてに納得できるわけではないし、「ん？」と思うような部分もけっこうあります。が、アジャイル開発における品質の考え方、それを語るうえでの言葉を定義して点で、やはり大事な文献だと考えています。

特に、ウォーターフォール中心の世界から転生してきて、アジャイルの考え方に戸惑っているような人にはオススメです。
わたしがそうだったのですが、「リリースの時点で、品質はカンペキになっているべきだ」という感覚だと、「その時に必要とされる品質に合意し、それを達成することが大切」という考え方*1が、「妥協」「品質の軽視」と見えてしまうんですよね。そういう方には、本書で紹介している「パターン」である「品質ロードマップ」「着陸ゾーン」といった考え方が役に立つと思います。

ただ繰り返しになりますが、すべてが「なるほど！ これだ！」となるような本ではないので、アジャイル経験者・未経験者を交えて議論する読書会で読むのがいいと思います。逆に一人で読むとモヤモヤしそう。

ノンフィクション

対立の世界史図鑑

歴史がわかる 今とつながる 対立の世界史図鑑

「正確で詳細な知識」を求める人には合わないだろうということを先に言っておくとして。
世界史に苦手意識があり、全体の流れもよくわからないから、ざっくり把握したい！って方（つまりわたし）にオススメしたい本です。歴史上の「対立」を、複雑さと情報量を、本質を失わないところまで落としたうえで、数ページで図解してくれます。よくある「見開き」ではさすがに無理なので、4～6ページにしたのは英断でしょう。

これで世界史を理解したことにはならないでしょうが、詳細に分け入る前の入口として、すごくよくまとまっていると感じます。

物語 ベルギーの歴史 ヨーロッパの十字路

物語 ベルギーの歴史　ヨーロッパの十字路 (中公新書)

「詳細に分け入る」本の一冊がこの本です。
仕事関連でブリュッセルに行く*2のをキッカケに手にした本です。

わたしにとってベルギーとは、中学時代に習った「ベネルクス三国」と、「ゴディバ」しか事前情報のない国でした。ヨーロッパの地図を見せられても、その位置を指すことはできなかったでしょう（今も少し怪しい）。観光本で「多言語国家」だと知って、へー。と思う程度の国。

が、その「多言語」という要素自体が、言ってみればベルギーの歴史そのものであり、そしてそれが今も続いている。言葉の違う人同士が仲良くなるのはサッカーの国際試合の時くらいだというくらい、オランダ語話者とフランス語話者の立場や関係が二転三転し、さらにはドイツ語話者もいて・・・と、とにかく複雑です。ベルギーの人に気軽に「あなたの母国語は？」と聞けなくなってしまいました。無知って怖いですね。。

なお今年から、「初めて訪れる国では、事前にその国の歴史の本を一冊読んでおく」プラクティスを実践しているのですが、これは本当に良いです。その国の全体観をふんわりとでも知っていくと、見えるものが少し違うように感じます。
オススメなのは、明石書店の『エリア・スタディーズ』。各地域の歴史から現代の各側面までを、複数の識者が網羅的に説明しています。ベルギー版は、上の本と同じ著者が編著されたものです。

ビジネス

ビジネス会食完全攻略マニュアル

ビジネス会食　完全攻略マニュアル――すべての食事会を成功に導く最強の実務メソッド

ジョーク本ではありません。
取引先などと「会食をする」。それだけのことで分厚い一冊書けてしまうのか、と驚く本。
食事のマナーのマニュアルではない。会食をいかに計画し、実行し、完了するのかを、徹底的に解き明かした一冊なのです。

この本に通底するのは、「相手のことを徹底的に考える」という点。わたしから見ると、「さすがにそれはやり過ぎでは」「そこまではできないな」と思うような指南もあるのですが、短期的な打算ではなく、中長期的に良い関係を築くためには、その徹底さが必要なんだろうなと感じます。

また特に気に入ったのが、「店を道具のように捉えていない」ところ。
最近は簡単にオンライン予約ができるようになり、人数増減やコース変更はもちろん、キャンセルさえも、「相手にお詫びし、伝える」というステップを踏まない気軽なものになっています。これは飲食店を、「自分の都合で自由に動かせるリソース」のように捉えることにつながります。
「実務メソッド」「攻略マニュアル」と聞いて、そういう行為や発想を「テクニック」のように紹介しているのかと思ったら、さにあらず。筆者は、もてなす相手との関係を築くのと同じように、良い店とも長く続く関係を築くことを目指す。どうしてもキャンセルが発生してしまう分は、プライベートで店を訪れて埋め合わせる。
もてなす相手に対しても、店に対しても、誠意をもって接するのだという気概の伝わる本でした。

文学

えーえんとくちから

えーえんとくちから (ちくま文庫)

現代詩はホントに好みが分かれるので、わたしがこの詩集の中で好きになったものを2つ紹介します。

ひまわりの死んでいるのを抱きおこす　季節をひとつ弔うように

ひろゆき、と平仮名めきて呼ぶときの祖母の瞳のいつくしき黒

読めば意味はすんなりとわかる、でも自分からは千年待っても出てこない、そんな言葉たちです。

フィクション

ハコヅメ

ハコヅメ～交番女子の逆襲～（１） (モーニングコミックス)

よくあるお巡りさんドタバタ物語かと思ったら・・・。
いや、まずそういう感じで始まるのですが。で、そのドタバタだけでもめちゃくちゃ面白いのですが。

時々姿を現す不穏な感じ。その不穏さは、次のページにはあっさりかき消されてしまう。でも少し経つと、その不穏さがまた顔を出す。切れ味鋭いギャグ展開の中に、どうしても目をそらせない悪寒。

あまり書くと面白さを損なってしまうのですが、何度も「・・・は？」ってなりました。ギャグと伏線ミステリーの奇跡的なコラボだと思います。

地雷グリコ

大好き過ぎて、こちらで記事を書きました。

www.kzsuzuki.com

黒子のバスケ

黒子のバスケ モノクロ版 1 (ジャンプコミックスDIGITAL)

めちゃくちゃ「週刊少年ジャンプ」だな！っていうマンガです。
ぶっちゃけ、バスケ×異能バトルといってもそう外していないと思うのですが、主人公・黒子テツヤの持つ能力は、ずば抜けていながらも万能ではない。というより、試合をするごとに効力を失っていく。そんな中、強大なライバルたちとどう伍していくか・・・。

と書くとやっぱりただの異能バトルのようになっちゃうのですが、「チームの絆」という物語の中に一本通った芯があり、「バスケットボール」というスポーツのラインをギリギリ踏み越えていないんですよ（多分）。
わたしは『テニスの王子様』のハチャメチャさも好きなのですが、あれはもう「確信犯」*3じゃないですか。対戦相手の五感を奪うとか、自分の周りにブラックホールを出現させるとか。
『黒子のバスケ』は違います。・・・いや、違うと言い切れないヤバい能力も出てくるけど・・・それでも「スポーツ青春マンガ」だと思います。

風が強く吹いている

風が強く吹いている（新潮文庫）

で、結局わたしは「若者が頑張ってる姿」が好きなんだなと思って、『風が強く吹いている』を読み直してみました。

ほぼ素人ばかりの10人がいきなり箱根駅伝を目指してしまう時点でご都合主義的なところはあるにしても、若者一人一人がいろんな思いを抱え、走りの中で自分と向き合っていく姿が胸に迫る。
「なぜ、走る者のこの感覚を、想像で書けてしまうんだ？ 本当に走りに走った人にしか到達できない、つかむことのできない感覚なのでは？」という描写にも驚かされます。小説家というのは、いったいどのような才能と感性をもって、自分の経験していないことを、文章として結実させていくのか。恐ろしいとしか言いようがない。

で、なぜこの小説を16年ぶりくらいに読んだかというと・・・

同じ「箱根」での戦いを、『弱虫ペダル』で読んだからです。

弱虫ペダル　1 (少年チャンピオン・コミックス)

『弱虫ペダル』、途中までしか読めていないのですが、とにかく1年目のインターハイの物語完成度は100%なんですよ*4。自転車競技なんかまったく知らないのに、それなのに、胸を締め付けられるような緊張感と、感動。

この作品の中でずっと「凡人」と呼ばれ、自分を「弱い」と言い続けている手嶋先輩のモノローグを置いておきます。

オレだって期待されれば　もっと頑張るのにって　思ってた
でもそれは　間違いだった
考えればあたり前のことだ

そうさ

頑張らないと
期待なんかされない！！

――― 『弱虫ペダル 34巻』RIDE.290 凡人と天才

陳腐でしょうか？ 陳腐かもしれません。
でも、切り抜かれた言葉ではなく、物語を通してみると、この言葉に詰まっている思いがわかると思います。

やっぱり歳なんですよね、若者たちがひたむきに、がむしゃらに頑張って何かをつかもうとする姿に、ぐっときちゃうんですよ。わたしの青春はこんな風に、何か一つのことに仲間と取り組むようなものではなかったので、フィクションで追体験させてもらってます。
若者の情熱からパワーを受け取りたい方へ。

おわりに

今年もまだ読み中のいい本がたくさんあるので、また共有したいなーと思います。
2025年もよろしくお願いします。

*1:この考え方がアジャイルの特徴だと言いたいわけではないです。ウォーターフォールでも同じ考え方はあったと思います。アジャイルについて下手に言及すると殴られそうで不要に言い訳がましいけど。。

*2:『人生が整うマウンティング大全』を読んで以来、海外に行くと言及すること自体に過敏になっている。

www.kzsuzuki.com

*3:間違った意味での。

*4:って2022年にも書いていた・・・。 www.kzsuzuki.com

わたしの好きなデシジョンテーブル表現方法を説明するにもほどがある

これは、ソフトウェアテストの小ネタ Advent Calendar 2024、10日目の記事として出す。
出すが・・今回まだその時と場所の指定まではしていない。どうかそのことを諸君らも思い出していただきたい。つまり・・我々がその気になれば、記事の公開は5日・10日前ということも可能だろう・・ということ・・！

qiita.com

テスト設計においてもよく利用されるデシジョンテーブル。
その記述方式は大きく分けて2つ、「制限指定」と「拡張指定」があります。

この記事では、『ソフトウェアテスト技法練習帳』の問題を借りてこの2つの記法を紹介したうえで、わたし自身が気に入っている記法について説明したいと思います。

ソフトウェアテスト技法練習帳 ~知識を経験に変える40問~

なおデシジョンテーブルは、JIS X 0125:1986 で規格化されています。ただ正直そこまで厳密な定義に興味がないため、じっくり読んではおりません。よって「制限指定」「拡張指定」の説明は雑かもしれません！ 先に逃げを打っておきます。

これはエグゼクティブサマリーです。

エグゼクティブサマリー

フッターにWACATE2024冬と書いてあるのは、WACATE2024冬の発表資料作成中に生まれ出てきたスライドだからです。
たぶんこの話は寄り道になり過ぎるので、Twitterとこの記事で放流してしてしまいます。WACATEで会うみなさん、その旨ご了承ください。

今回使う仕様

『練習帳』の問題2.5では、「カレンダーの日付を色分けする」という動作について、デシジョンテーブルを書きます。その仕様は、ざっくり以下のようなものです。

祝日は赤
日曜日は赤
祝日でない土曜日は青
祝日でない平日は黒

これをどう条件として切り分けるかは好みがあるかと思いますが、『練習帳』における解答にしたがって、「祝日かどうか」と「何曜日か」を組み合わせることにします。

デシジョンテーブルの記述方式

1. 制限指定

先にデシジョンテーブルをお見せすると、こうなります。

制限指定

この後の話のために用語を説明しておきましょう。

デシジョンテーブルの4つのエリア

デシジョンテーブルの左上が「条件記述部」。
一番上の行には「祝日」とだけ書いてありますが、もう少し丁寧に書くなら「祝日である」という命題です。

右上が「条件指定部」。「祝日である」という命題に対し、真偽値を書いています。

左下は「動作記述部」。
こちらも一番上の行は「赤である」という命題と捉え、右下の「動作指定部」に「X」が書かれていれば「真である」を意味します。

このように制限指定では、左側つまり記述部が、2値の命題になっている点が特徴です。

デシジョンテーブルは横長の表になりがちですが、制限指定であれば指定部が1文字で済むので、表がコンパクトになります。一方で、記述部は真偽値を取る命題に「開く」必要があるため、縦長になりがちです。

そして一番の問題は、「祝日」という命題と、「土曜日」「日曜日」「平日」という命題が、別のパラメターの値であることがわかりづらいという点です。
この表をパッと見た人は、なぜ「祝日」が「TTTFFF」で並び、「土曜日」「日曜日」「平日」に順番に「T」が現れるのか、わからないでしょう。可レビュー性が低いです。

2. 拡張指定

デシジョンテーブルはこのような形になります。

拡張指定

特徴は、指定部に真偽値ではなく、具体的な「値」が入っていることです。これによって、パラメターは「祝日」と「曜日」の2つであり、それぞれ「祝日」「非祝日」、「土曜日」「日曜日」「平日」という値を取るのだということが、制限指定よりはわかりやすくなります。

また、個々の列（ルール）をチェックするとき、たとえば#1を上から順に見ていくと、「祝日で土曜日なら赤」ということが一目でわかるのも嬉しい。これは制限指定にはなかった長所です。ただ個人的には、#1～#6で正しく値を割り当てられているかがイマイチわかりづらいなと感じます。

スペースの使い方としては制限指定と真逆になり、縦はコンパクトになりやすく、横が広がりやすい。

3. わたしの好きな形式

こんな形式です。

鈴木の好きな形式

別にわたしオリジナルというつもりは全然ないのですが、明示的な名前がついていないような気がします。
ともあれ、特徴は2点あります。

(1)記述部には、パラメターと値を、列を分けて書く。

ある意味、制限指定と拡張指定のハイブリッドと言えるかもしれません。
こうすることで嬉しいのは、条件と動作それぞれにどのようなパラメターがあり、各パラメターがどのような値を取るかが明らかである点です。
よって、以下の観点でのレビューが楽になります。

• 条件部のパラメターは十分か、他に動作に影響するパラメターはないか
• 動作部で確認すべき項目は十分か
• 条件部のパラメターと動作部の項目は、適切に同値分割されているか

これらは、どう丸つけするか、テーブルを圧縮するかといった話以前の、「そもそも検討していることが正しいか」の確認であり、きわめて重要です。
また同じ理由で、パラメターや値を追加する際にもその変化が見てとりやすいでしょう。拡張性に優れているともいえます。

(2)指定部は、該当する箇所だけにマークする。

これはある意味冗長であり、スペースの無駄遣い。縦に伸びやすい制限指定の特徴を引き継いでいます。
しかしそのおかげで、丸付けのパターンがとても明瞭であることも見て取れると思います。これは制限指定にも拡張指定にもない長所と言えます。

ただし1点、重大な欠点があります。この形式をスプレッドシートで表現しようとすると、パラメター列で「セル結合」に走りがちだということです。
セル結合の弊害は計り知れません。セル結合だけはしないでください。

結論

自分の好きな形式で書いてください。

「過剰品質」とは一体何を指すのか

「日本の製品は過剰品質なのでコストが高くなり、グローバルで売るのが難しい」といった主張を聞いたことはないでしょうか。
このような主張がなされるとき、本当に現状を憂えている場合もあれば、「日本製品の品質の高さ」をどこか誇っているようなこともあります。

それでは、「過剰品質」とは何を指すのでしょうか。

品質特性と顧客価値

JaSST'24 北海道の発表資料*1で、当日言及できなかったスライドを、Twitterに放流してみました。

JaSST北海道では言及する時間のなかった、「過剰品質」についてのスライドの供養。
日本企業が過剰品質を自嘲する時、「当たり前品質」を頑張り過ぎる➋を言っているつもりが、実は「当たり前品質」も上がっていない➊になっていないか？というのが言いたかったことでした。

過剰品質とは？

かけた労力に対して、品質*2や顧客価値がどう変化するかでマトリクスを作ってみましょう。

価値 → 品質 ↓	上がっている	上がっていない
上がっている	理想的な状態	②自己満足
上がっていない	ありえない？	➀完全な無駄

おそらく、本来の意味の「過剰品質」は、②を指すのではないでしょうか。労力をかけて、製品を「良く」した、けれど顧客のうれしさにつながっていないと。
ただこれは、「顧客を見る・知る」ことで解決すべき、前向きな課題に思えます。

一方➀は、技術力の問題に帰着するかもしれません。
「テストケースは多いほど正義」「理由はわからないが、過去のリグレッションテストは決して減らすことができない」、こういった意識が根付いていて、「効果的なテスト」を追求する意志がないと、➀につながっていくのではないでしょうか？

自社ビジネス価値

上のツイに対し、こんなコメントをいただきました。

あとは、③として、品質も価値もあがってるがビジネスになってないというのもありそう。
耐久性上がって買い替えサイクルが長くなるとか、著しく人に依存した職人芸とか

これにはハッとさせられました。十分な時間をかけて品質を上げ、顧客も大喜び、でも自社は全然投資回収できていない・・。これでは本末転倒ですよね。

とくさんの例はすごくわかりやすいです。
「耐久性が上がる」、つまり品質が上がった、顧客も大喜び、しかし買い替えが起こらなくなるために、長期的には自社の首を絞めてしまう・・。
過去、某メーカーの何とかタイマーという都市伝説がありましたが、「あえて耐久性を制限する」（＝品質も価値も下げる）ことで、自社ビジネスの継続性を担保する、その代わりの他の品質特性で圧倒的な価値を与えるという戦略もあるのかもしれません。倫理とのバランスはあると思いますが・・。

ともあれ、自社にとってのビジネス価値。
言われてみれば当たり前ですが、「品質特性」「顧客価値」の2軸マトリクスで網羅した気になっていると見落としてしまう、大事な観点だと思いました。

他社ビジネス価値

ついでに、JaSST'24 TokyoでのGojko Adzicさんの基調講演で提示されたこの絵のことも思い出しました。

Gojko Adzicさんのモデル

見ての通りこれは、マズローの欲求5段階のオマージュで、下の方から順に満たされていくというモデルです。

第1階層は「デプロイできる、機能がまとも」ということで、本当に「最低限」です。マズローでいうところの「生理的欲求」に対応しています。
第2階層は「性能が出て、セキュアである」。マズローの「安全欲求」に何となく対応しているのが面白いところです。
第3階層は「使うことができる」。ここまできてようやく、製品としてまともになってきますね。
第4階層で「有用である」となってきます。SQuaREでいうところの「製品品質」から「利用時の品質」にシフトしている感じもあります。ただ、「製品」と「利用者」に閉じた話にも見えます。

第5階層はそれを飛び出し、その製品の利用を通じて「組織として成功しているか」*3に注目しています。利用者が製品を喜んで使っていたからといって、それがビジネスとしての利益に結びついていないなら、まだ道半ばということですね。これも、過剰品質の話につながってきそうです。

まとめ

過剰品質話は誰も得をしないので、「どんな価値につなげるために何をがんばるのか」は意識しておきたいところです。
また「自社あるいは他社が利益を得られるか」となると、（狭義の）品質からは話が飛び出してしまいますが、QAたるもの、こういう視点も持っていたいものですね。勝手に勉強になりました。

*1:元資料はコチラです。 speakerdeck.com

*2:本稿でいう「品質」とは、品質全体を構成する各品質特性のことです。たとえば、性能とか、使い勝手とか。

*3:講演と聴いた時には、「製品開発側の自組織が、その製品の提供によって成功しているか」という話に聴こえたのですが、ご本人のブログ記事を読む限りでは違うようです。 gojko.net

ãƒ‡ã‚·ã‚¸ãƒ§ãƒ³ãƒ†ãƒ¼ãƒ–ãƒ«è¶…åœ§ç¸®ã®å¤¢ã«ç ´ã‚Œã¦

『ソフトウェアテスト技法練習帳』の勉強会で、めちゃくちゃいい質問がありました。

ソフトウェアテスト技法練習帳 ~知識を経験に変える40問~

その場で答えてはみたのですが、すごく大事な話だと感じたので、ブログ記事にしておきたいと思います。ただわたし自身の理解も足りていないかもしれないので、お気づきの点があればフィードバックお願いいたします。

3行まとめ

• デシジョンテーブルテストは、「複数の条件を組み合わせた場合の動作」を検証する技術である。
• 「組み合わせる前の単一条件の動作」は、デシジョンテーブルテストの前に検証しておく必要がある。
• デシジョンテーブルで2つ目もカバーできると思っていると、痛い目に合うかもしれない。

デシジョンテーブルの超圧縮!?

対象の問題は、本書「2.3 紳士服店の割引率」。
問題を雑に簡略化するとこうなります。

以下の仕様に基づいて、デシジョンテーブルを書け。
「ワイシャツとネクタイを含めて7点以上買えば、7%引きになる」

単純には、以下のようになります。
7点以上⋀ワイシャツあり⋀ネクタイあり ならば、7%引き。それ以外は割引なしと。
特にヒネリはありません。

	1	2	3	4	5	6	7	8
7点以上	T	T	T	T	F	F	F	F
ワイシャツあり	T	T	F	F	T	T	F	F
ネクタイあり	T	F	T	F	T	F	T	F
割引7%	T	F	F	F	F	F	F	F

これに対して、以下の質問をもらいました。

「ワイシャツあり」「ネクタイあり」の条件を別々にせず、「ワイシャツとネクタイが入っている」という1つの条件にしてはいけないのか。

なるほど。これをヨシとすると、以下のようになります。

	1	2	3	4
7点以上	T	T	F	F
ワイシャツとネクタイあり	T	F	T	F
割引7%	T	F	F	F

なんと、テストケース数が半分になりました！

ただそんなうまい話があるわけもなく、何か失っているものがありそうです。何しろ、これを突き詰めていくと、これでもいいのですからね・・・。

	1	2
7点以上でワイシャツとネクタイあり	T	F
割引7%	T	F

具体的なテストケースを考えてみると・・

さて、少し話が変わります。
デシジョンテーブルでテストケースを導出したとして、ではそのままテストができるでしょうか？

いいえ、必ずしもそうではありません。
たとえば最初のテーブルの#1のテストケース、「7点以上」という条件がTになっていますが、具体的には何点にしましょうか。また「ワイシャツあり」とありますが、ワイシャツは何点含めましょう。
てな感じで、実際にテストを行うにはもうワンステップ、テストデータの具体化が必要なわけです。

では、2つ目のデシジョンテーブル（以下再掲）のために、こんなテストデータを用意します。

	1	2	3	4
7点以上	T	T	F	F
ワイシャツとネクタイあり	T	F	T	F
割引7%	T	F	F	F

• #1: ワイシャツ×3、ネクタイ×3、ソックス×4
• #2: ソックス×10
• #3: ワイシャツ×3、ネクタイ×3
• #4: ソックス×3

もし実装が以下のようになっていれば、このテストはすべて通るでしょう。

7点以上 ⋀ (ワイシャツあり ⋀ ネクタイあり) → 割引7%

一方、以下のように実装が間違えまくっていても、このテストはすべて通ります。

9点以上 ⋀ (ワイシャツあり ∨ ネクタイあり) → 割引7%

デシジョンテーブルで網羅的にテストをしたはずなのに、一体、何が悪かったのでしょうか・・？

ブレイクタイムに書かれた重要な注意書き

実はこの2.3のコラム欄「ブレイクタイム」に、こんなことがさらっと書かれています。

デシジョンテーブルを使ってテストをしたからといって、十分にテストをしたとは言えません。なぜなら、デシジョンテーブルは条件の組み合わせを網羅するものであり、個々の条件をテストするものではないからです。

これは、単体テスト→統合テスト→システムテストと、小さな範囲のテストを積み上げていくことに似ています。部品の組み合わせのテストをする前に、部品自体のテストをする必要があるということです。

では、先のデシジョンテーブル（以下再掲）を元に、部品である個々の条件を調べてみましょう。

	1	2	3	4
7点以上	T	T	F	F
ワイシャツとネクタイあり	T	F	T	F
割引7%	T	F	F	F

条件「7点以上」

「7点以上」という単一の条件自体が正しく動作するかを確認してみましょう。
この場合は、デシジョンテーブル上で「7点以上」の値だけが結果に影響を与えるテストケースを選んで、境界値テストをすることができます。

	1	3
7点以上	T = 8点	F = 7点
ワイシャツとネクタイあり	T	T
割引7%	T	F

ここでもし実装が上述のように

9点以上 ⋀ (ワイシャツあり ∨ ネクタイあり) → 割引7%

と誤っていれば、#1のテストが失敗（割引7%がFになってしまう）で検知できることになります。

条件「ワイシャツとネクタイあり」

「ワイシャツとネクタイあり」という条件が正しく効いているのかの確認には、テストケース#1と#2を使います。

	1	2
7点以上	T	T
ワイシャツとネクタイあり	T ワイシャツあり ネクタイあり	F ワイシャツあり ネクタイなし ワイシャツなし ネクタイあり ワイシャツなし ネクタイなし
割引7%	T	F

そう、デシジョンテーブルの中で1つの条件に丸めることで、一見テストケースが減ったように見えましたが、部品の確認のために結局、ワイシャツとネクタイのあるなしの組み合わせを個別に確認する*1ことになるのです。

つまり、やるべき具体的テストケースの数は別に減っちゃいないということですねー。

まとめ

再掲。

• デシジョンテーブルテストは、「複数の条件を組み合わせた場合の動作」を検証する技術である。
• 「組み合わせる前の単一条件の動作」は、デシジョンテーブルテストの前に検証しておく必要がある。
• デシジョンテーブルで2つ目もカバーできると思っていると、痛い目に合うかもしれない。

勉強会での質問を受けて、あらためて認識しました。これを説明しているところって、意外に少ない気がしましたが、どうでしょう*2？

なお本稿は、ネモトノリユキさん、しましまさん、ブロッコリーさんにレビューいただきました。ありがとうございます。

追記 (2024/9/24)

秋山さんから以下のコメントをいただきました。

先に条件（condition）と判定（decision）を教えてからデシジョンテーブルテストの説明をしないとそう言う質問がくるかもですね。
疑問に思っても質問しない人が多いから良い質問だけれど。

— あきやま🏀 (@akiyama924) 2024å¹´9月23æ—¥

ここでいう「条件」とは、「7点以上である/ない」「ワイシャツがある/ない」「ネクタイがある/ない」の、各単一条件を指します。
判定とは、単一条件を組み合わせた結果、「割引がある/ない」という判定がどうなるかを指します。

Generated By Dalle

*1:なし/なしを省略する作戦はありうる

*2:ブロッコリーさんから、『ASTERセミナー標準テキスト』に近いことが書かれている、とコメントいただきました。確かに演習問題の方のファイルP.23に、以下の説明がありました。

それぞれの条件に対して同値分割法・境界値分析を適用する。