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

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

プロダクト出力の確率論性質と品質保証

生成AI 機械学習 ソフトウェア品質

機械学習・AIの文脈における「確率論」（probabilistic）といえば、以下が思い当たる*1。

  1. 機械学習のモデルトレーニングにおいて、最初に与えるシード値によっては同じデータセットでも違うモデルになりうる。モデルが違うと、同じ入力であっても別の出力になりうる。
  2. テキスト系生成AIにおいては、出現確率が閾値内に入る単語群から単語を選定して出力するため、同じ入力であっても別の出力になりうる。
  3. 機械学習のモデルによる出力は、「確信度が高い」ものであって、100%とは限らない。そして、確信度が100%であっても正解とは限らない。

確率論的とか非決定論的（non-deterministic）とかいう話をするときは、どの意味で語っているのかをハッキリさせておくといいだろう。

さて、品質保証の文脈で、このようなツイートを見かけた。

従来はOK/NGを明確に判断できたものが、AIプロダクトでは「明らかに間違っているものを排除する」というアプローチに変わらざるを得ない。

このツイに対し、伊藤由貴さんはこう言っている。

QAが決定論から確率論になったのって生成AI時代だからというよりは元からそうなんじゃないかなという気がしてる 誰かにとっての価値だよね、という時点でもう確率論な気がしている

これらの話自体に異論はないのだけれど、冒頭に書いた「確率論的」とはまた違う話に思える。

両者をどう仕分けるといいのだろうと考えてみると、これはソフトウェアテストでいうところの、「実際の結果」（actual result） の話なのか、「期待結果」(expected result) の話なのかで考えるとよさそうだ。

冒頭の話は、「実際の結果」が確率論的、つまり「同じ入力でも、実際の結果が同じになるとは限らない」 ということを言っている。
一方でツイートは、「どのような出力になるべきかという期待結果を、開発者が一意に指定できるとは限らない」 という話にみえる。伊藤さんが引用しているWeinbergの「品質とは、誰かにとっての価値である」しかり、James Bach・Michael Boltonの「品質とは、誰かにとっての、ある時点での価値である」しかり。

「本当の期待結果」 を開発者・QAエンジニアが事前に知りえない、何ならWeinbergらのいう「誰か」でさえ明示的に示すことができない（かもしれない）というのは、AI時代以前からの品質保証の悩みであり面白さでもある。
ただ、AIプロダクトにおいてはそれが顕著になる。

簡単な例でいうと、AIによる文章要約タスク。
要約された結果に対して、「完全に正解」「完全に不正解」のいずれにもならず、「そこそこいいけれど、改善の余地あり」といった判断になりうる。それこそ「明らかに間違っている」のラインを決めるのも難しい。
ただ、これを「確率的」と言ってしまうと、ちょっと違うようにも思う。期待結果自体が確率に関係しているわけではないからだ。

大雑把に言うと、こんな風に整理*2できるだろうか。「パラダイム」という言葉を使ってみよう。かっこいいからだ。

パラダイム 期待結果 実際の結果
平和な世界 客観的に決められる 一意に決まる
従来の品質保証 主観的にしか決められない 一意に決まる
AIプロダクトの品質保証 主観的にしか決められない 確率的にしか決まらない

ともあれ、「AIプロダクトの品質保証」パラダイムにおいては、「主観的」と「確率的」が掛け合わせて効いてくる、これこそが難しさの源泉なのではないかと思う。

*1:知識が浅いので、誤解があったら優しく教えていただきたい

*2:もちろんこれは大雑把な整理である。「従来の品質保証」パラダイムにおいても、たとえば「定量的に性能要件が決められていたとしても、実際のレスポンスタイムは実行ごとに異なりばらつきがある」といったことが起こる。

ISTQBから出ている境界値分析についてのホワイトペーパーが面白かった

基本的なテスト技法である「境界値分析」（Boundary-Value Analysis、BVA）についてのホワイトペーパーが面白いと聞いて、さっそく読んでみました。わずか7ページで読みやすいですし、基本的なコンセプトから誤解しやすいポイント、注意点などが具体例付きでまとめられていて、とてもいい内容だと思いました。

Research Compendium - International Software Testing Qualifications Board - Boundary Value Analysis According to the ISTQB® Foundation Level Syllabus (pdf)

第6章の「Dealing with seamless transitions」の例は、自分でしっかり考えたことのなかったものだったので、簡単に紹介してみます。
銀行の送金プログラムを例として、以下のような仕様を考えます。

取引の手数料は、取引金額の1%。ただし手数料の下限は1ユーロ。有効桁数は小数点2桁まで。

シンプルに考えると、「1%が1になる上限」である「100」が境界値になります。取引金額100ユーロまでは、手数料は固定の1ユーロだなと。100ユーロを超えると1%の計算も1ユーロを離れ、取引金額に比例していくと。

よって、以下の2つの「同値パーティション」が特定できたことになります。

  • EP1: 取引金額 0.00ユーロ から 100.00ユーロ。手数料は1ユーロ固定。
    • 上限の側のカバレッジアイテム（テストすべき入力）は、100.00、100.01。3値BVAの場合は加えて 99.99。
  • EP2: 取引金額 100.00ユーロ以上。手数料は取引金額の1%。
    • 下限の側のカバレッジアイテムは、100.01、100.00。3値BVAの場合は加えて 100.02。

さて、これで何も問題なさそうですが、これらのテストにおける出力を見てみましょう。

同値パーティション 入力値 (取引金額) 100ユーロまでの固定値 取引金額の1% 出力値 (手数料)
EP1 99.99 1.00 1.00 1.00
EP1 100.00 1.00 1.00 1.00
EP2 100.01 1.00 1.00 1.00
EP2 100.02 1.00 1.00 1.00

そう、この4つの入力値はすべて、「100ユーロまでの固定値」「取引金額の1%」が1ユーロになり、出力値がどちらの数字を「採用」したかがわからないのです。これでは、境界の実装が誤っていた場合に検知することができません。

このホワイトペーパーでは、データの変化（data transision）に応じた新しい同値パーティションを定義するとしています。

  • EP1: 取引金額 0.00ユーロ から 99.49ユーロ。手数料は1ユーロ固定だが、取引金額の1%は1ユーロ以下である。
  • EP2: 取引金額 99.50ユーロ 以上 100.49ユーロ 以下。取引金額の1%は1ユーロである。
  • EP3: 取引金額 100.50ユーロ以上。取引金額の1%は1ユーロを超える。

先と同じ表を作ると、以下のようになります。

同値パーティション 入力値 (取引金額) 100ユーロまでの固定値 取引金額の1% 出力値 (手数料)
EP1’ 99.49 1.00 0.99 1.00
EP2’ 99.50 1.00 1.00 1.00
EP2’ 100.49 1.00 1.00 1.00
EP3’ 100.50 1.00 1.01 1.01

EP1’、EP2’、EP3’で、「取引金額の1%」が違っており、手数料が決まるロジックを確認できるようになりました。

テスト技法を勉強してけっこう長いですが、このようなケースについてあまり考えたことがなかったというのが正直なところです。
第7章の「Further practical considerations」にも興味深い話がありますので、「境界値分析なんて基本だぜ！」という方にも読んでいただきたいです。

英語中級者(自称)による、英語学習における生成AIのちょっとした使い方

英語 生成AI

日ごろ、英語のちょっとしたお勉強に生成AIをどう使っているかをご紹介します。
わたしは生成AI使いこなしマンってわけでもないので、ちょっと恥ずかしいのですが。 ざっくりと、3つあります。

  1. 語幹を調べる
  2. 意味の違いを調べる
  3. 英文を添削してもらう

1. 語幹を調べる

「英語のボキャブラリーを強化する」なんて目的がなくても、単語における「語幹」というのは面白いものです。
よく例に出るのが「philosophy」（哲学）。philoは「愛する」でsophyは「知恵」なので、philosophyは「知恵を愛する」ことであり、愛知県のことでもあります。
「Mesopotamia」（メソポタミア）もいいですね。世界史の時間に、「2つの川に挟まれた」という意味だと習いましたが、実際mesoは「中間」、potamは「川」を意味している。このpotamは「hippopotamus」つまりカバという単語にも含まれていて、ついでにカバは「河馬」なので、漢字で書いても「河」が含まれている。さらにhippoの方は「馬」なので、「hippopotamus」と「河馬」は完全に対応している、というわけです。

わたしはGPTsを作っておいて、知らない単語が出てきたらそれに聞いて、さらにその語源から別の単語を引くようにしています。 こんな感じです。

語幹を調べるGPTs

「diagnosis」（診断）という単語にgnos（認識する）という語幹が含まれていて、同じくgnosを含む単語として「agnostic」「cognition」という単語があるとわかります。さらにこの「agnostic」と調べてみると‥という使い方になります。
「診断」と「グノーシス主義」の間にある、「認識する」という意味のつながりを見出すことができたりするわけです。
最高ですね。

2. 意味の違いを調べる

英語を書こうとすると、「似て非なる単語」に出会ってハタと迷います。そんな時、生成AIはいい感じに意味の違いを教えてくれます。これもGPTsにして、気になったら聞くことにしてます。
同じ「制約」的な意味をもつ、「limitation」と「restriction」の違いを教えてもらうと、こんな感じです。

単語の意味の違いを調べるGPTs

ポイントは、「どちらかでしか意味の通らない例文」を提示してもらっている点です。意味的な説明だけだとよくわからないのですが、「この文脈ではなぜこの単語が不適切なのか」という具体例があると、「そういうことか！」ってなるんですよね。

3. 英文を添削してもらう

これはまあ、みなさんやっているかなと思います。生成AIに原文をつっこんで翻訳してもらう方が100倍早いのですが、気力がある時には自分で英文を書いて、添削してもらっています。
これはさすがに生の使い方（つまりわたしの拙い英文）を見せるのが恥ずかしいので、プロンプトの概要を紹介します。これはこれで拙いとは思いますが。。

日本語の文章が与えられたら、以下の条件で添削をしてください。  
1. まったく新しい文章を作り直すのではなく、できるだけ元の文章構造・単語を維持するようにしてください。そうすればユーザは、自分の文章の問題点・改善点を理解しやすくなります。  
2. 重大な誤り、誤解を招く表現、失礼に当たる言い回しがあれば、必ず指摘してください。  
3. 文章のトーンとして、「プロフェッショナル同士のやり取りだが、カジュアルさを持つ」ものとしてください。  
4. 入力された文章の、英語としての精度を、10点満点で表現してください。わたしの感情に配慮せず、合理的に点数をつけてください。  
  * 10点: ネイティブなみ  
  * 8点: ノンネイティブとしては十分な自然さ  
  * 6点: 不自然な構文・単語が散見される  
  * 4点: 間違いが多く、大きな改善余地あり  
  * 2点: 読解自体が難しい  
  * 0点: 英語になっていない  
5. 最後に、生成された文章の日本語訳も併記してください。

条件1を指定しているのは、「解釈した意味をベースに、生成AIがまったく新しい文章を作り直してしまう」傾向があったためです。これだと何が悪くて直されたのか、全然わからなくなってしまいます。たとえ多少しょぼくとも、自分の書いたものをベースにしたいため、このように指示しています。
条件2はまあ、そのままです。知らずに使っている、実は失礼な言い回しなどをチェックアウトすることが目的です。
条件3は、わたしが英語を使う場面で共通的に求められるコンテキストです。
条件4は、自分の英語の未熟さを自覚するためのモノです。だいたい6点です‥。
条件5は、あまりに自分の英語がひどすぎて、生成AIが意味そのものを取り違えてしまうケースを避けるためのモノです。。

あまり参考にならないかもしれませんが、よかったらどうぞ。
語幹はいいぞ。

『ソフトウェアテスト徹底指南書』、鉛のごときその濃密さ

書評

「噛めば噛むほど味が出るスルメのような」 という比喩は、しばしば書籍にも用いられます。最初に読んだ時にはすっと通り過ぎてしまったけれど、少し経験を積んで読み直してみると、「この何気ない一言は、そういうことだったのか！」 と合点してしまうような本です。
なぜ、そのような本が生まれるのか。
それは、その本の記述が、「ネットで調べたことをまとめてみました！」ではなく、徹底した実践と経験に裏付けられているからでしょう。そのため、読む側の経験値が増えると、著者の意図がストレートに伝わってきて、その経験を追体験できるのです。

2025年6月、井芹洋輝（@goyoki）さんの『ソフトウェアテスト徹底指南書』が、満を持して発売されました。 本書はまさに、スルメのような本です。しかも、口には入りきらない、でっかいスルメです。

ソフトウェアテスト徹底指南書 〜開発の高品質と高スピードを両立させる実践アプローチ

ソフトウェアテスト徹底指南書 〜開発の高品質と高スピードを両立させる実践アプローチ

Amazon

モノの重さは、体積と密度をかければ求まります。どちらかでも大きければ、重くなります。
『指南書』は、両方大きい。文章量がまず膨大で、そこに詰め込まれた情報密度も濃い。よってこの本は読者に、しんどい読書体験をもたらします。何せ、安易に読み流させてくれない。1行1行に血肉が詰まっています。冗長な部分、不要な部分は、井芹さんの几帳面さをもって丁寧に排除されています。使い古された言葉ですが 「筋肉質」 であり、レントゲン写真を撮る際に身にまとう鉛の防護エプロンのようです。

一人の人間が、これだけの知識を得、実践し、自分の言葉として練り上げるにはどれだけの努力が必要なのか。凡人たるわたしにはとても想像がつきません。
「QAエンジニア」 という言葉が広がるにつれて残念ながら、「テスト技術」を軽視する、正面から取り組むことを避けるような言説も目にするようになりました。「QAエンジニアの仕事はテストだけではない」は真。でもそこから「よって、テストの話をしてもしょうがない」というのは真ではないでしょう。そう思っていたところに、この本を産み落としてくれたことに、感謝しかありません。

‥ さて、エモに入りすぎたので、もうちょっと具体的に書いていきましょう。

本書の好きなところ

わたしが本書の長所と思う点を3つ、挙げてみます。

テストを礼賛しない

P.10のタイトル、いきなりコレです。

ソフトウェアテストは本質的に制約だらけで力不足

ここに、著者のスタンスが詰まっていると思います。
テストには長年の知見の蓄積があり、学ぶべきことは多い。しかしそれでもなお、全然、力が足りてない。 ひるがえって、だからこそ、テスト以外の部分と補完し合って品質を創り上げていく必要がある、としています。
そのため本書には、「テスト以外のところでどのように品質を積み上げるか」 という記述が豊富にあります。それは設計や実装のこともあれば、チームやそれ以外のステークホルダーとの協働のこともあります。「力不足」だからこそ、「テスト以外」にも積極的に言及していく。これは本書の大きな特徴です。

メリットとデメリットを併記する

テストにはいろいろなプラクティス・技法がありますが、それぞれにメリットとデメリットがあります。本書は、デメリットの説明にしっかりとスペースを割いています。実践しているからこそ得られる知恵と言えるでしょう。「バッドプラクティス」の節も充実しています。
また、旧弊的で形骸化した品質保証部門への警告を発しながらも、「古いから悪い」というスタンスではありません。蓄積されてきた知に敬意を払いつつ、モダンな開発への適用を考えていくという、バランスの取れた記述になっています。

具体例を通じて理解を促進する

抽象的な記述に対してはかならず、「たとえば」と具体例を出すのを心掛けているのがわかります。抽象的に「ああすべき」「こうすべき」だけ書かれても、読者の意識には残りません。実践を通じて得られた具体例を付すことで、読者の理解が進みます。 また挙げられる例も、組込み系、Webサービス、スマホアプリなど、バランスよく取り上げているように感じられます。

この3つの特徴はすべて、「文章量を増やす」 ことにつながります。それは著者にとっても出版社にとっても厳しい選択だと思います。テストのトピックのみを扱い、良い点ばかりを書き、抽象的な記述に終始していれば、書くのはもう少し楽でしょうし、フォントも行間も大きくて手に取ってもらいやすい本にできるでしょうから。
でも、そうしない。そうしなかった部分がそのまま、わたしにとってのこの本の大きな価値です。

誰にオススメするか

以上のような特徴を持つ本だからこそ、気軽に 「この本は誰にでもお勧めできます！」 言いたくないのですよ。テストの世界に親しんでいない人が真正面から突破しようとすると、その情報濃度に圧倒されてしまいかねないためです。
たとえば、こんな読み方がいいのではないでしょうか。

テストの世界をこれから知ろうとしている方は‥
  1. 先に、より入門的な本でソフトウェアテストの全体観を把握する
  2. 本書で、特に興味のある部分から粗読していく
  3. 隣接する章に手を伸ばしていく

ただし、知りたいトピックがすでに明確になっているなら、2から始めても問題ありません。
また、「この本がそばにあれば、テストのことを調べたいときにすぐに調べられる」という安心感はデカいです。とりあえず買っておく、はアリです(笑)。

テストの世界にすでに入っている方は‥
  1. 本書全体を粗読する
  2. 一番気になっている部分から精読する
  3. チームに持ち帰って議論する

おそらく、3はかなり盛り上がると思います。小さい章でも、得られる情報量はデカいので‥。

最後に

「安易に読み流させてくれない」と書きましたが、実はわたしはまだ全体を「読み流」ししただけの状況です‥。ですが今後、この本を文字通り「座右」に置き、事あるごとに精読を進め、井芹さんの血肉を自分にも取り込んでいきたいと思います。

ステマ的になるのを避けるため最後に書いておくと、わたしは本書のレビューに参加させていただき、本書もご恵投いただきました。
レビュー期間に見ていたテキストから大きく印象の変わっている部分もあり、レビュー後も大変な労力を注ぎ込んで、書籍としての品質を向上させたことが伺われます。 井芹さんのこの大作にわずかでも貢献できたことは、わたしにとって大きな誉れです。 どうもありがとうございました。

ISO/IEC 25010:2023 と ISO/IEC 25019:2023 の日本語勝手対訳

品質特性

ISO/IEC 25010 は、ソフトウェアの品質モデルに関する規格です。SQuARE（Systems and software Quality Requirements and Evaluation）とも呼ばれています。
旧版の ISO/IEC 25010:2011 は、JIS X 25010:2013 として日本語化されているのですが、最新版である

の2つはJIS化されておらず、定訳がありません。そこで、「こんな感じかなー」という対訳（解説ではないです）を、井芹さんと一緒に作りました。
コメントを開いていますので、何かあればお気軽にどうぞ。（あんまりこまめにみないと思いますが‥）

docs.google.com

ついでに、AIシステムの品質特性の方も（一部）作ってあります。何かのご参考になれば。

雑感

井芹さんからいただいたコメントを見てあらためて思ったのですが、品質特性の定義は「degree of …」、つまり「●●の度合い」とされているものが多いです。なので、たとえば User Engagement という副特性は「ユーザエンゲージメント」そのものではなく「ユーザエンゲージメントを実現している度合い」を指すことになります。

対応する日本語としては、「●●性」「●●度」「●●さ」などがあり、既存の対訳を考えるとやはり「●●性」を選ぶざるを得ません。
正直、「フェールセーフ性」というのはスッキリとして日本語ではないのですが、これは致し方ないところかなと思います‥。

参考