« 2008年10月 | トップページ | 2008年12月 »

2008年11月

2008/11/21

バグの優先度は意思決定プロセスの結果

バグの優先度は意思決定プロセスの結果であると喝破した記事がある。
チケット駆動開発(Ticket Driven Development:略してTiDD)の経験を思い出しながら考えてみる。

【元ネタ】
サン流だけど一流のバグ管理心得

バグにそもそものプライオリティなんかないんだ。バグはプライオリティとともにうまれるわけじゃない。
バグのプライオリティってのは、我々の決定なんだ。
単なる技術的な決定じゃない。単なるバグの影響度でもない。単なる重大性でもない。
バグは、リソース、ビジネス上の判断なんかによって、決定されるもんなんだ。

バグの優先度は、意思決定プロセスの結果なんだよ。
つまり、どれがバグで、どれがバグじゃないのかって決めたことのね。


チケット駆動開発(Ticket Driven Development:略してTiDD)を実践してみて、チケットの取捨選択はこのことなんだ!とようやく理解した。

TracやRedmineでは、チケットに優先度や重要度という項目がある。
優先度は、タスクが緊急の作業なのか、後回しでよいのか、を示すチケットの属性。
重要度は、チケットがシステム要件や顧客のビジネス要件の中で、どれだけその機能が重要なのかを示すチケットの属性。

Trac入門 ――ソフトウェア開発・プロジェクト管理活用ガイド」でも、Tracの優先度と重要度の違いについて説明している箇所がある。
その説明によると、優先度と重要度の概念について混乱があったらしい。

優先度は、開発者の作業の優先順位を決める重要な指標。
重要度は、顧客の観点から見た要件の指標。
優先度と重要度は、その属性に関わるアクターが異なる点が重要だ。

特に、優先度はチケットの取捨選択に大きく関わる。
例えば、システム上致命的なバグならば、そのバグ修正のチケットの優先度は緊急になるだろう。

最近のWebシステムならば、セキュリティパッチやSQLインジェクションなどのバグ修正が相当するだろう。
そんなバグを放置すれば、システムやデータの安全性、更には顧客が社会から信頼を失うといった危険があるからだ。

逆に、その機能の重要度は高いが緊急性は低いというタスクもある。
例えば、Amazonのような小売系Webシステムで新しい決済機能を実現する要件が出てきた時、顧客としては早く実装して欲しいが、バグ修正や今開発中の機能のリリースの方が緊急性が高い場合もある。

チケットの優先度は、顧客の利益やシステムの安全性、開発者の工数見積などの観点から、顧客と開発者の間で調整して初めて決まる。
だから、優先度は意思決定プロセスの結果という指摘は非常に洞察に優れている。

従って、プロジェクトリーダーは、顧客と開発者の間で調整して、タスクの優先順位を決めるという能力を必要とする。
その能力は調整という名の政治力そのものだ。
チケット駆動開発は、そんな意思決定の材料を色んな観点で提供してくれる優れたインフラなのだ。


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

2008/11/10

TestLink設定メモ

TestLinkを運用する時の設定メモ。

TestLinkはRedmine以上に癖が多く、デフォルト機能のままではすごく使い辛い。
大人数でテストケースを厳格に管理しようとして、逆に使い辛くなっているから、基本は制限を緩めた方が使いやすいと思う。

#八朔さんへの援護射撃になるかな?

【環境】
TestLink 1.7.4

【1】RedmineとTestLinkの連係

TestLinkテストケースが失敗になったら、バグ登録する。
この時、BTSと連携する重要な機能。
Mantis、Bugzilla、Trac、Redmineが連携可能だ。
BTSのURLを設定するだけでOK。

この機能を使うと、テスト実行画面で「失敗」ケースのバグアイコンからバグ管理IDを登録すれば、BTSのチケットへリンクできる。
更に、テスト結果画面にある「失敗したテストケース一覧」リンクから、NGケースとRedmineのチケットが一覧表示される。
しかも、Redmineチケット名は、「解決~バグxx発見!」というフォーマットなので、チケットのステータスも見える。
だから、チケットが解決ステータスになったら、テスト担当者はすぐに再テストすればいい。

このバグは直したんだっけ?
NGのケースはもうテストした?
という作業指示を僕が逐一出す必要が無い。

わずか数人のチームでさえも、TestLinkにインポートしたテストケースは優に1千件を超えている。
ExcelはSW開発で不要だ!とつくづく思う。

【2】メイン画面のロゴ変更
自分の会社やOSSのロゴを使いたい時に対応する。

/testlink/gui/themes/theme_m1/images
company_logo.png
を上書きする。

【3】大量のテストケースをインポート

TestLinkのメーリングリストで下記ツールを教えてもらった。

TestLinkはシナリオベースのテストケースが管理対象だ。
あくまでも手動テストケースを管理するツール。
だから、既存のExcelのテスト仕様書からいかに簡単にコンバートできるかが鍵。

テストケースは普通、Excel上で増幅して作るため、数千・数万のオーダーでテストケースをインポートしたい時が多い。
下記ツールで1千件ぐらいなら簡単にインポートできる。

v06_TestLinkCnvMacro.xls

【4】インポートのXMLファイルサイズを変更する
config.inc.php のTL_IMPORT_LIMITとTL_IMPORT_ROW_MAXの値を下記に変更する。

/** some maxima related to importing stuff in TL */
// Maximum uploadfile size
// Also check your PHP settings (default is usually 2MBs)
//define('TL_IMPORT_LIMIT', '204800'); // in bytes
define('TL_IMPORT_LIMIT', '2097152'); // in bytes

/** maximum line size of the imported file */
//define('TL_IMPORT_ROW_MAX', '10000'); // in chars
define('TL_IMPORT_ROW_MAX', '15000'); // in chars

【5】TestLinkのテストケースからExcelのテスト仕様書を作る

TestLinkのテストスイート・テストケースをエクスポート後、ExcelのXMLインポート機能を使う。
但し、レイアウト整形は手作業になる。

【6】テストスイート表示のパフォーマンス改善
テストケースが1千件を超えると、JavaScriptが原因でテストスイート表示機能が遅くなるので、下記に変更する。

custom_config.inc.php に、以下の記述へ修正
$g_tree_type='JTREE';

【7】日本時間に合わせる
 「config.inc.php - /** [CHARSET] */」への追加

   /** [CHARSET] */
   date_default_timezone_set('Asia/Tokyo');

【8】実行済みのテストケースの編集・削除を可能にする

TestLinkのデフォルト機能では、一度実行したテストケースを編集したり削除できない。
しかし実際のテストでは、テストした結果、設計書が間違っていてテストケースを編集せざるを得ない時は多い。

編集可能にするには、「config.inc.php - 516行付近」

/** [Test case] */
    :
//$g_testcase_cfg->can_edit_executed=0;
$g_testcase_cfg->can_edit_executed=1;


削除可能にするには、「config.inc.php - 559行付近」で

//$g_exec_cfg->can_delete_execution=0;
$g_exec_cfg->can_delete_execution=1;

【9】アップロードした添付ファイルをDBへ格納

テストケースにファイルを添付したい時がある。
TestLinkのデフォルトは普通にアップロードするだけだが、上記の設定でDBへ格納できる。
DBにある方が、SQLで一発で検索もできるし、バックアップや移行作業もやりやすい。

config_inc.php
316行

$g_repositoryType = TL_REPOSITORY_TYPE_DB; へ修正する。

【10】アップロードするファイルのMaxサイズを拡大

アップロードするファイルのMaxサイズを変更するには「config.inc.php 174行付近」の以下を変更。

  /** [GUI] */

  //define('TL_IMPORT_LIMIT', '204800'); // in bytes
  define('TL_IMPORT_LIMIT', '512000'); // in bytes

 「334行付近」

 //define("TL_REPOSITORY_MAXFILESIZE_MB", 1);
 define("TL_REPOSITORY_MAXFILESIZE_MB", 4);

【11】「テスト実行のアサイン」で「未割当」でも、テスト実行及びレポート出力できるようにする。
 また、Loginユーザー以外のテストケースも展開する。

実際のテストでは、テストケースを作りながらテストするときが多いから、アサインするユーザが決まっていない時が多い。
だから、条件を緩めないとテスト計画の全体像が見えない。

 「config.inc.php - 596行付近」

↓この設定を外すと、ユーザをテストケースにアサインしなくてもテスト実行できる。
  //$g_exec_cfg->exec_mode->tester='assigned_to_me';
 $g_exec_cfg->exec_mode->tester='all';

↓この設定を外すと、テスト実行時にアサインに関わらず、テストケースを全て表示できる。
//$g_exec_cfg->user_filter_default='logged_user';
$g_exec_cfg->user_filter_default='none';

【12】テストの実行で、(デフォルトで)実行した履歴を表示する

TestLinkのデフォルト機能では、最新の実行履歴しか表示しない。
下記の設定で、テスト実行の履歴が全て表示される。

 「config.inc.php - 533行付近」

/** [Executions] */
     :
//$g_exec_cfg->history_on=FALSE;
$g_exec_cfg->history_on=TRUE;

【13】テストケースをテスト計画へ追加画面で、チェックボックスのデフォルト表示=ONにする

TestLinkの管理機能はデフォルトのままでは非常に使い辛い。
数千件のテストケースをインポート後、テスト計画へテストケースを追加しようとすると、テストケスイートのチェックボックスを1個ずつチェックしなければならない。
だから下記でデフォルトでONで表示する。

/gui/templates/planAddTC_m1.tpl
ソースの書き換えが必要

124-127 このタグの最後に「checked」をつける

ユーザをテストケースへアサイン画面で、チェックボックスのデフォルト表示=ONにする
/gui/templates/tc_exec_assignment.tpl
ソースの書き換えが必要
85-87 このタグの最後に「checked」をつける

【14】ビルドのテスト結果画面(テスト実行画面)で、成功のラジオボタンのデフォルト表示=ONにする

デフォルトでは何故か「ブロック」になっている。
まとめてテストした結果を大量にコンバートする時、逐一「成功」を選択しないといけない。
そもそも、普通のテストでは、80%以上は「成功」のはず。
テスト結果が「ブロック」や「失敗」が半分以上のプロジェクトは、そもそも品質が悪いはずだ。

/custom_config.inc.php
カスタム設定ファイルに以下の設定を追加
$g_tc_status_for_ui_default = "passed"; // 成功:"passed", 失敗:"failed", ブロック: "blocked"

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

2008/11/09

ツールが開発プロセスを改善する

Redmineでチケット駆動開発(TiDD)を運用して気付いたことは、開発プロセスが大きく改善されただけでなく、従来の開発プロセスの弱点が浮き彫りになったこと。
下記の記事を読んで考えたことを書いてみる。

【元ネタ】
ケント ベック氏のアジャイル開発における開発支援ツールの役割についてのホワイトペーパー

元請SIerがTracのような環境を提供できない3つの理由 - なからなLife

元請け企業が用意すべきもの - T/O


【1】強力な構成管理ツールが無い時代はライブラリアンが独裁者

構成管理の基本は、任意のバージョンのシステムを再現できること。
今時、Subversionのようなバージョン管理ツールの無いSW開発プロジェクトはありえないだろう。

CVSやVSSが無かった頃は、構成管理ツールなど存在せず、構成管理を人手でやるしかなかった。
今でも、Excelなどの設計書はバージョン管理で制御されておらず、ファイルごとバックアップして運用するプロジェクトは数多い。

そのようなプロジェクトでは、プロジェクトリーダーよりも権限の強い人がいる。
それは構成管理を担当するライブラリアンだ。
彼が手作業で、プロジェクトで発生した成果物を手作業で分類し、日別で管理して、リリースしてくれる。
彼がいなければ、プロジェクトの成果物が作成できないだけでなく、彼が整理してくれている成果物を元に作業する開発者も困るだろう。

アジャイル開発でもXPは、ソースの共同所有や継続的インテグレーションのプラクティスで、構成管理に焦点を当てた。
ソースの共同所有のおかげで、誰もが最新のソースに触れて、最新の機能を追加できる。
継続的インテグレーションのおかげで、最新のビルドモジュールが毎日作られる。

特に、継続的インテグレーションはビルドの重要性をSW開発者へ再認識させて、HudsonのようなCIツールを生み出した。
Hudsonも構成管理ツールの一種と見なせる。

XPは、ライブラリアンや管理者主体から、プログラマ主体の開発スタイルへ変えようとした。
XPの主張は、その政治的メッセージだけでなく、構成管理ツールの必要性を再認識させた点が素晴らしいと思っている。


【2】構成管理ツールが開発プロセスの作業ステータスを見える化した

RedmineやTracという強力なプロジェクト管理機能を持つBTSは、チケット管理の機構によってSW開発の作業全てを管理できる。
この開発スタイルがチケット駆動開発。

僕がRedmineでチケット駆動開発を実践して、強く感じた点は下記2つだ。

一つは、チケットの取捨選択という本来のマネジメントを意識したこと。

XPやScrumは小規模リリースのプラクティスに従い、2~4週間のサイクルで小刻みにリリースする。
小規模リリースを実践するには、わずか2~4週間で、ユーザが使えるレベルまでシステムの品質を持っていかねばならない。
このバージョンアップ戦略では、短い期間で開発できる機能に分割し、小刻みなバージョンアップで対応しようとする。
この時に、チケットの取捨選択という技術力と政治力をミックスした高度な判断能力を要求される。

もう一つは、従来の開発プロセスで意識しなかった作業ステータスが現れたことだ。
最近、テスト管理ツールTestLinkとチケット駆動開発システムRedmineを運用し始めて、従来意識しなかったワークフローが見える化してきたという経験が僕の中で増えている。

先日、TestLinkを運用している開発者とKPTしたら、ステータスを追加して運用したいというTryがあがった。
つまり、下記のフローが具現化された。

新規←TestLink担当者がバグ発見!

担当←PLがPGをアサイン

解決←PGがSVNコミット

検証中←TestLink担当者が、解決チケットを検証する

検証完了←TestLink担当者がNGのテストケースを「成功」にするタイミングでチケットを検証完了にする

終了←PLが承認してCloseする

Redmineのデフォルト・ステータスには、検証中や検証完了のステータスは無い。
しかし、テスト担当者(TestLink)とバグ修正担当者(Redmine)が交互に作業し合うには、彼らの作業に対応するステータスが必要になった。

この経験を通じて、構成管理ツールが従来になかった開発プロセスを生み出しただけでなく、このような運用フローを意識しない従来の開発プロセスの弱点もはっきり認識できた。

バグは普通、結合テストのテストケースをテストしてNGの場合に発生する。
TestLinkでは、NGケースにバグ管理IDを紐づけできるので、バグ発生源を特定できる。

更に、TestLinkのNGケース結果画面で、NGケースとRedmineのチケットが一覧表示される。
しかも、Redmineチケット名は、「解決~バグxx発見!」というフォーマットなので、チケットのステータスも見える。
だから、チケットが解決ステータスになったら、テスト担当者はすぐに再テストすればいい。

このバグは直したんだっけ?
NGのケースはもうテストした?
という作業指示を僕が逐一出す必要が無い。

つまり、バグ修正フローでは、次々に現れるバグの修正に追われて、バグの状態を追跡できる仕組みが今まで誰もきちんと意識していなかったことが明確になった。

おそらくこのような現象が他にも色々あるだろうし、RedmineやTestLinkという強力な構成管理ツールのおかげで、開発プロセスがどんどん見える化するだろう。

【3】最近の構成管理は、メインラインモデル+チケット駆動開発に特徴がある

3-1.SVNのバージョン管理も、単なるコミット履歴の機能だけでなく、メインラインモデルを当てはめることが多くなったように思う。
メインラインモデルとは、trunkとbranchで最新機能のコードラインと保守コードラインを使い分けることだ。
いわゆる2系統のバージョン管理戦略に相当する。
例えば、Rubyならver1.9系がtrunk、ver1.8系が保守ブランチで分けて開発することに相当するだろう。

メインラインモデルの利点は、機能追加のコードラインとバグ修正だけのコードラインを別管理できること。
これによって、開発者は目的に応じて、それぞれのコードラインを修正したり機能追加するから、見通しが良くなり、コードラインそのものも安定する。
弱点はマージ作業が発生することだが、SVNのmerge機能やマージトラッキング機能などで、マージ作業の難易度は下がりつつある。

3-2.Redmineによるチケット駆動開発は、単なるバグ管理だけでなく、SW開発全般の作業ステータスを追跡できる点に大きな意義がある。

チケット駆動開発の運用の難しさはやはり、チケット管理にあると思う。

7日のKOFでは、こんな質問があったので、僕はこう答えた。

Q.チケットの粒度はどうやって決めますか?

A.僕は新規開発とバグ修正でチケットの粒度を変えます。

新規開発
→一つの成果物を作る作業をチケットにする。
 基本は担当者1人で5人日以内にする。
 例:設計書を作る、一つの機能を実装する、など。

バグ修正
→一つのバグをチケットする。
 PGとテスト担当者の2人で作業する。
 結合テスト以降では、1人だけの作業ではデグレが発生すると致命的だから。

以前、Tracはバグ管理はしやすいが、プロジェクト立ち上げでは使い辛いという話をよく聞いた。
チケットに何を書けばよいのか、分からないということだった。

よく聞いてみると、チケットを仕様書代わりに使おうとして失敗している。
チケットがバグ報告票なので、チケットはバグに対する仕様を書くものと見なしたらしい。

僕はチケットは作業指示書だと思っている。
だから、チケットには必ずアウトプットがある。
チケットはプロセス管理に使うものであって、成果物の管理に使うべきではないと思っている。

【4】構成管理の最終目的は、作業の透明化
ケント ベック氏のアジャイル開発における開発支援ツールの役割についてのホワイトペーパー 参照

ケントベックが言うには、リリース期間が短くなるにつれて、SW開発に質的変化が発生することを指摘している。
以前のウォーターフォール型開発なら、最後の1回だけリリース。
しかし、アジャイル開発なら、2~4週間のサイクルでリリースしなければならない。
だから、アジャイル開発はプロジェクト管理が非常に難しいのだ。

構成管理ツールの重要性をXPは指摘した。
この指摘によって、SW開発に何が起きたのか?

ケントベックが言うには、チームの作業の透明性が重要になったと言う。
テスト駆動開発で、自分が書いたプログラムが単体テストが通るか一目瞭然となった。
継続的インテグレーションによって、ビルドが毎日通るかどうか一目瞭然となった。
これは、開発者個人の作業が透明化されたことを意味する。
同様の現象が他にも起きるだろう、と。

チケット駆動開発は、SW開発の全ての作業のステータスを見える化する。
全ての作業が透明化される。

作業の透明化の利点は、コミュニケーションがスムーズになることだ。
デスマーチプロジェクトを見ると、負荷の高い人と低い人が極端で、大変な人を助けようというチームワークそのものがない。
構成管理ツールを導入してすぐに現れる効果は、コミュニケーションの改善と言われる。
チームの開発力をアップしてくれる。

今は、SW構成管理という概念そのものが実は曖昧だけれど、SW構成管理についてIT技術者はもう一度再認識すべきだと思う。


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

2008/11/07

何故、構成管理ツールが必要なのか?

最近の構成管理の運用について良い記事があったのでメモ。

SubversionとTracでファイル管理の“迷宮”から脱出 (1/4) - @IT

コラム 「プログラマー以外も必見! 文書の構成管理もできる」では、ソースだけでなくExcelのようなドキュメントもSVNでバージョン管理した方が良い理由が書かれている。
TortoiseSVNの差分機能も説明されていて、その利点が非常に分かりやすい。

最近の構成管理は、バージョン管理(SVN)+バグ管理(Trac、Redmine)で運用するのが業界標準になりつつある傾向を示しているように思う。


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

2008/11/06

チケット駆動開発はステータス追跡システム

チケット駆動開発はステータス追跡システムと思う。

チケットで作業ステータスを追跡できるのが最大の利点。

チケットの対象はバグ報告票だけでない。
機能追加、仕様変更、環境作り。
開発者から客への仕様の質問、客の問い合わせ、コードレビュー。

バグはもう直った?
NGのテストケースは今どうなっているの?
お客様から問合せがあったメールの件はどうなった?
この仕様の不明点はもう確認した?
コードレビューの指摘事項はSVNコミットした?

作業や質問のステータスをリアルタイムに知りたい。
全てはチケットファースト。

ステータスとワークフローを決めるのが本当のマネジメント。


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

2008/11/03

【告知】Redmineでチケット駆動開発を実践する~チケットに分割して統治せよ

関西Ruby会議01@関西-KOF2008
で以下を発表します。

◆場所
大阪南港ATC ITM棟 6F マーレギャラリー(受付・展示会場)
〒559-0034 大阪市住之江区南港北2-1-10


◆日時
11/07(金)15:00 (50 min)
会場
9F セミナールーム1

◆表題
Redmineでチケット駆動開発を実践する
~チケットに分割して統治せよ

◆概要
RedmineはRuby on Railsで作られたバグ管理システム(BTS)です。
RedmineはTrac(Python製BTS)と共に、従来のプロジェクト管理を根本的に変える 可能性を秘めており、一部で注目されています。
一部で提唱されている「チケット駆動開発(TiDD)」は、このBTSの開発スタイルをアジャイル開発の一プロセスとしてフレームワーク化を試みたものです。
今回は、Redmineでチケット駆動開発を実践して気付いたこと、考えたことについてお話します。

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

« 2008年10月 | トップページ | 2008年12月 »