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

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

ソフトウェアテスト分野のFizzBuzz、「Myersの三角形問題」に学ぶ、テストについての教訓

 テストエンジニアの多くが一度は耳にし、解いたことがあるであろう「Myersの三角形問題」
 社内のソフトウェアテスト勉強会で、n年ぶりm回目で解いてみました。
 この10分ほどのトライを通じて、以下のようなことを再認識しました。

Myersの三角形問題とは

 Myersの三角形問題とは、J. Myers氏の書籍『ソフトウェア・テスト技法』で提示された問題です。

 『ASTER標準セミナーテキスト』から、内容を引用します。
 やってみたことのない方は、ぜひトライしてみてください。

<問題>
以下のプログラムをテストするのに十分と思われる一連のテスト内容(何を確認するか?)を書いてください。

このプログラムでは、ユーザーが3個の整数を入力します。
この3個の値は、それぞれ三角形の3辺の長さを表すものとします。
プログラムは、三角形が、不等辺三角形、二等辺三角形、正三角形のうちのどれであるかを決めるメッセージを出力します。

 一見、シンプルな問題。テストケースなど簡単に導けそうに思えるかもしれません。
 ですがあらためてこの問題を解いてみると、以下の3つのことを再認識できました。

1. 仕様の正確な記述は、とても難しい
2. シンプルな仕様のテストがシンプルとは限らない
3. テストすべき観点やケースの唯一解はない

 順に、説明していきます。

1. 仕様の正確な記述は、とても難しい

 この問題を見て、「そもそも仕様が曖昧なのでは?」と感じる人もいると思います。
 勉強会参加メンバーの一人は、「三角形の定義」から始めて、

ここでいう三角形は、ユークリッド空間における三角形を指すのか?

というところから確認していました。わたしは、こんなこと考えてもみませんでした。

 もちろん、何から何までクリアに、誤解の余地なく記述することはできないでしょうし、過剰だとも言えるでしょう。
 そうはいっても、テストを検討するうえで必要な部分は明らかにしていく必要があります。仕様検討とともにテスト設計を始めることで、仕様をより詳細・具体的に書き下して、両者の認識を合わせていくことができるでしょう。

 それでも、仕様を考える人とテストを考える人、両者が無意識に前提としていることは、議論もされないかもしれません。そしてその前提は、ユーザの前提とは違っているかもしれないのです。

2. シンプルな仕様のテストがシンプルとは限らない

 三角形問題の著名人による解が、辰巳敬三さんのブログで解説されています。テストケースの数は、4個という人もいれば、185個という人もいるそうです。

a-lifelong-tester.cocolog-nifty.com

 また、山浦恒央さんの連載記事*1では、16個のテストケースを提示しています。

monoist.itmedia.co.jp

 わたしの解を山浦さんの解と比べてみると、以下の観点を漏らしていました。

  • #9「2辺の和<残り1辺が長い」はあるけれど、#10「2辺の和=残り1辺が長い」がない。
  • #7「小数2.5」はあるけれど、#8「小数5.0」がない。
  • #14「入力しない」がない。

 まあぶっちゃけ・・・、けっこう恥ずかしいのを落としてますよね・・・。
 さらに先の勉強会メンバーは、こんな観点を教えてくれました。

  • 数式、たとえば「1+2」は、「3」と解釈されて処理されないか。
  • 数式が解釈される場合、逆ボーランド記法「2 3 +」も解釈されないか。
  • eは自然対数として解釈されないか。
  • 「010」が、8進数で「8」と(Java的に)解釈されないか。

 そしてこのような面白い観点を出してくれたメンツをしてなお、「ユーザが許容できる時間内に結果が返ってくるか」「入力しやすい画面になっているか」といった非機能的な観点はあまり出なかったのです。

 このように、誰でも理解できるような単純な仕様ですら無数の観点があるし、人は(特にわたしは)その観点を見逃してしまいます

3. テストすべき観点やケースの唯一解はない

 このように無数の観点があるなかで、どの観点を選び、その観点からどのようなテストケースを選ぶか。
 これは「ソフトウェアテストの7原則」の言う通り、「テストは状況次第」なのですよね。
 JSTQBのシラバス*2から引用します。

状況が異なれば、テストの方法も変わる。例えば、安全性が重要な産業用制御ソフトウェアのテストは、eコマースモバイルアプリケーションのテストとは異なる。また、アジャイルプロジェクトとシーケンシャルライフサイクルプロジェクトでは、テストの実行方法が異なる。

 ユーザが求めていることは何か。どこまでの品質を求めるか。バグによりどんな悪影響が考えられるか。といった外的な要素もあれば、
 入力値の制約はされているのか。どんな言語を使っているか。プログラマーが不安に思っているのはどこか。といった内的な要素もあります。

 状況に依存しないただ一つの解はない。
 その中で、合理的でみんなが納得できるテストを選ぶための活動が、テスト分析とテスト設計です。

 『ASTER標準セミナーテキスト』で、Myersの三角形問題は、テスト設計の解説の導入部分として用いられています。シンプルながらやっぱり、含蓄の多い問題だなあとあらためて思いを深めた次第です。

 しかし「入力しない」を漏らしたのはダメすぎる・・・(一生悔いてる)。

Turner Margate

*1:『ソフトウェア技術者のためのバグ検出ドリル』の元ネタになっています。

*2: 『ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018.J02』