« 2009年5月 | トップページ | 2009年7月 »

2009年6月

2009/06/30

紙やExcelによる管理が残っている工程

2007年頃のバグ管理の資料があったのでメモ。

【元ネタ】
[Think IT] 第3回:取材お断り!の裏事情 (2/3)

・現状は、半分以上が紙もしくはExcel
・今後は、Bugzilla、Visual Studio 2005 Team Foundation ServerなどのBTSを使いたい人が多い


以前、バグをExcelで管理していた時、バグ管理IDは特別なExcelシートで採番するやり方で運用されていた。
そこでユニークなバグ管理IDを採番した後、その障害管理票を紙に印刷して運用していた。
その紙には、判子の欄があった。
判子の欄には、開発者、テスト担当者、プロジェクトリーダーの3つの欄があった。
それは、他の人の作業した結果を認めたら、各人が判子を押していく運用フローになっていた。

つまり、ワークフローと言う概念が当時の開発者だった僕の頭にはなかったけれど、たとえアナログであろうともワークフローは厳然として存在していた。

そして今は、RedmineやTracのチケットでプロジェクト内部の作業を全て管理する運用を始めて、リーダーだけでなく開発者もテスト担当者もワークフローと言う概念を、少しずつ認識し始めている。

この仕様変更は、どのチケットと関連しているのか?
このマージ作業は、どの障害修正から発生したのか?
自分が作ったプログラムは誰がテストするのか?
プロジェクトの中で自分のプログラムはどんな重要性を持っているのか?

いずれもチケット一覧、ロードマップから判別できる。

しかし、殆どの作業がBTS上でIT化された中で、未だに紙ベースの作業が唯一残っている。
それは、変更管理・進捗会議や設計レビューなど、4~10人による複数人での作業。

それらは大量の紙を印刷して配布され、その紙を見ながら、議論してメモしていく。
その会議中は全員分かり合った気分になっているが、後でメモを読み返して議事録にすると、微妙にニュアンスがずれていたりする。

議事録ドリブンできちんとやれば、そんなことは解決できるが、ExcelやWordの議事録はすぐに散らかってしまう。
せっかくレビューで仕様漏れをチェックし、ソースインスペクションもするのに、紙ベースで残すので、Excelの議事録にまとめるために二重の手間がかかる。

本来ならば、その場ですぐにExcelにレビュー指摘事項を一つずつ記録して、それをきちんと反映したか、というチェックを行いたい。

あるいは、突然の仕様変更に対し、方針を立てて、メンバーごとに調査を依頼する場合、それらをWikiなどに反映して、メンバーが作って持ち寄った成果物をチェックしたい。

そのワークフローをもっとスムーズに行いたいのだ。
今はメールや紙ベースで散在してしまっている。
後の運用保守で、それらの経緯がいつも分からなくなる。

どうやら3人以上による作業の場合、ペアプロも行えないので、紙やホワイトボードでコミュニケーションを取り合うしかない。
そして、それらはExcelの議事録を残すしかない。

チケット駆動開発は、個人のタスク管理には威力を発揮するが、複数人の作業によるワークフローを乗せるのはまだ分からない。

BTSチケットへどのようにレビュー結果や議事録をのせるか?
チケット駆動開発には、まだ課題は残る。

| | コメント (0) | トラックバック (0)

TestLinkから外部サーバーのBTSに接続する方法

TestLinkのあるサーバーから外部サーバーのRedmine/Mantisへ接続する方法でメモ書き。

【元ネタ】
FreeBSD/Mysql/外部接続 - PukiWiki Plus!

TestLinkにあるmantis.cfg.php、redmine.cfg.phpの設定は正しいのに、何度やっても、TestLinkからBTSチケットへリンクできない。

原因は、外部サーバーのBTSにあるMySQLが、localhost以外はデフォルトで接続不可になっている。

--確認
select User,HOST,Password from mysql.user;

--ユーザを追加
GRANT ALL ON [BTSのDB名].* TO '[DB-user]'@'[TestLinkのサーバー名]' IDENTIFIED BY '[DB-password]';
FLUSH PRIVILEGES;

MySQLを知っている人なら当たり前だろうけど、ちょっとはまった。

但し、TestLinkからTracへの設定は下記を参照すれば簡単。
Trac0.11からXML-RPC Pluginがデフォルトで付随しているため、trac.cfg.phpにURLを設定するだけでいい。

Trac と TestLink の連携 - かおるんダイアリー

| | コメント (0) | トラックバック (0)

2009/06/29

アジャイル開発は受託開発の方が向いている

ある人と話して気付いたこと。

アジャイル開発は受託開発の方が向いている。

組込系の製品開発やパッケージ製品開発では、マーケティングやビジネス上の要請から、既に要件が殆ど決められていることが多い。
だから、ウォーターフォール型開発で進めやすい。

受託開発では、おおまかな要件は決まっているが、あくまでも方針だけ。
顧客のためにカスタマイズしていく間に要件が絞られて、具現化していく。
ガチガチのウォーターフォール型開発で進めると、度重なる仕様変更を制御できずに、コストや納期がオーバーしやすい。

だから、小刻みにリリースしながら、顧客のフィードバックをイテレーション単位で取り込んで、システムをブラッシュアップしていく。
コストと納期は厳守しながらも、スコープ(要件)を変化させることで、顧客満足を稼ぐ。

でも、アジャイル開発だからといって、設計書は不要、とか、計画は不要、というわけではない。
要件の変化を確実に追跡できる変更管理の仕組みは必須。
どのイテレーション(バージョン)に、どんな改善要望や障害修正を反映していくか、というリリース計画を作るのが重要。

チケット駆動開発がアジャイル開発のインフラを提供していく。

| | コメント (3) | トラックバック (0)

2009/06/27

チケット駆動開発はソフトウェア開発のERPを目指す

家計簿ソフトをいじりながら思ったこと。

家計簿ソフトは最終的には、財務システムにつながる。
本質は複式簿記。

日々の収入、支払いというトランザクションは、勘定科目に分類される。
勘定科目は、BSという観点で、資産・負債のメトリクスを出力する。
企業の家計簿は、四半期ごとのPL・BSを出すためにある。

TiDD(チケット駆動開発)のチケットは、基本はタスクカード。
チケットは開発チーム内部の日々の作業記録。

ストーリーカードは、チケットの発生源。
ストーリーカードを勘定科目に喩えたら、顧客価値がより一層理解しやすくなるのでは?

顧客向けの進捗報告がストーリーカードの観点ならば、それはBSそのもの。
開発したシステムの資産と負債を現すのではないか?

TiDDでは、チケットの属性に担当者、予定・実績工数を入力できる。
これによって、担当者の単価を元に工数と人月を集計すれば、プロジェクトの原価・コスト・利益を自動集計することができる。

TiDDによって、SWプロジェクトの作業を開発者の観点で管理できるだけでなく、SWプロジェクトに関するお金の流れ、システムの価値も追跡できるようになるはずだ。

TiDDを突き詰めれば、最終的には、ソフトウェア開発のERPになりうるはずだ。

| | コメント (0) | トラックバック (0)

TestLinkの弱点~マイルストーン管理

TestLinkの利点は、実行するテストケースを貯蔵して再利用できること、テスト実行と集計の管理機能があること。
TestLinkはテスト管理ツールとして強力だと思う。
でも、TestLinkの機能で唯一使いづらい機能がある。
それはマイルストーン管理。

【1】TestLinkのマイルストーンは、ビルドに対する日付ラベルのような存在で、進捗を測定する機能がある。
しかし、有り難味がない。

テスト工程でマイルストーン機能を使いたい場面は、テスト進捗の予定と実績の比較だ。
テスト仕様書にあるテストケースには必ず、テスト実行者がアサインされ、テスト予定日が書かれている。
テスト予定日に従って、テスト実行者はテストし、テスト実施日とテスト結果を記載していく。

テストに失敗した場合、2回目のテストをする必要があるが、Excelではテストケース1行の横にどんどん展開されていくので管理しづらかった。
TestLinkでは、ビルド単位でテスト実施結果の履歴を残せるため、後で管理しやすい利点はある。

しかし、TestLinkには、テスト予定日の欄がなく、テスト予定日でテストケースをフィルタリングする機能がないため、使いづらい弱点がある。

TestLinkのマイルストーンの本来の機能は、テスト予定・実施の累積グラフにおけるスナップショットであるべきだと思う。
つまり、テスト開始日からテスト終了日までの期間に数回のマイルストーンを置き、そのマイルストーンで予定から進捗がどれだけ遅れているかを表示する機能であるべきだと思う。


【2】但し、TestLinkCnvMacroでTestLinkのテスト実績を出力できるので、Excelに取り込んで、テスト予定日とテスト実施日を比較することは可能だ。

TestLinkCnvMacro- TestLinkTools - SourceForge.JP

テスト計画では普通、テスト予定日から推測したテスト実施予定の累積グラフ、テスト計画から類推したバグの累積グラフをあらかじめ作成できる。
これらのグラフに、テスト実績の累積グラフ、実施後のバグの累積グラフを重ね合わせれば、予定と実績の比較ができる。

その比較の差異から、進捗の遅延の原因や、バグが多発する機能を探ることができる。

TestLinkCnvMacroには、下記の観点でテスト結果を出力してくれるので、テスト工程の進捗や生産性を考える上で、非常に役立つ。

・テスト結果の推移データ(テスト実施結果の累積グラフ)
・要件カバレッジの推移データ
・時間帯別の試験結果データ
・試験結果のピーク時間帯推移データ
・曜日別の試験結果データ
・時間当り実施数推移データ
・試験者別時間当り実施数データ


【3】TestLinkはテスト管理に特化していて、スケジュール管理などのプロジェクト管理機能が弱いと従来から指摘されていた。

ガントチャートなどを生成したり、テスト工数を残す機能などはRedmine等で行えばよいと思うが、せめてテスト予定日の機能は入れて欲しいと思う。

既に、TestLinkにはテスト実施日とテスト実施結果はDBにあるため、予定と比較の機能から、テスト工程における意思決定の情報を作成できるはずだ。

TestLinkは発展途上のオープンソースのツールのため、不足している機能は多いが、世界中のテスターの要望を受け入れて改善されていけばいいなと思う。

| | コメント (0) | トラックバック (0)

Redmineの唯一の弱点~工数管理

僕は、Redmineは現在、世界中で一番優れたBTSだと思っている。
何と言ってもプロジェクト管理機能が強力で、このおかげでチケット管理を更に活用できる。
しかし、唯一の弱点があると思う。
それは、工数管理。

Redmineチケットには、予定工数と実績工数を入力できる。
その実績工数は、レポート欄でログ検索のように検索できる。
しかし、使い勝手は正直悪い。
実績工数を単に表示するだけでは面白くないからだ。

また、Redmineの実績工数には作業分類という属性があり、デフォルトでは「デザイン作業」「開発作業」がある。
これは、Redmineでは作業トラッキング(タイムトラッキング)と呼ばれている。

つまり、実績工数を更新するたびに、実績工数を色づけできるから、後で、作業分類ごとに工数集計できる。
しかし、この作業分類を上手に使って集計する機能がない。

結局、MySQLへ直接SQLを発行して、自分が欲しい工数集計をするしかない。

予定工数と実績工数をRedmineのDBにためて、後でどのように使う場面があるか?
よくある状況は、週次報告や月次報告で、チケット単位で工数を集計して上司や顧客に報告することだ。

例えば、下記のようなレポートを顧客へ月次報告していないだろうか?

2009/6の月次報告
-----------------------------
作業内容 工数 作業終了日
-------------------------------------
バグAの修正 xx人日 2009/6/15
仕様Bの追加対応 yy人日 2009/6/30
--------------------------------------
合計 zz人日

更に、詳細欄では、メンバー単位、作業分類単位(設計・開発・テストなど)で工数集計しているだろう。

メンバーAの作業報告
----------------------
作業日 作業内容 工数
-------------------------------
2009/6/1 バグAの修正 cc時間

2009/6/30 仕様Bの追加対応 dd時間
-------------------------------
合計 ee時間 (ff 人日)

このような作業報告が必要である理由は、殆どの受託開発や運用保守では顧客へ人月単位で請求しているからだ。
普通のマネージャや現場リーダーは、Excel上で上記の工数を手計算で集計しているだろう。

でも、Redmine上でチケット駆動開発しているならば、工数はRedmineのDBにあるから、集計プログラムさえあれば、自動出力できる。
しかも、Cronを設定しておけば、毎月の工数報告も出力できる。

でも、Redmineには上記の機能がWebUIとして揃ってないため、直接SQLでCSVを落とすしかない。

とはいえ、Redmineには更なる可能性もある。

一つは、予定・実績の工数比較ができること。
チケット単位、メンバー単位で予定と実績の工数比較ができれば、その差異から、プロジェクトのリスクを感じ取ることができる。

もう一つは、作業分類によって、工数をタイムトラッキングの単位で出力できること。
作業分類を工程ごとに登録しておけば、工程単位で工数を集計できる。
例えば、要件定義、設計、開発、テストのように作業分類を登録すればいい。

このデータを活用すれば、2次開発や運用保守で工数見積する時の参考資料になりうる。

僕がRedmineのレポート機能でよく見るのは、イテレーション(バージョン)と月別の実績工数のクロス集計だ。
2~4週間のサイクルでイテレーションをリリースしたとしても、イテレーション毎に実績工数は実は予定工数と結構異なっている。
その差分が発生した理由を類推して把握しておくのは、次のイテレーションの開発で非常に役立つ。


Redmineはまだ開発途中の機能が多いけれど、工数集計のような機能はプラグインで対応すればいいだろうと思う。
しかし、工数集計のプラグインは色々探したが、現在はどれもいまいちだった。
でも、Railsなので、プラグインも今後増えると思われる。
今後のRedmineの機能拡張で、工数管理の機能は要注目だと思う。

| | コメント (0) | トラックバック (0)

2009/06/22

事象にユニークなIDを採番する利点

RedmineやTestLinkなどのツールを駆使してプロジェクト運営すると、チケット、バグ、テストケース、要件などSW開発に関する事象にユニークなIDが振られるのに気付く。
すると、チーム内でこんな会話があって、お互いに事象を認識して共有しやすくなっているだろう。


今日は、チケットxxとyyのいずれを最優先で行うか?
今、チケットzzの作業状態はどうなっている?
このSVNリビジョンrrの修正理由は、チケットIDがxxにある仕様から来たんだね。

今、あのバグxxのステータスはどうなっている?
テストケースは何番まで実施した?

そのテストケースyyは、要件IDがxxから作りました。
要件IDがxxをテストするテストケースが漏れていますね。

その仕様は、要件ID xxから来ているから、勝手に修正してはいけないね。


過去を思い出そう。
Excelでバグ管理していた時、きちんとしたワークフローを踏んだ開発チームでは、バグ管理IDを振るための特別なExcelシートがあった。
そのExcelシートで、バグ管理IDをユニークに作り、それから障害報告票を作成し始める。

そんなワークフローにした理由は、IDを振ることで、バグの症状や原因、状況を最初から説明する必要がなくなるからだ。
IDが振られていなければ、MM月dd日に見つけたバグですが、とか、機能AのボタンBのバグでYYYとか、などのように、事象を逐一説明しなければならない。

1日でバグが10件以上も多発した場合、チーム内で上記のコミュニケーションを取るのは至難の業だ。

同様の事は、チケット駆動開発におけるチケットIDでも同様。
君が担当している機能Aの仕様変更はどうなった?という質問をしたい時、仕様変更の中身を説明しないといけない。
納期が迫ってタスクがどんどん溜まっていく時、タスクを説明するだけでかなりの労力をすり減らすだろう。

事象にユニークなIDを振ることで、互いのコミュニケーションのロスが減る。
だが、更なる利点は、変更管理がやりやすくなることだ。

チケット駆動開発では、チケット無しのソース変更を認めないルール(チケット・ファースト)があるので、ソースのリビジョンには必ずチケットIDが振られている。
つまり、ソースの修正理由をチケットに追記することができる。
だから、過去のバグ修正やパッチを追跡できるインフラが自然に整う。

更に、バグ管理IDと失敗したテストケースID、更には要件IDが紐づいていれば、最終的に、ソースの修正理由を要件IDまで辿ることができる。


最近気付いたことは、要件IDを振られた要件定義書を作らずにSW開発を始めているプロジェクトが殆どであることだ。
すると、受入テストで使うテストケースを作る時に、そのテストケースは要件に基づいた業務フローで作られているのか?という保証をするのが非常に難しくなる。

受入テストは要件定義のテスト工程であるから、テストの元ネタとなる要件として揃っていなければ、テストケースのレビューもできない。

IDを振るという行為には、事象をユニークに定めるという基本動作が含まれている。
そこから、IDに重複がなく漏れもないということを自然に考えるようになる。
つまり、要件や仕様がダブりなく漏れもないようにMECEで考えることを自然に行っているはず。

IDを振る行為には、コミュニケーションロスをなくすだけでなく、変更管理を容易にするだけでなく、IT技術者としての基本動作も含まれているような気がするのだ。

| | コメント (0) | トラックバック (0)

2009/06/21

クラウドコンピューティングとKey-Valueストア

クラウドコンピューティングとKey-Valueストアは密接に関係している。
参考リンクをメモ。

【元ネタ】
Key Valueストアがリレーショナルデータベースを駆逐するシナリオの妥当性:Azureの鼓動:ITmedia オルタナティブ・ブログ

Bigtableの使い方教えます - ひがやすを blog

株式会社スターロジックの羽生章洋が書いてるブログ:端境期を感じるシステム開発 - livedoor Blog(ブログ)

株式会社スターロジックの羽生章洋が書いてるブログ:key-valueはデータディクショナリの夢を見るか - livedoor Blog(ブログ)

何故、Webシステム開発では、RDBだけでは物足りないのか?
Key-Valueストアは、どこに使われて威力を発揮するのか?
Key-Valueストアのアーキテクチャはどんなもので、どんな技術で実装されるべきなのか?
Key-Valueストアは、メインフレーム時代の技術の再来なのか?
Key-ValueストアはRDBを駆逐するのか?

| | コメント (0) | トラックバック (0)

RedmineとTracの機能比較part2~ポータビリティ、プラグインなど

あるTracユーザの話を聞いて、RedmineとTracの機能の違いを感じたので、考えたことをメモ。

【1】ポータビリティ(環境の持ち運び)はTracが勝る

TracLightningでは、SQLLite+SVNが一つのフォルダに存在するから、バックアップが簡単。
Tracはそもそも1プロジェクトしか扱えないので、1プロジェクトのTracDB(SQLLite)を持ち運んで同期を取ればいい。

しかし、Redmineでは、DBはMySQLが普通だから、バックアップや持ち運びはOracleのような操作が必要になる。
また、複数プロジェクトを扱っているから、1個のプロジェクトだけ持ち運んでも同期がとりにくい。

特に、客先と自社で受託開発のタスク管理をする場合、USBメモリでSQLLiteのDBを持ち運びできればすごく簡単だなと思った。

RedmineでもSQLLiteを扱うことはできるが、チケット数が増えてDBのサイズが増えるとあまりよろしくないような気がする。

【2】チケット更新の一括処理

スケジュールを最初に作った時、WBSからタスクをチケットにして一括登録したい。

Tracユーザの使い方を聞くと、Tracへチケットを新規登録する時は、Excelで一括登録する。
Web上で1個ずつ登録することはしないらしい。

ExcelTracAddIn 1.1.0 リリース - かおるんダイアリー

Redmineでも最近はチケット一括登録のプラグインなどが増えてきたけれど、最初はなかったので、手作業で入力するしかなかった。
でも、最近は、よいプラグインも出ている。

RedmineでチケットをCSVから一括登録/更新するプラグイン | RedMine | MTエンジニアブログ | スカイアークシステム

ExcelRedmineAddIn 1.0.0 リリース - かおるんダイアリー

post_issue_vbs - farend-redmine-tools - Google Code

【3】Hudsonとの連携

TracLightningなら、デフォルトでHudsonが使える。
Hudsonをビルド処理だけでなく、定時のバッチ処理で使えれば、なお強力だろう。

Redmineでは、以前は、SimpleCIプラグインを使っていた。
しかし、ビルド結果へのリンクがあるだけで、使い勝手はあまりよくない。

Plugin SimpleCI - Redmine

しかし、有志がHudsonのプラグインを最近提供してくれている。
ジョブの名前、ビルドの説明、ヘルスレポート、最新のビルド状況などを表示してくれるのですごく使いやすくなった。

Hudson Plugin 0.1.0 - Redmine

r-labs - Hudsonプラグイン - Redmine


【4】コードレビュー

Redmineではリポジトリ一覧画面から、ソースのDiffを表示する機能が以前からあった。
Diffを見て、何かおかしいと感じたら、「このようにリファクタリングしたらいいんじゃないの?」みたいなチケットに登録しておけばいい。
だから、コードレビューしやすい状況があった。

しかし、できれば、Diffの画面でコメントを付けられるとなお嬉しい。

Tracにはコードレビュープラグインが以前から存在していた。

PeerReviewPlugin - Trac Hacks - Plugins Macros etc. - Trac

あーありがち - Trac に PeerReviewPlugin を入れてみた

Redmineには最近になって、有志がプラグインを提供してくれている。

r-labs - Code Reviewプラグイン - Redmine


【5】Blogプラグイン

Redmineにはニュース機能があるが、プライベート日記のような機能があると嬉しい。
つまり、ニュースはメンバー全員に告知するためであり、Blogのように日々の思いを綴るのはやや違う。

TracクローンであるRetrospectivaには元々Blog機能があり、Redmineよりも唯一優れた機能だと思っていた。
そこで実際に使ってみようと思ったが、Redmineほどプロジェクト管理機能は使えなかった記憶がある。
#但し、最新バージョンではかなり機能拡張されているようなので注意。

プログラマの思索: Retrospectivaをインストールしてみる

最近になって、RedmineにもBlogプラグインが提供されている。

Redmine Blog Plugin - Redmine

なお、Tracでは以前からプラグインが提供されている。

TracBlogPlugin - Trac Hacks - Plugins Macros etc. - Trac

TracDoc/TickTackBlogPlugin -- HirobeのHack倉庫 -- Trac

| | コメント (0) | トラックバック (0)

2009/06/20

TestLinkをユーザ企業が使う時の注意点

下記の記事を読んで、TestLinkは本来、ユーザ企業が発注した業務システムを、ユーザ企業自身が受入テストで使うべきだと思った。
以下メモ書き。

【元ネタ】
TestLink を使ってみた - hokorobiの日記

TestLinkJP - TEF有志によるテスト管理システムTestLink日本語化プロジェクト

僕は、TestLinkをテスト工程のうち、結合~システムテストで運用している。
実際は、単体テスト完了したモジュールをリリースする前に、開発部隊が自分たちで業務シナリオベースのテストケースを作り、それでもってテストしている。
つまり、リリース前の品質保持のためにTestLinkを使っている。

でも本来は、ユーザ企業自身がTestLinkを使って、発注した業務システムを受入テストで使うべきなのだ。
理由は、ユーザ企業も受入テストというテスト工程を自身が関与しなければ、システム開発は終了しないこと。
更に、TestLinkは単体テストよりも受入テストの方が威力を発揮するから。

上記の記事で面白いと思ったのは、ユーザ企業自身が受入テストでTestLinkを使った運用例が紹介されていること。
類推すると、下記の運用と思われる。

1.テストケースは、結合テストの観点も入れた業務シナリオベースで作る。
2.テストケース数は 500 強。
3.テスト計画は1個だけ。つまり、全テストケース500個余りがアサインされている。
4.リリースモジュールがβ1、β2、β3、最終Verと渡されるたびに、ビルドを作る。
5.1回通すのが精一杯で回帰テストまでできていない。
6.どのリリースモジュール(つまりビルドに付与されたビルド番号)で、どのテスト(つまりテスト計画)を実行して、どのリリースで修正を確認した(つまりビルド)かが分かりやすかった。

使い方はすごく上手だと思う。
特に、受入テストのテスト計画1個に対し、リリースされるモジュールのバージョンごとにテスト結果(つまりビルド)を残しているので、ビルドが増えるたびに普通はバグの数も減っていくはず。

TestLinkでは、ビルド単位のテスト結果も集計してくれるので、リアルタイムにテスト進捗を把握できる。

僕としては、他の人がTestLinkを運用して、全テストケースに対するテストケースの失敗率を知りたいと思っている。

僕のわずかな経験では、失敗率が5%以上ならば、品質が悪く、リリース後にたくさんの障害修正が寄せられてくる。

例えば、テスト計画のテストケース数が500個と仮定しても、失敗率が5%ならば25件も失敗してバグも25件出たことになる。
受入テストで判明したバグは、単体テストのバグとはレベルが異なり、仕様漏れや要件漏れの原因が多いから、修正工数と再テスト工数が非常にかかる。

又、テストケースには依存関係があるため、1個のテストに失敗すると、10個ぐらいのテストケースも「ブロック」になってしまう。

例えば、Amazonのような小売系Webシステムで、クレジットカード決済の確認画面でテストに失敗したら、クレジットカード決済の受注や受注保守画面で受注データ修正、会計システムへ受注データをバッチ処理、などのテストケースは全て「ブロック」になってしまう。

すると、25ケースも失敗すると、単純に数えると250ケースは「ブロック」になってしまい、全テストケースの半分近くはテスト保留になってしまう。

だから、バグ管理やテスト管理をうまく制御しないと、テストそのものが終わらなくなる。
実際のテスト管理では、ブロックした「みなしバグ」のテストケースは無視して、バグと関係しないテストを先にやったり、本来のバグが修正されたらすぐに再テストを開始するなどの運用が重要になってくる。

TestLinkでは、テスト結果だけでなく、失敗したテストケース一覧やバグ一覧の画面もあるので、テストケースやバグのステータスをリアルタイムに確認できる。

そして、そのテスト結果をTestLinkCnvMacroで分析すれば、各種のメトリクスから色んな気付きが得られるだろう。
テスト実績の累積数のグラフは、信頼度成長曲線とある程度似通ってくるはずなので、品質の判定にも使えるはず。

TestLinkCnvMacroダウンロード - TestLinkTools - SourceForge.JP


僕としては、SRATSを使って最終的には、ソフトウェアシステムのMTBR、MTBFまで自動計算させたい。
そうすれば、リリース判定、出荷判定にも使えるはずだ。

SRATS:Software Reliability Assessment Tool on Spreadsheet Software

その意味では、TestLinkに溜まったテスト実績は、プロセス改善の宝庫とも言える。

TestLinkによるテスト管理には、まだまだ色んな可能性があると思う。


|

2009/06/14

ソフトウェアタグ

6/12のSEA関西プロセス分科会で聞いたソフトウェアタグに関するメモ書き。

【元ネタ】
第38回 SEA関西プロセス分科会のご案内

StagEプロジェクト


ソフトウェアタグとは、受託システムへ開発時のプロジェクト情報を付けて、トレーサビリティ(追跡性)とアカウンタビリティ(説明責任)を持てるようにすること。
イメージは、工業製品や食品のタグのように、原産地はどこで、品質は保証されていることを開示できるようにする。

ソフトウェアタグは経済産業省のプロジェクトの一つとして研究されているらしく、規格が決まってようやくタグの利用方法について議論が始まった状態らしい。

ソフトウェアタグが利用される状況は、SIerとユーザ企業の間で受託システムを契約して納品する時に使うことを想定している。
そのために、ソフトウェアタグの規格には、システム情報だけでなく、進捗に関する工数や、設計やソースコードに関するメトリクス、品質に関するメトリクスも含まれている。
ソフトウェアタグを使うことによって、SIerとユーザ企業の間で法的な争いごとが起きても、その資料として使える状況も想定しているらしい。

僕としては、システムの品質や開発の進捗に関するメトリクスをいつでも見れるから面白そうだと思ったが、実際のSIerのビジネスとしては複雑な問題がある。
質問タイムでの議論が面白かった。

現在の請負契約の元では、進捗情報を元に元請やユーザ企業が指示を出すと、違反になるらしい。
だから、あくまでも参考資料としてしか使えない。
そもそもSIerが工数をユーザへ出すのは抵抗感があるので、規格では必須ではなく、任意であるようにしているらしい。

このソフトウェアタグに興味を持つ企業は、中国やインドのオフショア先の企業。
彼らはこのソフトウェアタグを逆手に取り、逆に開発効率や品質の良さを他企業との差別化戦略に使いたいらしい。

ソフトウェアタグの話を聞いて、ソフトウェア開発に必要なメトリクスがある観点で提示されたのは面白いと思うと同時に、現場で使いこなすにはハードルが高いだろう、という感想も持った。
ソフトウェア工学にも同様の問題があるが、ソフトウェアタグもそもそもメトリクスの基準がはっきりしていないのだ。

バグ数と言っても、プロセスが安定していなければ、ばらつきが大きすぎて定量的にならない。
バグの検出基準も、会社だけでなくプロジェクトごとにバラバラであれば定量的にならない。

質疑応答時にもあったが、単体テスト時のバグ数のカウント方法も、一通りの単体テストが終わった後で別の人が単体テストでバグをカウントするやり方もあれば、実装完了後に開発者自身がバグをカウントするやり方もある。
当然両者の数は異なるし、後者のやり方で押し付けることはプロジェクトによっては難しい。

ソフトウェア工学では「計測できないものは制御できない」という根本思想の元でメトリクスを採取しプロセス改善していく手法を取るが、エンジニアリングの土壌が存在する仮定がそもそも難しい。

とはいえ、ソフトウェアタグが農産物や工業製品のように、要件からモジュールまでの追跡性、更には、品質に関する説明責任まで保証できるならば、非常に役立つ。
日本以外では規格がないらしいので、品質保証に強い日本発の技術になれば面白いだろうと思う。

| | コメント (0) | トラックバック (0)

2009/06/13

東京と名古屋のRedmine勉強会

東京のRedmine勉強会が昨夜開かれた。

Redmine勉強会で発表してきた - Sooey

events.php.gr.jp - Redmine勉強会

Redmine勉強会は盛り上がりました! - yandodの日記

内容を読んでいると、行きたかったなあ~。

「完璧なRedmineなど存在しない」資料では、Redmineを半年運用した結果、

プロジェクト数:18
チケット総数:1696
ユーザ数:22

と公表されている。

この数値を見る限り、大規模チームでもRedmineは十分に運用に耐えれるようだ。
Redmine導入マニュアルも作っているらしいので、公開されたら見てみたい。

チケットの登録における分類(トラッカー、バージョン、ステータス、カテゴリ、作業分類など)は、サマリで数値で出力されると嬉しい単位にすればいいと思う。
TiDDの利点の一つは、チケット集計結果を自動出力してくれること。
自動集計の機能のおかげで、毎週だけでなく毎日の進捗報告を自動出力できるから、プロジェクトマネジメントの意思決定に使える。

TiDDを突き進めると、チケットというマスタデータをいかに綺麗なフォーマットで大量に用意するか?という問題に置き換えられると思う。
チケットのデータが綺麗で揃っているほど、運用保守や進捗報告で大きな威力や意外性を発揮する。

また、名古屋でもTiDD入門が開かれる!

第13回勉強会『チケット駆動開発入門』ご案内 - 名古屋アジャイル勉強会 - Yahoo!ブログ

TiDDは今、日本で最も注目されているのかな?

| | コメント (0) | トラックバック (0)

2009/06/11

Redmineを使って気付いたことpart8~チケット駆動開発の先にある世界

チケット駆動開発やTestLinkなど各種ツールを運用して、SW開発とは一体何なのか?という疑問を感じた。
以下メモ書き。


Redmineでチケット駆動開発を実践すると、アジャイル開発における無駄な管理工数が減る。
TestLinkを導入すると、テスト工程における無駄なマネジメント工数が減る。
Hudsonによって、リリース作業の工数も減る。

では、それらでプロジェクトは楽になったのか?
確かに、以前よりも進捗管理は制御しやすくなった。

でも、SW開発そのものの難しさは変わっていないように思う。
むしろ、顧客と要件定義に時間を費やしたり、設計時に仕様変更の履歴を辿って本来の要件を理解しようとしたり、実装を意識した設計に時間を費やす。
いわゆる前工程へのフロントローディングが自然に行われるようになり、設計工程で多くの時間を割くようになった。

つまり、開発時の進捗管理に自信があるからこそ、曖昧な要件定義や設計工程にギリギリまで時間をかけることができる。
設計に時間を費やし、実装やテストはバグ無しで一発で通すようにする。
すなわち、リーンソフトウェア開発につながる。

SW開発ではビッグバン統合は失敗しやすい。
ウォーターフォール型開発や大規模案件が失敗しやすいのは、結合テストで初めて欠陥が人前にさらされるからだ。
もっと前工程で欠陥に気付けばいいのに、実際にシステムが初めて動く工程が結合テストだからだ。
IT業界は、結合テストでプロジェクトが火を噴くパターンを何度も繰り返している。


アジャイル開発の本質は、XPのプラクティスである小規模リリースに尽きると思う。
短期間の繰り返し型開発。
小刻みなVerUpで機能拡張していく。
小規模リリースはリスクが少ない。

「MS製品はVer3.0で使い物になる」とよく言われるが、MSのやり方もアジャイル開発に近いのではないか?
リリース当初は評判が悪くても、じきに市場を席巻する。

アジャイル開発のソース管理は、本番運用中と開発中の並行開発が基本だ。
いわゆるソフトウェアプロダクトラインに近い。
つまり、2本のコードラインで品質維持と最新ソースの同期を取る。
マージ作業は分散バージョン管理の方が楽な傾向がある。
GitやMercurialを使えば、ソース管理はもっと楽になるだろう。


チケット駆動開発は、プロジェクト管理や構成管理を全自動化する。
進捗管理、ソース管理、リリース作業の工数はそもそも不要。
PGがプログラムを作れば、即システムが出来上がる。

チケット駆動開発がなければ、従来通り、Excelの進捗管理やリスク管理しかない。
限られた工数のうち、マネジメント工数が実はかなりかかってはいないか?

アジャイル開発のような短期間の繰り返し型開発は、チケット駆動開発のように作業ステータスを自動集計する機構を必要としている。

KPTによるふりかえりで、イテレーション単位でリリース後の集計結果をメンバー全員に見せている。
それは、自分たちの開発チーム、そして各メンバーの成績表。
チームの開発速度、メンバーの貢献度が一目で分かる。
メトリクスの威力は恐ろしい。

チケット駆動開発がメンバーに根付くと、ワークフローと言う概念が自然に現れる。
どうやら、一つのチケットを他人に渡す時にステータスを変更して、他人に通知したいらしい。

バグ修正とバグ検証も然り。
課題の問合せと回答も然り。

それらのワークフローを集めたら、自然にそのチームの開発プロセスになっている。
Redmineならトラッカー、Tracならチケットの種類がワークフローに相当する。

ソフトウェア開発に必要なワークフローは一体どれだけ存在するのか?
それが分かれば、Redmineはソフトウェア開発のERPになりうる。


| | コメント (0) | トラックバック (0)

2009/06/05

【公開】ETWest2009講演資料「TestLinkでアジャイルにテストする」

ETWest2009の講演資料「TestLinkでアジャイルにテストする」を公開します。
CC Attribution ライセンスとします。

上記の講演で、TestLinkを半年間運用してみて、経験したこと、理解できたこと、そして確信したことは全て書いた。

一番言いたい事は、TestLinkがアジャイル開発の弱点の一つである受入テストを補強してくれることだ。
テスト駆動開発や継続的インテグレーションのプラクティスで単体テストの品質は保証できるが、結合~受入テストの品質を確保するのは、ウォーターフォール型開発だけでなくアジャイル開発でも難しい。

その問題の本質は、二つある。
一つは、受入テストの自動化は難しいこと。
もう一つは、手動の受入テストの生産性が悪いこと。

TestLinkの導入によって、手動の受入テストを効率化できると確信している。
だが最終的な目標である受入テストの自動化は、TestLinkだけでは足りない。

それを実現するには、テスト環境の仮想化と並行ビルドの技術が鍵を握ると思う。
そのアイデアは下記に書いた。

プロジェクト管理やテスト工程をクラウド化する: プログラマの思索

RedmineやTestLink、Hudsonなどのツールを駆使してソフトウェア開発していくに従って、問題の難易度が上がってきた気がしている。

ソフトウェア開発に銀の弾丸はないけれど、プロセスのレベルが上がるに従って、ソフトウェア開発の本来の問題点に少しずつ近づいてきたような気がしている。

ソフトウェア開発は、製造業や営業とは異なる本質的な特徴とそこから生じる根本問題がやっぱりあるのだ。

| | コメント (2) | トラックバック (0)

2009/06/03

TestLinkを運用して気付いたことpart5~TestLinkのテストケースの概念

TestLinkのテストケースの概念についてのメモ書き。

【元ネタ】
TestLink 実戦投入 - かおるんダイアリー


TestLinkの「テストケース」も「テスト計画」と同様に、「ビルド」(回帰テストの実施結果)と1対多の関係になる。

「テストケース」の状態遷移図を考えると、下記のようなフローになる。

アサイン前→未実行→成功 or 失敗 or ブロック

「アサイン前」の「テストケース」は「テスト仕様」にあるが「テスト計画」にアサインされていない状態。
つまり、イテレーション計画に組み込まれていないので、TestLinkへただ貯めている状態になる。

「未実行」の「テストケース」は「テスト計画」にアサインされて、いつでもテストを開始できる状態。
テスターは担当の「テストケース」をフィルタリングして、どんどんテストをこなしていく。

テストケースがいつも「成功」ならば良いが、やはり「失敗」する時もある。
この時、「失敗」したテストケースに依存するテストケースにも「ブロック」を付けて、テスト保留とする。

つまり、「ブロック」とは、バグが直らないと先に他のテストケースをテストしたとしても、再検証が必要になるテストケースの状態を指す。
例えば、Amazonのような小売系Webシステムでカート画面のテストケースが失敗したら、注文フローのテストケースは全て「ブロック」になるだろう。

TestLinkのテスト実施時には「ブロック」を上手に使うことが重要だ。
上記のような「ブロック」するテストケースは「見なしバグ」と言われるらしい。
つまり、テストしていないから失敗してないし、バグも出ていないが、テストしたら必ずバグが出ることになる。

「見なしバグ」のテストケースは一生懸命テストしたとしても、工数の無駄だ。
実際の現場では、バグが多発すると「見なしバグ」の切り分けが難しく、プロジェクト後半と言うただでさえリソースが少ない状況で、工数を無駄に浪費してしまいがちだ。
だから、「見なしバグ」のテストケースは保留として、他のテストを先行したり、本来のバグが修正したらすぐに再テストする管理が必要になる。

TestLinkでは、テスト結果をリアルタイムにモニタリングできるため、テスト結果を見ながら管理者はバグの状況に応じて、テストを中断したり、別のテストを指示したりする。

TestLinkの機能で惜しいのは、失敗したテストケースはバグ管理IDとリンクできるが、ブロックしたテストケースの発生源である失敗したテストケースIDにリンクする機能がないことだ。
ブロックの発生源のテストケースのステータスがTestLinkのテスト結果上で分かるようになれば、管理者の指示なしでテスターが自発的にテストできる状況になる。

TestLinkによるテスト管理には、世界中のテスト技術者のノウハウがたくさん詰まっていると思う。

| | コメント (0) | トラックバック (0)

2009/06/02

TestLinkを運用して気付いたことpart4~TestLinkの概念を再考

かおるんさんのTestLink経験談を読んで、TestLinkの概念をもう一度考え直した。
以下メモ書き。

【元ネタ】
TestLink 実戦投入 - かおるんダイアリー


TestLinkで重要な概念は「テスト計画」「ビルド」「テスト仕様」だと思う。

「テスト仕様」はテストケースの貯蔵庫。
Scrumのプロダクトバックログに相当する。

「テスト計画」はテストケースをイテレーションの単位でグループ化したもの。
Scrumのスプリントバックログ、XPのイテレーションに相当する。

「ビルド」は「テスト計画」の実施結果。
つまり、回帰テストの実施結果そのもの。
普通は、テスト対象モジュールのビルド番号、製造番号に相当するようだ。

概念モデル上では、「テスト計画」と「ビルド」は1対多の関係になる。
テスト計画を2回以上実施したいならば、ビルドを2個以上作ればいい。
この関係があるおかげで、回帰テストを管理しやすくなる。
回帰テストを自動化できる環境ならば、ビルドへテスト結果を流し込めばいい。
回帰テストは、デグレ防止にもなるから、システムの品質を更に強化してくれる。

運用上は、「テスト仕様」にあるテストケースをリリース計画に基づいて、どのイテレーションでテストするか、「テスト計画」へテストケースをアサインしていく。
この作業が真の意味でのテスト計画と言っていいと思う。

リリース計画、要件の優先順位付けなどから、どのテストを最優先に進めるか、手間をかけてでもテストすべきか、というマネジメントそのものになる。
更には、1次開発でバグを多く出した機能のテストケースがあるならば、2次開発以降でそのテストケースを再利用して、手間をかけてでも再テストする、などと言った戦略も取ることができる。

普通のシステムをリリースするまでの単体~受入テストまでの全テストケース数は軽く数千~数万になるため、テスト計画へ上手に分割する必要がある。
そうしなければ、全てのテストケースを実施するのに数ヶ月かかるだろう。
最悪な場合は、全てのテストケースを実施しきれないだろう。

たとえ、テスト工程を制御できているチームであろうとも、テスト工程で実施するテストケースを間引いて手を抜いていいわけではない。

TestLinkでテストケースの管理や実施結果の管理を始めると、テスト工程というプロセスの品質が今までいかにおろそかだったか、よく分かる。
つまり、全テストケースを実施できずに、品質保証すらできずにリリースしていなかったのか?という疑問が湧いてくるだろうと思う。

数千~数万のテストケースと実施結果を管理するのは並大抵の苦労ではないと思う。

|

« 2009年5月 | トップページ | 2009年7月 »