ソフトウェアテストシンポジウム (JaSST 08) に行ってきた(初日のみ)
JaSST 08 に行ってきました。去年は2日間参加したけど、今年は初日の30日のみだけど、チュートリアルを受講してみました(会社の金で)。それも含めて、個人的なメモを残しておきます(あくまで、僕視点のまとめです)。
基調講演
SPR の Capers Jones 氏による基調講演。タイトル「Software Quality in 2008」、幅広すぎ。。
- 万国のいろんなプロジェクトから集めた品質指標のまとめが中心
- 不具合*1除去効率が大事
- 「リリース前に見つけた不具合」 対 「リリース後の不具合」
- 不具合の原因となるのは、コーディングだけじゃない
- FP(Function Point) を使おう。LOC(Line of Code) よりも
- LOC はコードがないと計測できない(上での、コーディング以外のバグに起因する数値をはかれない)
- 統計的な平均値で、変換可能 (例: C言語だと 128 LOC = 1 FP, C++ だと 50 LPC = 1 FP, など)
- FP での規模感覚をつかむための参考として、世の中のプログラムが大体どれくらいのFPか*2
- Windows Vista は 160,000 FP くらい
- Microsoft Office は 100,000 FP くらい
- SAP とかは 300,000 FP くらい
- ケータイ(の制御ソフト？) は 15,000 FP くらい
- iPhone は 20,000 FP くらい
- iPod は 5,000 FP くらい
- 車の制御ソフトは 3,000 FP くらい
- 飛行機の制御ソフトは 25,000 FP くらい
- "Error-Prone Module" …全体の5割のバグの原因となっているモジュール
- 50％以上のバグが、5％のモジュールによって発生しているという統計も
- そういうモジュールは取り除き、置き換えるべき (必ずしもできる気はしないが…)
- 要求仕様がどれくらい膨れたのかもFPで計れる
- 不具合除去率は、CMMレベルの高い組織ほど高い
- 最近、CMMレベルの高い企業が多いのはインドという話
- 「FPあたりの不具合率」と「不具合除去効率」を軸とした表に、自分のプロジェクトをプロットしてみよう
- 不具合率が 3以下で、除去率 90％以上を目指すべき
- インスペクション大事
- テスティング以前の、要件仕様、設計など
- インスペクションによって、各フェーズでの不具合をそのフェーズで検出できる
- 個別のテストやインスペクションだけでは不具合検出は十分にできない
- 各フェーズでの各種テストを総合的に実施しないと、高い検出率は達成できない
チュートリアル
午後に入って、引き続き、Caper Jones氏のチュートリアル。内容はけっこう基調講演ともかぶる部分もあって、それは残念。
- いろいろなインスペクションや機能テストや各種非機能テストなどについて、下記の項目などの統計情報
- どういった種類の不具合をどの程度除去できるか
- FPあたりどの程度の時間がかかるものか
- FPあたりどの程度テストケースが必要なものか
- テストプランとテストケースのインスペクションは、やってないなら是非やるべき
- 膨らんだ要求仕様は、元の要求仕様より、潜在的な不具合が含まれる率が高く、バグ除去効率が低い
- FP の 1.25 乗で、平均的な潜在不具合数が算出できる
- たとえば 100 FP なら、およそ 316 の潜在的な不具合があると見積もれる
- CMMレベルが高ければ、1.25 よりも少なくはなる
- FP の 0.25 乗で、必要な修正フェーズ回数を見積もれる
- 100 FP なら、およそ 3
- FP の 1.2 乗で、最大必要なテストケースの数を見積もれる
- 100 FP なら、およそ 251
- 最小限必要なテストケースを見積もりたいのであれば、 1.05 乗をかける
- FP の 0.2 乗で、テスト実施回数を見積もれる
基調講演＆チュートリアルを受けての個人的な所感
基調講演の最後で、「これからの課題」みたいな項目に「自動テスト」とか「アジャイルプロジェクトのデータ」とか、個人的にキーワードになりそうなところが入ってて、へこーッとなりました。つまり、全体的にウォーターフォールモデルを前提とした話のようで、そのあたりはかなりビミョウ。。
チュートリアルの終わりで、質問者が「たとえばユニットテストのテストケース内容を修正して再度テストを実施した場合、それぞれでひとつのテストステージとカウントするのか、それとも合わせてひとつなのか？」といった質問をしたら、「なぜ同じテストを繰り返すのか理解できない」といったようなことを言っていたので、完全にウォーターフォール脳のような印象を受けました。(単純に、質問を誤解していたのかもしれませんが。。)
あと、テスト以外の、インスペクションやレビューでの不具合検出率をはかるためには、そこで見つかった不具合を個別に記録しなければいけないけれど、そのコストがけっこう高そう。
ただ、テストによるバグの検出率は今のうちのサイクルでも算出できるはず。あとは、本番バグの原因分析(仕様バグなのか、テストでの見落としなのかなど)や、メジャーリリース後のバグFixリリースでどういった項目を今まで対応してきたのかの確認などは、もうちょっとちゃんとやろうと思いました。
セッション D4 「テスト設計かじり虫」
残りの時間は、D4の小セッション3つを聞く。
「テスト分析の方法 HAYST法とマインドマップを使って」
仕様書から、機能的なカットだけでHAYST法のテストケース作るのではなく、マインドマップを使って顧客視点を盛り込むと、リスクも捉えた充実したテストケースが組めるよ、という話。顧客視点で見たときに現れる内容は暗黙知であり、経験であるが、マインドマップの各枝を知識ベースとして蓄積することで共有できる。それによって、これまでは障害として報告されてはじめて分かっていたことが、予測的にケースとして捉えることができるようになる。というような内容と理解しました。
HAYST法でテスト作ったことがないのでアレですが、今後、機能によっては参考にするといい部分があるかも。
「テストの”質”評価と欠陥分析によるソフトウェア信頼性評価」
信頼度成長曲線だけだと、テスト完了判断に使うのは微妙。テスト観点(テストの種類)ごとにテスト件数と検出されるバグ数の見積もりをたてておいて、実際に検出されるバグ数とつき合わせてフェーズごとに見ていくとより精度の高い曲線を得られるよ、という話。と理解しました。
うちも今は、実装する項目×平均検出バグ数という大雑把なかたちでしか見積もりたてていないので、このあたりの精度を上げることを考えるときに参考になるかも。少なくとも、実際に見つかったバグが、意図したタイミングに、意図したテストで出たものなのかどうか？という点はもう少し注意してみていくべきかと思いました。
「不具合に関する知識の抽出に関する研究」
バグの分析をする際、間違ったナレッジを抽出してしまわないようにしたい。そのため、誤解を招くような仕様や設計はアフォーダンスの観点から悪設計だとして、適切な原因分析のレベルに到達できるようにするべき、といった話。
正直、ちゃんと理解できた気がしていません。。プレゼンで紹介されていた例だと、「すでにメニューが表示されているときだけ、メニューボタンを押したときはメニューを表示するのではなく、メイン画面を表示する」こと、開発の際に間違いやすい(常にメニュー画面を表示するように作ってしまう)、といったことを言っていたが、この例だと、ユーザー視点からの仕様として求められているのでは？といった疑問を持ったので、いまいち納得感がありませんでした。
