『第2回 ソフトウェアテストセミナー』に行ってきた

SATOOアジャイル, コスト, セミナー, テスト, テスト駆動開発, メトリクス, リバースエンジニアリング, レポート, 分散開発, 見積もり

こんにちは、SATOOです。
今日は、つい先日(3月11日)に催された『第2回 ソフトウェアテストセミナー』に行ってきた感想を書こうと思います。

『ソフトウェアテストセミナー』は、技術評論社が主催して行うテスト・エンジニアのためのイベントです。
昨年から品質管理チームを立ち上げ、テストや品質管理・品質改善といった分野に足を踏み入れた身としては、ここら辺で一度しっかり勉強しようと思い、参加してみました。

カメラマンが入っていたので、いずれ技術評論社のサイトで公開されると思いますが、現段階ではまだレポートは上がってません。まぁ、昨日の今日なので当たり前ですか。

会場は予想より広く、しかもほぼ満席。
普段ほかのテスト・エンジニアと交流する機会がないので、こういうセミナーに参加する人がこんなにもいるのだと知りました。しかも意外と女性もいたりして、少し感動。

ちなみに、セミナーの目録はこんな感じでした。


ソフトウェアテスト・ヒストリー
~テストの歴史を学び、歴史に学び、そして歴史を作ろう~

講演者:辰巳 敬三 氏(富士通株式会社)

最初はハードウェアの一部(1950年代)
テスト技法はほとんどなく、必要な機能が十分に動くかどうかのチェック(デバッグ)だけ
工芸品としてのソフトウェア(1960年代)
ソフトウェアプログラミング技術としてCOBOL、LISPが登場
テスト技法としては、デシジョンテーブルテスト、同値分割/境界値分析の考え方が発表された
形式化・ウォーターフォールプロセス(1970年代)
信頼性を重視する指向が高まる
テスト技法も、非常に多くの手法が考案された(原因結果グラフ、状態遷移テスト、カバレッジ、複雑度、品質特性/品質モデル、変異テスト、ドメインテスト・・・)
生産性と拡張性(1980年代)
ソフトの大量生産とコスト低減のため、リスクマネジメント、再利用性が重視されるようになった
「バグを見つけることがテストの成功だ」と捉えられるようになる(破壊指向)
並行プロセスと順次プロセス(1990年代)
ソフト自体の品質が重視されるようになる
リスクを早期に発見し、『予防』することが重要
迅速な開発と価値(2000年~)
リスクベース・アジャイルと計画駆動のハイブリッドで開発するためのモデル、テスト駆動開発が登場した

他には現在のテスト研究の最前線の紹介など。
ソフトウェアについての考え方が、ソフトウェアテストのあり方に直結しているなぁ、というふうに思いました。


ソースコード静的解析ツールの有効利用
~ソフトウェア・メトリックスを利用した品質の可視化~

講演者:玉木 淳治 氏(株式会社 エクスモーション)

静的解析ツール利用の現状
バグの可能性の高いコードの検出に利用されている
しかしソフトウェア・メトリクス測定やリバースエンジニアリングはほとんど利用されていない
ソフトウェアメトリクスによる品質の定量化
メトリクスを使うと、理解しづらく利用されにくいソースコードを得点化でき、基準化と比較をしやすくする
リバースエンジニアリングによる構造解析
構造の複雑さを定量化でき、不適切な依存関係を自動で検出できる

ソースコード解析はわかりやすいのですが、メトリクス測定やリバースエンジニアリングは使いにくいという印象をもっていたので、興味深く聴きました。
メトリクス測定もリバースエンジニアリングも、品質を定量化するという意味においては有用だと感じました。
そのうち試してみようと思います。


プロジェクトを成功に導くソフトウェア品質管理の実現
講演者:越水 喜之 氏(日本アイ・ビー・エム株式会社)

ソフトウェア開発の変化
分散開発が主流になってきた昨今において、コミュニケーション不足、品質のばらつき、開発方針の不一致が問題になりやすい

内容的には「IBM Rational」の紹介がほとんどという感じでした。
要件定義段階から統合テストまで一元管理できる、というのは確かに便利そうでした。


国産ソフトの海外テストを成功に導く5つの秘訣
講演者:栗俣 一郎 氏(株式会社 日本オープンシステムズ)

海外でテストを実施するうえで重要なポイント
行うべき内容の明確化、安全に業務が遂行できること
会議体運用
5分でいいから、チームミーティングを持つこと
自律的に成果を出すには、コミュニケーションが不可欠

講演者ご自身の体験談をもとにお話しいただきました。
「ツールや技法ではなく、人こそが品質を作る」のだ、というメッセージが印象的でした。


こんなときだから「テストチームをつくろう!」テストチームを“おいしく”つくるオススメのレシピ
講演者:入江 直樹 氏(株式会社パソナテック)

テスト業務を好む開発者が少ない理由
つまらない
若手の仕事
何をするかよくわからない
将来性がわからない
専門職としての経験者は希少
エンジニアの価値観
正当な評価と待遇
専門性を磨きたい
一緒に働く人
まっとうな経営
オススメのテストチーム
ポイントはパワーバランスの対称化
開発vsテスターの構図にしない
インセンティブ性のある評価
外部研修は開発者にも受けさせる
定期的な勉強会・意見交換会、飲み会も有効活用
会社TOPの後方支援を明確化

他にも、マズいテストチームの形とか、うまくテストチームを作る細かいやり方などを紹介していました。
開発者にもテストセミナーなどの外部研修を受けさせましょう、というのは納得。
後半はテストエンジニアを派遣しますよ、というお話(パソナテックさんは人材派遣会社なので)でしたが、面白かったです。


プロジェクト見積もり技術の理論・歴史・実践
– 現実的で実践的な見積もりを実現するために、今、若手エンジニアが知っておくべきこと –

講演者:細川 宣啓 氏(日本アイ・ビー・エム株式会社)

見積もりの歴史と「矛盾」
トラブルの原因は、見積もりが間違っているか、要求仕様が固まっていないかのどちらか。ただし実際はその両方であることがほとんど
見積もりの説明には、合理的な理由と感情論の2つが必要
見積もりの落とし穴
見積もりは通常、規模・コスト・納期で決定する
ここで「品質」が抜け落ちている場合が多い
1:5:10:50:200の法則
例えば、要件定義時の欠陥除去コストを1とすると、システムテスト時の欠陥除去コストは50となる
→要件レベルでの品質追求は、システムテスト時の品質追及より、50倍の手戻り削減
要件定義時の欠陥除去コストを1とすると、サービスイン後の欠陥除去コストは200
→リコールに相当

とても面白かったです。
見積もり技術に関しては無知に近かったので、興味深く聴きました。
ソフトウェアテストというより、見積もりにおける品質保障の重要性について、といった感じでした。


参加してみて思ったのは、もう少し技術サイドの話が出てくるのかと思いきや、そんなことはなかったなということ。
個人的には、株式会社パソナテック/入江氏の「テストチームをつくろう」と日本アイ・ビー・エム会社/細川氏の「プロジェクト見積もり技術」の講演が興味深く聴けて勉強になりました。
アンケートに答えて粗品(電動歯ブラシ)と新書(組込みソフトの開発現場につける薬)も貰えたので、至れり尽くせりでした。

次回もあるようでしたら、ぜひまた参加したいと思います。