月別アーカイブ: 2007年6月

テスト工程

…とは言っても、学校の「期末試験」でなく、システム開発での「テスト工程」のことです。

今のプロジェクトが、そろそろお客様先での結合テストに入る…と、スケジュール上なっています。
しかし現実は単体テストレベルのバグがわんさか…1日50個とか…出ています。
設計書やテストケース等、ドキュメントが古かったのが原因の内容もありますが(これはこれで構成管理の問題がありますが)。
このプロジェクト規模はトータルで50~70人月です。

テストフェーズでバグが出ること自体は良いのです。
#テストフェーズでは品質の向上が目的ではなく、あくまで品質レベルの確認をするだけです。品質を作り込むのは上流工程とよく言われています。

問題はその内容や傾向、テスト消化件数、バグ件数が「見える化」されておらず、管理されていないことです。
「どの機能にバグが集中しているのか?」や「内容には傾向があるのか?」等が分かれば、手の打ちようがあるのですが、それが分からない状態です。

もう1つの大きな問題は、不具合修正とテスト実施を同時に行い、パスしていたテストケースがパスしなくなる…デグレード(orレグレッション)が発生していることです。

さらに怖いのは回帰(退行)テストをしてデグレードが見つかったわけで無く「偶然」見つかっていることなんです。
回帰テストができない理由は、テストの自動化を行えておらず、手作業で回帰テストが出来る程リソースがないからだと思います(私自身、途中からの参加&そういう立場でも無かったので「なぜか?」は分かりませんが)。

で、上記2つの根本的なところとして、テストマネージャー的位置付けなロールがいないのです。
その結果、見える化が出来ず、テスト計画も行き当たりばったりな感じなのです。
実際はテスト消化件数等数字は出るようになっていたのですが、それはQMS等への報告用でしかなく、それを使って何か対策を打つまでは出来ていなかったのです。

テストをしながら、私が数年前に参加したプロジェクトは全く違っていたなぁと思い出しました。

そのプロジェクトでは単体テストフェーズに入ると、それこそコメントであれ、一切プログラムを修正しないをルールとしていました。修正すれば影響範囲を見極めた上で再テスト(これが回帰テストです)を行うという運用でした。
#この影響範囲の見極めも、早めにテストケースを上げて、それにそって実装していたのでやりやすかったというのがあります。

当たり前ですが、バグ管理、グラフによる見える化を行っていて、先手先手で再テスト、ソースコード見直し等を行っていました。結果、デグレードは発生せず、リリース後の不具合もほぼ0件の稀にみるプロジェクトでした。

数年前から「システム開発のキモは上流工程」と言われ続けていますが、このプロジェクトも結局は上流工程の要件定義や基本設計が遅れていきました。
その結果、本来テスト計画をしないといけない時期にも出来ず、それが今の状況になっています。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: rgieseking via Visualhunt.com / CC BY

Javaの格言―より良いオブジェクト設計のためのパターンと定石[読書感想]

仕事でJavaを使ってのシステム構築をしています。

勉強したり、資格を取るためJavaをさわることはあっても仕事は初めてです。
で、思い立って以前に買って積読していた↓をちゃんと読んでみました。

■(Javaの格言―より良いオブジェクト設計のためのパターンと定石)
著者:ナイジェル ウォーレン (著), フィリップ ビショップ (著), Nigel Warren (原著), Philip Bishop (原著), 安藤 慶一 (翻訳)

【目次】
第1章 カプセル化
第2章 継承
第3章 ポリモルフィズム
第4章 型の安全性と定数
第5章 例外
第6章 コールバック
第7章 クラスのロードとオブジェクト生成
第8章 生成に関するイディオム
第9章 パフォーマンスとリソースとのバランス
第10章 コレクション
第11章 イテレータ
付録A 図ならびにコーディング規約について
付録B 規則・設計原則・ヒント一覧
付録C 重要用語集
付録D 参考文献

Javaの文法、カプセル化やポリモルフィズム等オブジェクト指向の基礎知識が前提で、UMLダイアグラムやデザインパターンも知っていればより面白いです。

各章のサンプルプログラムに対し、オブジェクト指向の深い考察が記述されています。
また保守、機能追加が加える際にどのように(オブジェクト指向的に)考えていくと良いかということも色々と考察されています。

特に第1章~第5章は上級プログラマーレベルであれば知っておいて損はないと思いますが、1回読むだけでなく…実際に仕事で使い…そして再び読むと「あぁ、なるほどねぇ」と思うこともあるような本です。

「10日で覚える~」「初めての~」シリーズとは趣が全く違います。また「Tips集500」は「こんなことしたいんだけどなぁ」の時に役立ちますし、実際の現場ではこっちが必要ですが、本質的な点や設計レベルで考えるのであれば、こんな感じの本に書いている内容を知っているとかなり良いと思います。

ちなみにピアソン・エデュケーションの本は良くも悪くもガッツリ深く書いている本が多いので、理解するのにパワーがいります。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo via Visual Hunt