人為的にバグを挿入することでバグの総数を予測する「池の中の魚」モデル 58
ストーリー by hylom
その作業をテストケースをたくさん作るほうに振り分けるべき 部門より
その作業をテストケースをたくさん作るほうに振り分けるべき 部門より
insiderman 曰く、
ソフトウェア中に存在するバグの総数を予測するための方法として「池の中の魚」モデルというものがあるそうだ（@IT）。
この方法は、デバッグ前にデバッグ担当者に分からないように意図的にバグを挿入することでバグの総数を予測するというもの。デバッグ作業後、発見されたバグの数から全体のバグ総数を推測するという。たとえば10件の意図的なバグを挿入し、発見されたバグの数が20件、そのうち意図的に挿入されたバグが5件だったとすると、全体のバグのうち50％が発見された、と判断できるという。
ただし、よく知られているとおりバグのないソフトウェアは存在しない。そのため、この手法の有効性については疑問の声が多く、実際に使われているケースは少ないようだ。
つーかさ (スコア:3, すばらしい洞察)
>プロジェクトマネジャーは、各プログラマーに分からないよう、集めたソースコードに、無理やりバグを埋め込みます。この「人工バグ」が先の「尻尾の赤い魚」に相当します
これできる優秀なプロジェクトマネージャという生き物に出会う確立はUFO捕獲と同じだろ
Re:つーかさ (スコア:2)
機能的なバグなら日々の回帰テストで判明する話ですし、非機能的なバグなら顕在化しにくく仕込む意味が殆どありません。
仕様や設計上のバグなら、仕込んだPMや上流の責任になります。
しかもバージョン管理で誰がやったのかもバレます、何故修正したのかコメントも読めます。
＃これを実践したPMって、社内からも顧客からも爪弾きにされますよ。
ホントに誰得なのでしょうね。
Re: (スコア:0)
労多くして功少なしですね
Re: (スコア:0)
運用的にも現実的じゃないね。
これが可能なら、どんなソース管理してるのよって話になるし、事前バレでも事後告白でも
埋め込まれた担当者のモチベーションは低下する。
バグ疑惑に対しても「埋め込みじゃねーの？」と感度が鈍くなる。
この方法を考えた人は、馬鹿だと断じます。
実践した人も馬鹿だが・・・だぶん、ほとんど事例はないんじゃないかと。
Re: (スコア:0)
管理システムにならされた鴨は、どんどんバカになっていくよね。
下々に教えないで、上司が評価するだけだよ。
# このセクションがまだバグが多いなとか
Re: (スコア:0)
あれ？
テスト前はちゃんと動いていたのに動かなっくなってる！
↓
Diffを取る
↓
人為的バグ全つぶし
となるのが予想できるのだが…。
何を今更？ と思ったら、連載か (スコア:3, 参考になる)
こんな古いものを…
父さん、酸素欠乏症にかかって…
と思ったら、連載講座か。
「池の中の魚」なんて名前がついているのは知らなかった。
ちなみに次回予定の2チーム手法ってのは、
最初の一定期間2つのチームA,Bで同時にテストして、
共通して発見されたバグと、Aだけ、Bだけに発見されたバグの比から、全体を見積もる手法の事。
これならわざわざバグを仕込む必要がない。
Re:何を今更？ と思ったら、連載か (スコア:1)
まあ、バグを統計的に扱って何とかしようというこの手のネタは、実用になった物から身も蓋も無い物まで幅広いですし。 特に実用にならなかった物に関しては、プログラミングで飯を食ってる人でもまず目にすることは無いので、 そんなアイデアが有ったのか! タレコまなきゃ! ってなるのもしょうがないかと。
裏を返せば、その手の人の集まる飲み会なんかでネタにするには最適な話題だったりするんじゃないかと。
Re: (スコア:0)
基本情報試験に乗ってるレベルですからねー
Re: (スコア:0)
「基本情報試験にしか乗ってないレベル」の間違いじゃね？
実用性ないからなあ。
Re:何を今更？ と思ったら、連載か (スコア:1)
知識のための知識というか、
それこそ次の「2チーム手法」を教えるためだけに教えるような踏み台ですよね。
エラーシーディング (スコア:3)
これは一般的にエラーシーディングと呼ばれる技法だと思います。…、と以前にも/.Jで言及して [srad.jp]いました。
「池の中の魚」モデルという名称よりもエラーシーディングの方が一般的な名称ですし、山浦氏が知らないわけがないのですが何か意図があるのでしょうか。それともエラーシーディングとは別物か。
Re: (スコア:0)
意図的にエラーを入れて発見率を測るのは、検証品質を推定するのに使うものだと思っていました。
この記事の方法だと、検証対象の品質を測るのに使うとなっていますね。
どっちにせよ、指標として使えるようなバグの作成は難しいと思いますが、作成方法は確立されているのでしょうか?
無駄無駄 (スコア:2, すばらしい洞察)
だって設計者とデバッグ担当者が同一人物なんだもの
「ただし、よく知られているとおりバグのないソフトウェアは存在しない。」てのが尼杉 (スコア:2, すばらしい洞察)
Re:「ただし、よく知られているとおりバグのないソフトウェアは存在しない。」てのが尼杉 (スコア:1)
正しくは、「バグが無いことを確かめる手法がない」、ということでしょうね。いわゆる悪魔の証明というやつです。
これを馬鹿正直にやろうとするのがカバレッジ率に基づく単体テストということになるのですが、これとて仕様のバグ等は取れません。また、効率が悪過ぎで、ひと目で問題の無いと分かるコードでも何通りものテストケースが必要になります。バグを効率的に取るというよりは、テストをやったというエビデンスを出すことが目的化しているように感じます。
Re:「ただし、よく知られているとおりバグのないソフトウェアは存在しない。」てのが尼杉 (スコア:2)
それは「テストだから」じゃないですか?
一部の形式手法ではバグがないことを保証できますよ
# ただしバグの定義を書け!とか鬼畜な要求をされますけどね!
Re:「ただし、よく知られているとおりバグのないソフトウェアは存在しない。」てのが尼杉 (スコア:2)
こんなところで解説してもしょうがない気がしますが,
形式手法の場合は,
・「うまくいかない挙動」を定義し, 目的のシステムからそれが発生しないことを数学的に示す
・うまくいくところから開始し, 起き得る動作が全て正しい動作であることを示す
のどちらかが用いられます.
前者の代表選手はモデル検査で, 後者の代表は証明によるソフトウェア構築(形式仕様記述も含む)でしょう.
モデル検査がそれなりに成功しているのは,
マルチシステムにおいてデッドロックが発生しないことを機械的に検査できたり,
例外動作の発生パスを機械的に限定できるから.
例外動作について言えば,
それが本来発生してよい実行パスと, 想定していない実行パスがあったときに, 後者はバグになるでしょう.
モデル検査においては「想定しているパス」を実行パスの全集合からそれを除外するだけで定義できるので, 十分に実用的です.
# もちろん簡単に定義できないバグというのももちろんありますよ
自動テストとの違いは,
モデル検査が異なる抽象度で検査の計算量が小さくなるように行われるのに対し,
テストの場合には必ず具体的プログラムで行われるため,
テストの実行時間が大きくなります.
じゃあ何も勉強してない人が形式手法が使えるか,
というと, もちろんそんなことはない.
なので使い分けとか役割分担が必要になる.
それを考えずに, 「産業界では使えません. 実用的ではありません」と断じるのもおかしいよね
# Rubyは中学生にも書けるのにJavaは書けない. Javaは実用的じゃない, と言うのと一緒
Re: (スコア:0)
かと。IC内部のマイクロプログラムとか、ライフサイクルを通してバグが顕在化しないソフトウェアは沢山在り、その内の何割かは本当にバグは無いのです。
ほんとそう思う。
バグがないソフトウェアはないって、言い訳じゃないの？
Re:「ただし、よく知られているとおりバグのないソフトウェアは存在しない。」てのが尼杉 (スコア:1)
いい訳であると同時に、運用側の心構えだね。
作る側は言っちゃダメ。システム運用は問題発生時の影響度が大きいから
バグのないシステムは無いと想定して、運用しないといけない。それがバグのないソフトは存在しない、ということば。
開発担当が言えばただの言い訳でしょ。
Re: (スコア:0)
それだけコストと時間をかけて世に出されるソフトウェアは稀なのです。
# 簡単に差し替えできるってことは品質を落とす理由になりえるんです……
バグ埋め込み法 (スコア:1)
と何が違うの？
Re:バグ埋め込み法 (スコア:2)
バグ埋め込み法そのものだと思います。
「池の中の魚」って名前を付ける事で教えやすくする。デザインパターンみたいなものですね。
あとは、お客様に説明するとき、
「弊社では『バグ埋め込み』によってテスト品質を確保しております」
なんて言えないよなあ、とか。
Re: (スコア:0)
名前が違う。
前提が無理 (スコア:1)
あらゆるバグの発見の容易さと修復の容易さが一様だという前提が必要。
極めて発見が困難なバグが一件入っているときに1000個の人口バグを挿入して1000個の人口バグをつぶせる
開発チームがあったとしても、やはり100%のバグは残留する。
Re: (スコア:0)
たのむから仕事では小学校で習うことのtypoは指摘させないでくれよ。
Re:前提が無理無理無理無理無理無理無理無理 (スコア:0)
違うよ、全然違うよ。
きっと人-ロバグ（hito-ro-ba-gu）っていう新しい何かなんだよ。
しばらく前にいたろ？yama-rorieって女の子芸能人。あれと同じ。きっと。たぶん。
Re: (スコア:0)
#2277377は、主張のサンプルそのものなわけだよ。
もっともキミのように「人口」に気づいただけだと、発見率は100%にはならないわけだがwww
バグって独立して存在するものじゃないんだけどな。 (スコア:1)
バグの陰にバグとか、バグがテスト自体をブロックするとか。
デバッグして修正不十分とか今まで動いていた所を壊すとか。
そういうことを考慮しない手法は現実的ではないな。
バグを仕込むのはいいけれども (スコア:1)
じゃあそのバグに対処する方法というのも何通りもあるので、
バグを仕込んだ、発見された、当初と違うところで修正された、という場合に
ピンポイントでコードを見るとバグの原因と想定して入れたコードが残っていても、
実際にはほかのところ(もっと下やもっと上)で修正されており、
「今度はわざと入れたバグのコードを修正しちゃうことがエンバグのリスクになる」と思うのですが・・・。
テストが行われていることを担保するためなら最終成果物のバグは平均して増えてもいい、
という最上層部から末端まで一貫した割り切りがない限りは
無駄なことやって問題増やしてるだけだと思います。
テスターへのプレッシャーにもなる (スコア:1)
テストのパフォーマンスが数値的に評価できるということで、テスターを奮起させる効果が期待できそうです。プログラマーとテスターが別人の場合に効果が期待できそうです。テスト設計者は漏れのないテスト設計を心がけるでしょうし、テスト担当者も注意深くテストすることになるでしょう。
ただし、人道的な問題があります。もともとはテスト工程の進捗の評価基準でしかありませんが、結果が独り歩きしだすと、テスター自身の評価として使われる危険性が出てきます。こうなると、テスターの関心は本来のバグではなく、挿入されたバグに向かうことになるでしょう。バグ挿入者がテスターに攻略される(考え方が看破される)と、挿入されたバグに特化したテストばかりやられて、本来のバグが放置という本末転倒な結果になりかねません。また、バグ挿入者も、仏心あれば、発見困難なバグの挿入をためらうということにもなるでしょう。
評価結果の詳細はプロジェクト内の極秘データとして人事評価者には漏らさないという管理が必要になるでしょうが、そこまでの公正さを持つ(という信頼を得ている)プロジェクトリーダーがそうそういないでしょう。銀の弾丸は無いのです。
一般論として、相互不信に基づく職場(減点法)と、相互信頼に基づく職場(加点法)、どっちで働きたいかということを考えれば明らかであり、前者の職場ではこういった本末転倒なことが起きかねないわけです。従来のソフトウェア工学は前者に基づく手法が大半であり、今回の手法もそれに分類されるでしょう。それに対するアンチテーゼとして、デマルコのピープルウェアや、XPが提案されているわけです。これらは、後者の「信頼に基づく職場環境こそが真の生産性を生み出す」と訴えているのです。
開発手法とか規模とかも加味して欲しい。 (スコア:1)
どうやって作ったか、どんな人が作ったか、どんな言語でつくったか、全然加味されませんよねこういうのって。
# yes, fly. no, fry.
昔からあるネタ (スコア:0)
セキュリティチェックのテストで本物の麻薬だか爆弾を入れたら、見つからずにそのまま航空機に積まれて出発してしまったそうですな。
# 20年ぐらい前の本で読んだ。
Re: (スコア:0)
2000年代にもありませんでしたっけ？
フランス（？）の空港で訓練のために客の荷物にランダムに爆弾を入れたら…ってやつ。
信管は抜いてるらしいけど。
テストチームの発見率 (スコア:0)
デバッグテストチームのバグの発見に関する率を求めるのには良いかもしれないけど、毎回毎回仕込んでいたら
単にデバッグ、テスト、検収系のコスト増やしているだけじゃないの？
Re:テストチームの発見率 (スコア:1)
そもそも、「埋め込んだバグ」とやらがよほど精巧なものでなければ、意図的に埋めたバグなんて早々に発見されるでしょう。
「人為バグは100%発見できてます完璧です」
客「バグ出たぞ」となるのがオチ。
テスターを放り込む会社があればその品質を示すことになるかも知れませんが、そんなことは「テスターのテストプロジェクト」でも作ってそこでやってくれ。
で、「竹：費用は安いが発見率50%のチーム」「松：費は高いが発見率80%のチーム」どちらになさいますか？
客「竹の値段で100%のやつよこせ」
ですよね。
Re: (スコア:0)
わざわざバグの数を推測するのだから、「どれだけデバッグするか？」の最適解を探すのが目的なんだろうけど。
バグの数と製品品質は別物だし、それを基準にされてもね・・・
くそっ、バグを埋め込む時間がねえ！！ (スコア:0)
この方法を取る余裕があるんだったら、バグはもっと少なく出来るよぉ……
# 「これ間に合わないっす」「んじゃ、それ埋め込むバグってことにしとけ」
# こんな使われ方をするだろうからね
これって情報処理技術者試験の定番 (スコア:0)
午前問題で良く出るよね。
「斬新なアイデア」なんて感じるとしたら、基礎知識に問題があるような気が・・・・
Re: (スコア:0)
あまりに前時代的で非実用的だから、まともな大学出てるとかえって目にしないんだよ。
そういう非実用的技術っていくつかあるけどね。
有名どころだとフローチャートとかファンクションポイント法とか。
もっと単純に考えて (スコア:0)
どれだけのバグを仕込めば。信頼できる値が取り出せますか？
バグ1件だけ仕込んでも意味がないわけで。
Re: (スコア:0)
この場合は統計的に考えて2000件もあれば…
# ♪トリビア～
これって (スコア:0)
高校の生物で習ったよ。
標識再捕獲法だね。
Re:これって (スコア:1)
標識再捕獲法の場合はもともとフィールドにいた特定種の生物個体を何体かいったん捕獲し標識をつけて野に放ち、ふたたび捕獲した同種生物個体中の標識済個体数の割合から全個体数を推定するでしょう？
バグの埋め込みはしない方法ということになるので、minet (45149) さんのコメントにある２チーム手法が標識再捕獲法に近いものではないですか。
もっとも標識再捕獲法では捕獲の技量は等しいことが暗に想定されているから、２チームの技量の差があるとバグの全数の推定ではなくなり、２チーム手法ではバグ検出の技量の差を比較しているだけということになってしまいそうですね。
この規模のプログラムなら〜 (スコア:0)
これくらいバグが出てこないとオカシイ！
頭の変な(一流w)会社が上流にいたせいで、理論式よりも少ないせいで怒られる・・・
結局、本末転倒なバグ埋め込みマッチポンプをせざるを得なくなりましたよ(７年程前の実話)
Twitter でこんなの見かけた (スコア:1)
バグのないソフトウェア (スコア:0)
>ただし、よく知られているとおりバグのないソフトウェアは存在しない。
勝手に決めつけないでくれるかなバグのないソフトウェアはあるよ
Re: (スコア:0)
有りますね。ただし、限られた分野になりますが。制御系のマイクロプログラムとか精密機器のドライバとか。
理由 (スコア:0)
「バグのないソフトウェアは存在しない」から「この手法の有効性については疑問の声が多」いという論理が分からん。元記事にもそういうことは書かれていないし。
バグの発生原因 (スコア:0)
バグの発生原因が全部網羅されていて、バグの種類によって入れるならいいけど、
人間が意図的に入れるバグは大抵同じものだから見つかり易いでしょ。
そういうものはテストで十分見つかる範囲だと思うけどね。
大体、バグの種類が網羅されているなら初めからバグを仕込まなくてテストだけでいいし、
有効性があるのか疑わしい。