Googleのバグ予測アルゴリズムを実装した「bugspots」のSVN版を作ってみた

先日、Googleのバグ予測アルゴリズムを実装した「bugspots」が公開されました。

ソースコードのなかでバグが多いのは、より高頻度に、かつ最近になって集中的に直している部分。これが、グーグルで採用された「バグ予測アルゴリズム」であることを、先月の記事「グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している」で紹介しました。

そのバグ予測アルゴリズムを実装したツール「bugspots」がオープンソースとして公開されています。

グーグルのバグ予測アルゴリズムを実装したツール「bugspots」、オープンソースで公開 － Publickey

上記ツールは、Gitのリポジトリで管理されているソースのみが対象となっています。

ただ、OSSの開発ならいざ知らず、実際の開発業務では、まだまだSVNの利用も多いことでしょう。

そこで、SVN（Subversion）のリポジトリで管理されているソースコードを対象に解析できる、

bugspots-svn

を実装してみました。


以下のようにして実行できます。

[前提条件]

  • Ubuntu 11.10 で確認。
  • ruby がインストールされていること。


1. subversionのrubyバインディングをインストールする。

$ sudo apt-get install libsvn-ruby


2. 「bugspots-svn」をgithubから取得し、ビルド＆インストールする。

$ git clone git://github.com/takanorig/bugspots-svn.git
$ cd bugspots-svn
$ gem build bugspots-svn.gemspec
$ sudo gem install --force bugspots-svn-0.1.0.beta.gem


3. SVNから解析対象のソースコードをチェックアウトし、「bugspots-svn」を実行する。

$ svn checkout http://wwww.samplerepo.com/svn/trunk /path/to/repo
$ /usr/local/bin/svn-bugspots /path/to/repo
  • ソースコードのパスは、URLには対応していません。チェックアウトした上で、そのローカルパスを指定してください。
  • デフォルトでは、「refs, fixes, closed」などのTracやRedmineで連携する際に利用されるキーワードを含むリビジョンが解析対象となります。特定のキーワードを指定したい場合は、以下のようにしてください。
    • $ /usr/local/bin/svn-bugspots -word "word1,word2" /path/to/repo

これで、一応解析結果は出力されるはず。

ただ、Rubyは久しぶりに使った＆初心者なので、正しく計算されているのか、すっごく不安。
いくつかのリポジトリで検証してみたんだけど、結構、値が低く出るんですよね。解析ロジック自体は、元のbugspotsのままなのですが...

「グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している − Publickey」で示されている式を利用した計算結果と一致するか、検証する予定ですが、現段階では、計算結果は保証できませんｗ

検証して頂けた方がいれば、ぜひ、ご連絡くださいm(__)m

2012/01/16 追記


リビジョンの取得方法に問題があったので、修正しました。
これで、大丈夫（なはず）。

The End of Advent Calendar

このエントリーは「Software Test & Quality Advent Calendar 2011」における最後のエントリーとして書いています。

トリとなったエントリーは、 numeha さんによる「ぼくのかんがえたSoftware Test & Quality」でした。

延べ22人による27個ものエントリーにより、12/1より開始した、この Advent Calendar も、無事（？）12/25まで続けることが出来ました！！

ご協力頂いた皆さん、ありがとうございました m(__)m
無計画にはじめたものですから、特に最初の頃に書いて頂いた人は大変だったのではないかと...


12/1の前日である11/30にふと思い付き、「Software Test ＆ Quality Advent Calendar 2011」を開始しましたが、自分自身のエントリーに関して、いろいろな方からコメントを頂いたことも刺激的でしたし、他の方のエントリーを見て、勉強になったことも多かったです。

特に、この Advent Calendar は、要素技術的な内容では無かったため、執筆者それぞれの思想が色濃く表れており、それがまた、面白いモノになっていたように感じています。


執筆者の方々には、私自身まだお会いしたことがない人が多いのですが、どこかで一緒になる機会があれば、ぜひ一声掛けて頂ければ、と思っております。


それでは！！




... と思ったら、大事な連絡忘れてた（汗）

この Advent Calendar は、技術評論社の電子出版サービス「Gihyo Digital Publishing」により、2012年1月中旬に、電子出版コンテンツとして配信される予定です。
まとめ読みしたい方は、ぜひ、そちらをどうぞ！

JaSST 10th Anniversary

Test

このエントリーは「Software Test & Quality Advent Calendar 2011」における12/22分として書いている。
12/21は kyuumin さんによる「テストとアジャイルについて勉強する中での気付き」というエントリであった。


さて、「Software Test」というタイトルを出しているからには、これについて書かないわけにはいかないだろう。
そう、今回は「JaSST：Japan Symposium on Software Testing」についてのエントリーだ。


JaSSTは、今年でなんと10周年！！！
2003年、東京で始まり、現在では、北海道・新潟・東海・関西・四国・九州と、全国各地で開催されるようになっている。
参加者数も、2003年の東京開催では200弱であったのが、昨年2011年の東京開催では2日間で延べ1600人にも及ぶようになっている。

このようなシンポジウムが、10年継続され、さらに規模も年々拡大されているのは、驚くべきことである。

※私は、JaSSTの実行委員でもなんでも無いのだが、いちJaSSTファンとして今回のエントリーを書いている。

JaSSTとは？

そもそも、JaSSTを知らない人もいるだろうから、簡単ながら説明しておく。

現代社会においてソフトウェアは、まるで空気のごとく不可欠な存在となっています。
空気に不純物が混じったり、濃度に変化があれば様々な障害が発生します。
実際、ソフトウェアの問題によって個人レベルでも社会レベルでも多様な問題が日々、起こっています。
ですから、ソフトウェアを用いる上で、その用途を満たしているかどうかという確認だけではなく、問題がないことの検証も同時に行わなければなりません。
そこには当然技術が求められ、ソフトウェアテストはまさにそのための大切かつ重要な技術の一つなのです。
技術ですから、日進月歩であるべきであり、進化した技術や知識は広く共有されるべきだと我々は考えています。

この考え方に基づき、ソフトウェア業界全体のテスト技術力の向上と普及を目指して、NPO法人ソフトウェアテスト技術振興協会（ASTER）はソフトウェアテストシンポジウム（JaSST ： Japan Symposium on Software Testing）を全国各地で開催しています。

JaSSTソフトウェアテストシンポジウム-JaSSTについて

JaSSTには、ソフトウェアテストに関わる人たちが多く集まる。
言わずと知れた、テストに関する日本最大のイベントだろう。

参加者の立場も、エンタープライズ系、組み込み系、ゲーム系など、様々である。

また、セッションの内容も、各社における取り組み事例発表、論文発表、テスティングライブやテスト設計コンテストなどがあり、非常に得るモノが多い。

基調講演／招待講演

私自身は、2006年の JaSST Tokyo から参加するようになったが、過去の JaSST Tokyo における基調講演／招待講演の内容を示しておこう。
テスト業界における著名な方々が登壇されていることが分かる。

年 基調講演 講演者
2011 Testing Trends and Innovations テスティングトレンドとイノベーション Lee Copeland （Software Quality Engineering ）
2010 Successful Software Management: 17 Lessons Learned 成功するソフトウェア・マネジメント: 17の教訓 Johanna Rothman （Rothman Consulting Group, Inc.)
2009 Emerging Trends in Software Engineering Roger S. Pressman, Ph.D. (R.S. Pressman & Associates, Inc.,)
2008 Software Quality In 2008 Capers Jones（Capers Jones & Associates LLC）
2007 デスマーチ-ソフトウエア開発プロジェクトはなぜ混乱するのか- Ed Yourdon（NODRUOY Inc.）
2006 Identifying Testing Priorities through Risk Analysis Rick Craig（Software Quality Engineering）
2005 Five Trends Affecting Testing Rex Black（Rex Black Consulting）
2004 Management: The Stuff They Don't Teach You Anywhere トム・デマルコ（The Atlantic Systems Guild）
2003 日本と世界のソフトウェア・テストの状況 山浦 恒央（日立ソフトウェアエンジニアリング）
年 招待講演 講演者
2011 「はやぶさ」をミッション完遂に導いたソフトウェア開発 檜原 弘樹 （NEC東芝スペースシステム）
2010 品質という王道を行こう 誉田 直美（日本電気）
2008 軟件製品の品質保証を巡る人間特性の諸問題 菅野 文友 （系統技術研究所）
2007 ソフトウェアテストの展望：SW機能テストから、システム挙動の評価へ 松尾谷 徹 （デバッグ工学研究所）
2006 IT検証産業協会 （IVIA）の紹介
一ケタ高い品質のためのソフトウェアテスト		 浅井 清孝（IT検証産業協会）
保田 勝通（つくば国際大学）
2005 ソフトウェア品質 温故知新 松原友夫（松原コンサルティング）
2004 我が国情報産業の国際競争力 大場 充（広島市立大学）

サイトからは、資料もダウンロードできる。
今回は、東京開催の基調講演／招待講演のみ示したが、他のセッションや、他の各地方の内容も、勉強になるものがたくさんある。
自分が抱える問題意識や興味のある分野の資料をダウンロードして、一読するのも良いだろう。

JaSST'12 Tokyo

さて、最後に。
1ヶ月の 2012年1月25日(水)〜26日(木) に、JaSST'12 Tokyo が開催される。

基調講演には、「How We Test Software at Microsoft」の著者であるMicrosoftのBj Rollison 氏、
招待講演では、10周年にちなんでJaSSTの第1回で基調講演を行われた東海大学の山浦 恒央先生 が登壇される。
http://jasst.jp/symposium/jasst12tokyo.html

また、今回は『10周年記念誌』が発行されるようだ。
過去、基調講演や招待講演をして頂いた方や、全国のJaSST実行委員長からのメッセージや、ソフトウェアテストのこの10年間の変化などもまとめられているようだ。

これは、ぜひ、私も Get したい！


これまで参加されたことが無い人も、ぜひ一度、参加してみてはどうだろうか？

循環的複雑度を活かしたバグ潜在リスクの軽減

PM Test

昨日のエントリーに引き続き、このエントリーは「Software Test ＆ Quality Advent Calendar 2011」における12/19分として書いています。

今日は、少しばかりアカデミックな話。
でも、うまく活用すると、品質改善のための強い武器になることでしょう！

循環的複雑度とは？

まずは、今回のタイトルにも書いている「循環的複雑度（Cyclomatic Complexity）」というメトリクスの説明から。

循環的複雑度は、Thomas McCabe 氏が開発したものであり、簡単に言うと、コードの複雑性を数値化したものです。

ソースコードの一部の循環的複雑度は、ソースコード内の線形独立な経路の数である。実際、if文やfor文のような分岐点のないソースコードの場合、その複雑度は 1 であり、そのコードには1つの経路しかない。コードに1つのif文が含まれていれば、コードには2つの経路があることになる。つまり、一方はif文での条件が真となる場合の経路で、もう一方はそれが偽となる場合の経路である。
（中略）
一般に、あるモジュールを完全にテストしようとした場合、全ての実行経路を通す必要がある。これの意味するところは、循環的複雑度の大きいモジュールの方が経路数が多く、従ってテストケースも多く必要になるということである。また、複雑度の大きいモジュールは、ソースコードの意味を理解するのに多くの経路を追わなければならず、読解がより困難になる。

循環的複雑度 - Wikipedia

まあ、細かい話は置いておいて、以下では、循環的複雑度が何の役に立つかを説明しましょう。
（アカデミックな話と言いつつ、複雑度の計算式などの話は飛ばします...）

「循環的複雑度」が何の役に立つのか？

1. バグ混入の確率を減らす

循環的複雑度の値に応じて、そのプログラムのバグ混入率は、以下のようになるそうです。

循環的複雑度 複雑さの状態 バグ混入確率
10以下 非常に良い構造 25％
30以上 構造的なリスクあり 40％
50以上 テスト不可能 70％
75以上 いかなる変更も誤修正を生む 98％

実際にコードを書いてみると、「10以下」を徹底するのは難しいのですが、きれいなコードを書いていけば、「30以下」は十分に徹底できるレベルです。

上記のような指標値を基にリファクタなどをしていくと、バグの混入自体を軽減することができます。

2. xUnitのテストケース数の指標となる

循環的複雑度は、プログラムの経路の数から算出されるので、実は、

　循環的複雑度 ≒ C1（分岐網羅）の経路数

と言うことができます。

そのため、循環的複雑度を利用すると、xUnitのテストケース数が、妥当かどうかを評価するための参考になります。

3. バグの修正スピードが向上される

過去に循環的複雑度の影響を調査したところ、「複雑度が30以上のコードがいくつもあるプロジェクト」と、「複雑度が30以下を徹底したプロジェクト」では、バグの修正スピードに大きな違いが見られました。

バグの発生から解決までの時間を「バグTAT（Bug Turn Around Time）」と呼んでいるのですが、この値が、前者では3〜5日程度かかったものが、後者では、1〜2日程度となっていました。

数プロジェクトでの検証ではあるのですが、構造がシンプルになる分、バグの修正スピードも向上されるようです。
バグ修正の時間が、約半分になることを考えると、大きなメリットですよね。

循環的複雑度を測定するツール

循環的複雑度は、静的解析のひとつに含まれますが、そのメトリクスを測定・活用しているプロジェクトは、あまり見ないですね。

でも、フリーで利用できるツールもたくさんあるので、利用しないのは損ですね。

私は、Javaで開発することが多いので、主に以下のツールを利用しています。

JavaNCSSには、AntタスクやMavenプラグインもあるので、自動レポートにも利用できます。

循環的複雑度は、言語によってツールが違いますが、メジャーな言語ならば、大抵フリーのツールがあるので、利用してみると良いと思います。

最後に

循環的複雑度自体は、新しいものではないのですが、知らない人も多いようです。
自分自身の実感として、循環的複雑度をうまく活用すると、コードの質が非常に上がりますよ。

ぜひ、自分のプロジェクトで試してみてください。

品質に厳しい組織で、なぜ品質が劣化するのか？

PM Test

このエントリーは「Software Test ＆ Quality Advent Calendar 2011」における12/18分として書いています。
12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。


今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。

特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる／苦しんでいるような人から、うまく伝われば良いと思っています。

矛盾する問題

私は、SEPG（Software Engineering Process Group）という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。
絶対数で言えば、そんなに多くはないかもしれませんが、その経験上感じているのは、このタイトルの通り、

品質に厳しい組織で、なぜ品質が劣化するのか？

ということ。

レビューを強化したり、テストを強化したり、品質分析を強化したりと、いろいろな対策を打っているにも関わらず、品質が維持されるどころか、劣化することがあります。

この原因について、私なりの答えを書くと、

プロジェクト／組織の体制に問題がある

と思っています。

どこの組織でもある程度の規模になれば、品質保証という活動が出てくると思います。
典型的な例として、「バグ密度などの指標を決め、品質見解などを求める」、ということがありますが、結果をチェックされるために、それを求められる開発側は、適切な取り組み／分析をするよりも、指標値の範囲内に収めよう、という思考が働くのです（本末転倒）。
そうなると、品質の良いモノを提供しようという意識も弱くなり、大概は、それなりに良く見える品質レポートを提出して納得する／させる、ということになるのです。

「よくある話」と思う人も多いかもしれませんが、品質を厳しくチェックするがために、品質が劣化する、という矛盾には、開発者も品質担当者も悩んでいる状況が続いている現場は多いのではないでしょうか？


ここまで読んで「だからTDDしよう！」などと思われる人もいるかもしれませんが、私の考えでは、それでは根本解決はしないと思っています。
TDDでカバーできるのは実際的には一部のテストですし、そもそも、同じプロダクトやサービスを提供する関係者が、敵対関係のままであるのは、解決したいところなのです。
アジャイルでは「協調」が大事にされていますが、顧客だけでなく、開発チーム／組織の中でも、同様に大事ですよね？

体制のリファクタ

さて、ここからが本題。
私自身、試行中ですが、上記のような問題をどうすれば改善されるか、を考えています。
その結果、必要だと考えているのは、以下の3つの転換。

1. 「品質保証」ではなく「品質支援」を

まず「保証」という言葉が良くない。なので「品質保証」という言葉も部署も、無くしてしまいましょう。


※全国の品質保証の方、ごめんなさい m(__)m
※でも、実力のある品質保証の方って、実際的には、保証だけをしているのではなく、開発が成功するよう、積極的に支援していると思うんですよね。


「保証」と言われるがために、品質保証側も、その後問題が発生したときの責任を考えてしまい、形式的な指摘や粗探しをしてしまうのではないでしょうか？
責任は、プロジェクト全体で分担するのが適切で、だからこそ、プロジェクトが成功するよう、品質エンジニアも開発エンジニアを支援するし、開発エンジニアも品質エンジニアにアドバスを受けるかたちが良いと考えています。

実際には、

  • 設計やテストケースの検討を一緒に行う
  • 品質エンジニアは、開発エンジニアが自動テストを行いやすいよう、支援する
  • メトリクスを開発エンジニアが収集し、分析は品質エンジニアが行う

といった活動が必要でしょう。

2. 「やり直し」ではなく「フィードフォワード」を

品質に問題があると、強化テストや、レビューのやり直しを求められることってありますよね？
でも、あれって大抵うまく行きません。

なぜかというと、そもそも、自分たちが分かっていなかった部分で問題が出るのであって、それが分からないメンバがやっている限り、いくら時間をかけても無駄です。

工程毎や、イテレーション毎で、なんらかのチェックをするのは重要だと思います。
ただ、その結果、やり直し作業になるのって、モチベーションも下がりますよね。

問題があれば、次の工程やイテレーションで何をすべきか、フィードフォーワードを行うべきだと思います。
そもそも、過ぎた時間は戻らないし。

設計漏れや試験漏れがあったとしても、その後の工程やイテレーションで、何をすべきかに注力して考える方が建設的だと思いますし、そのために、品質エンジニアは適切にアドバイスできるだけのスキルが必要だと思います。

3. 「レビュー」ではなく「検討会」を

最近、「レビュー」は難しいなって思っています。
レビューは、なにかしら「できたモノ」を評価することになりますが、人間、できたモノがあると、そこのフォーカスで物事を考えがち。そうすると、重要であっても書かれていない部分の問題は、見逃してしまいがちなんですよね。
スキルのある人は、当然そのようなことはないですが、必ずしもそのような人ばかりでないのも現実です。

そのために、私は「検討会」を勧めてます。

  • プロジェクトの進め方
  • 設計の内容
  • テストの観点抽出

など、レビューをする前に、検討会で考えを出し合う方が、内容も良いモノが出来上がりますし、トータルな時間も節約できると感じています。

最後に

最近では、「DeveloperTest」と「QATest」のように、開発エンジニアが行うテストと、品質エンジニアが行うテストが区別されてしまっているケースもあります。

本来は、良いプロダクト／サービスを提供する、という部分で目的は共通だと思っているのですが、歪んだ品質管理／品質保証のやり方により、おかしい部分が生まれてきてしまっているように感じています。

私は、今でも、「開発者」「品質管理者」「プロジェクトマネージャ」と、複数の役割を持っています。実際の仕事も、コーディングもしますし、他プロジェクトの品質管理もしますし、OSSやフレームワークの提案などもしています。

今回、それらの役割が決別するような状況は変えていきたいと思って、今回のエントリを書きました。