JaSST 2009
JaSST 2009 の感想をやっとでまとめたのでアップロード。
= 基調講演 ソフトウェア工学の動向
カーツワイル氏の収穫加速について、ハイプサイクルもあるんだよという話があった。
CASE: Computer Aided Software Engineering も一時期もてはやされたけど結局ダメじゃね？
みたいな話があったけど、私は CASE には希望があるし、
人工知能については回復期にあるんじゃないかなあと思う。
あとはまあ最近それなりに話題に上がる単語の紹介、という感じだった。
このスライドを見直すことで、研究テーマを探すのには役に立ちそう。
"... the best way to predict the future is to invent it."という言葉を述べた
アランケイは天才だ。
再利用しやすいのは、モジュールのインターフェースが限られているといった、
まあ常識的な結果だった。
= モデル検査の状態爆発への実践的低減策
モデルの順番を並び替えると状態数が減って実行時間が減るとのこと。
そういうことはコンパイルでやってくれないかなあ、というか、この結果がコンパイラ開発に生かされるのか。
= 直交表と万能型直交表作成ソフト Galois の活用
直交表について興味を持った。私も勉強しないとなあ。
あと既存発表の間違いを正すというアグレッシブな姿勢がよかった。
JaSST にはあんまり無いスタイルだと思う。
あと高専の先生でこうやって研究して発表するのはかっこいいなあ。
= 基本的な手法によるテスト工程の立て直し事例
たしかに基本的な手法だったけれど、しっかり実施することが大切なんだなあと思った。
「期限を設定すると、その直前まで着手しない。期限は設定せず、開発者を信じてできる限り早くタスクを消化してもらう」
という考えも面白いと思った。
= 問題のリアルタイム検出による品質改善
ベストスピーカー賞を取られた発表だった。たしかに面白く、役にたちそう。
やっぱり数字が載っている発表は説得力がある。
特に、結合試験と出荷判定試験のバグ密度に関する対比グラフの出されて
・結合試験でたくさんバグを見つけたとしても、出荷判定試験でバグが出ないわけではない
＝バグが出し切れていなかった
・結合試験よりも、出荷判定試験の方がバグが多い
＝バグの検出漏れが多かった
というような説明があり、結合試験バグ密度が目標値を下回っていたとしても、
それが意味のある品質判定にはならないとのこと。
そこでコードクローンや静的解析による評価に当てはめてみると、
出荷判定試験で目標品質に達している良いプロダクトは、
ソースコードの品質も良いという関係が示されていたことが非常に興味深かった。
静的解析をやってみよう、と心に誓ったが、１週間経った今でも未着手なので、
今のプロジェクトにてなんとか早めに試してみたい。
= ソフトウェア開発時のコミュニケーションにおけるコンテキストの可視化ワークショップの実施とその考察
タイトル長いな。
内容はソフトウェア開発者や品質担当者で、ソフトウェア開発についてどのような概念を持っているか、
そしてどれくらい差異があるのかを調べるというもの。
やり方は「RFP」という単語から連想する単語を書き、さらにそれから連想する単語を書いて…というのを
各人10分間でやってもらい、それらの単語が共通フレームなどでどの分野に該当するかをマッピングする。
そうすることでどの分野に興味を持っているかを計るというもの。
この調査方法が面白いと思った。
= 10年後のソフトウェアテスト技術
これこそベストスピーカーだ、と思ったけれど、招待公演だったのか被投票対象者ではなかったので投票できず。
面白かった点がたくさんあるので、箇条書きで。
・同値分割でも「本質的に等価なもの」と「主観的に等価に扱おうと思うもの」がある
たしかにこの区分を私は付けられていなかった。
私の研究でも同値分割はかなり重要な位置を占めるので、今この概念を授かったのはとてもありがたい。
・外部使用はフラットでも、内部は凸凹
たとえばmalloc(size_t size)は外部仕様から見ると、
入力の同値クラスとして size が負か0か正か、くらいしか見えてこない。
しかし実装によっては、ページメモリ境界(4k)をまたぐかとか、
要求サイズが実メモリ容量をまたぐかとか、
未使用の領域を返すのか、一度開放された領域の再割り当てなのかといった、
内部的な同値クラスがある。
似た話が西先生のとこでも出た記憶があるなあ。
・アプリケーションテストフレームワークとテスティングフレームワークを組み合わせる。
一致させてしまうのもよい気がする。
・テストケース数を爆発させるのは、条件式よりもループ。ループにもテストケースを爆発させるものとさせないものがある。
テスト容易性設計を考えると、プログラミングの視点から同じように見えるが、
概念としては違うものについて、分けて設計製作できるようにすべきではないか。
ちなみに例として挙げられたのは、前回のループ処理されたものをその次のループ処理で扱うようなものはテスト数を爆発させるが、
配列の初期化などはテスト数が爆発しないとのこと。
Iteratorや、集合演算などの概念を入れれば解決しそうか？
・ハードウェアは、自然界の法則をベースとしているため、凸凹が少ない
そうかも。まあハードウェア開発を知らない身としてはあまり偉そうなことは言えないのだけれども。
= アプリケーション開発の工業化への取り組み
資料が無いのが残念だったけど、基本的な手法によるテスト工程の立て直し事例に匹敵するほどの
現実感がある発表でよかった。
改善活動の実際というか。
あとメモですが「ソースコードレビューには1000ステップあたり2〜4時間をかける」とのことでした。
数字が出るのがいいね。
= パネルディスカッション テスト技法からテストメソドロジへの進化を目指して
各人好きなことを言っていて会話に入れないプレスマンって感じだった。
いやプレスマンも自分だけの世界で話してたけどね。
あとは頑張ってガンダムネタを入れようとする西先生が素敵だった。
内容としては、松尾谷さんの「有則・無則・禁則」という考え方が私が考えている内容にとっても近くて
私の研究生活は節穴だったのかと思った。なぜ2年前に気がつかなかったのか。
でもここ1,2年で出してきた概念なのかも?
まあよく見てみるとちょっと違いがあるし、そこからどうするのかという発展が大切なので、
まだまだ研究を続けられそうではある。
あとは誰の発言だったかは分からないけど、覚書を。
・要求の網羅性のための10の要素
富士通かどこかの方の話だったと思う。発表スライドに書いてあったことなので、
スライドがウェブに上げられることを期待して詳細メモせず。
・テスト探索空間の大きさはどのように実装されているかに依存する
mallocの話もそうだけど、内部にももっと目を向ける必要があるのかなあ。
まあ各フェーズで、どのような視点でテストを設計するかという話なのだろうけど、
具体的にどのような観点にするか、ということについて考える際に忘れないようにしないと。
全体を通して、今年の JaSST もとてもよかった。
8400円という参加費は今回は自費だったんだけど、十分に安い。
この内容だったら倍でも出すね。2万円を超えると厳しいけれども。
