マネジメントのスピードが開発のスピードに直結する

倉貫さん(XPJUG代表)の記事を読んで、システム開発に関する洞察が優れている点についてメモ。

【元ネタ】
アジャイル開発のボトルネック - Social Change!

(中略)
つまり、発注側のかけるコスト（工数）の限界が、ソフトウェア開発における速度の限界点なのだ。プロジェクトが成功するかどうかの分水嶺と言える。
これは実はアジャイル開発に限らず、一般的なウォーターフォールのソフトウェア開発でも、まとめて要件定義や検収テストをしているだけで、結局、同じくらいの工数がかかっていたのではないだろうか。もちろん、要件定義の前のビジネスや業務検討のフェーズを含めれば、である。
アジャイル開発では発注側が行う作業へのコミットが細分化されて見えるので、開発と同程度の工数が必要だという傾向が顕著に見えるだけかもしれない。発注側と開発側にかかる工数比があるように思わせたのは、そうしないと儲からないSIerの罪であろう。
『ソフトウエア開発においては、開発側が必要とする工数と、発注側が必要する工数を同等にするべきである』こんな法則があるのではないだろうか。そして、『発注側は、自社がかけれる工数（コスト）以上の、発注をしてはいけない』というルールでもあれば、うまくいくのではないだろうか。
(後略)

上記の指摘は、昨今のシステム開発の現状において非常に的を得ていると考える。

僕は、Redmineによるチケット駆動開発を運用して初めて、アジャイル開発はこういう開発スタイルなんだ！と実感した。
即ち、チケット駆動開発では、ロードマップ画面でバージョンをイテレーションに見立てて、小刻みに機能拡張しながらリリースしていく開発スタイルになる。
つまり、XPの小規模リリースを自然に具体化した開発プロセスになる。

すると、チケット駆動開発を運用する開発チームの内部作業はスムーズに進むようになり、顧客と仕様やスケジュールを調整するプロセスがボトルネックになってしまう現象が頻繁に起こるようになった。
例えば、開発チームではこういう仕様で進めるし、無理ならば代替の仕様が選択肢としてありますよ、と顧客に提示するが、そこで決定に時間がかかってしまう。
実際に作ってリリースして、顧客に見せたら、ちょっと違うよと言われる機能があったり、本来の要件が間違っていた事実も判明するが、どんなスケジュールで直していくか、優先順位を顧客が付けれない。
リリーススケジュールを開発側が提示して、返事待ちという状況が多くなる場合がある。

この状況の原因は、開発の速度よりも仕様やリリーススケジュールを決める速度が遅い点にある。

従来ならば、システム開発そのものに工数もコストもかかっていたが、Railsなどの優れたフレームワーク等のおかげでプログラミングの速度が上がってきた。
そして、RedmineやTestLink、チケット駆動開発で開発チーム内部の作業も効率化し、品質も安定するようになってきた。
すると、開発チームで制御できないプロセスがボトルネックになって、開発の速度に制約がかかる。
特に、レビューと言うプロセスでこの症状が顕著に現れる。

XPにはオンサイト顧客というプラクティスがある。
顧客も開発チームに加わり、ストーリーカードの優先順位付け、受入テストなどを行う。
実際の開発では、顧客が開発チームに入るのは難しいので、要件定義を行うSEがその役割を担っている。
倉貫さんはこの手法を「顧客プロキシ」(オンサイト顧客の代理人)と呼んでいた。

ここで、オンサイト顧客(要件定義を行うSE)の重要な役割の一つに、開発チームが作ったシステム仕様をレビューして、品質チェック後、承認するという作業がある。
このレビュープロセス(デザインレビュー)はすぐに完了できるわけではないし、レビュー後にその仕様で実装していくから、レビュープロセスのキューにどんどんタスクが溜まって、開発速度が落ちる現象が頻繁に起きるようになった。
かと言って、レビュープロセスを簡略化したり、無視していいわけではない。
そして、SEの代わりに顧客を連れてきても、状況はおそらく変わらない。

今の僕の経験では、デザインレビューが開発のボトルネックになっている。
つまり、デザインレビューの速度が上がらなければ、開発の速度が現状以上に上がらない。

要求を洗い出す作業と、要件を仕様化する作業は別の能力だと思う。
要求開発やBaBOKのレベルでは、業務の全体最適化(つまりエンタープライズアーキテクチャ)の観点から、システムのあるべき姿を導き出す。
しかし、我々ITエンジニアは、要件をいかにシステムとして実装して稼動させるか、という作業に注力を注ぐ。
それらの作業は大きく異なる。

その作業をつなぐ部分にボトルネックがあるのかもしれない。

TestLinkCnvMacroメモ

TestLinkCnvMacroの使い方が書かれていたBlogをメモ。

TESTLINKマクロのススメ - 台湾サラリーマン日記

TESTLINK エクセル変換マクロでデシジョンテーブルを取り込む。 - 台湾サラリーマン日記

TestLinkを中国語で使っている例としても興味深い。

テスト手法の概念をTestLinkで説明する

脱Excel！ TestLinkでアジャイルにテストをする － ＠IT自分戦略研究所で書ききれなかったテスト手法の概念についてメモ。

【元ネタ】
脱Excel！ TestLinkでアジャイルにテストをする － ＠IT自分戦略研究所

TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス: プログラマの思索

TestLinkを運用して気付いたことpart9～後追いテスト: プログラマの思索

下記の資料にまとめてみた。
ちなみに下記のテスト用語(方言？)はTEF関西のNakaさんから教わった。

Test Linkのテスト手法

View more presentations from akipii .

【1】ブロック、ブロッキングバグ、みなしバグ、みなしOK、周辺テストの概念

上記1枚目で、Ver2.0のカート削除1のテストケースでテストに「失敗」したとしよう。
その場合、カート削除2のテストは、カート削除1のバグに依存して必ず失敗するから、開発者をびびらせる意味も込めて「失敗」にする。
つまり、カート削除2のテストケースは、みなしバグになる。

更に、カート機能でバグが発生していて注文機能のテストを進められない状況の場合、注文機能のテストケースは全てテスト保留にする。
つまり、注文機能のテストケースはブロックになり、カート機能のバグが解消され次第、テストを再開できる。

又、カート削除1のテストケースからRedmineへバグチケットが発行される。
このバグは、みなしバグやブロックしたテストケースなど数多くのテストケースに影響範囲があるから、ブロッキングバグになる。
つまり、ブロッキングバグはテスト進捗を妨げる重大なバグである。

ブロッキングバグの修正が完了し再検証する場合、テスターには、ブロッキングバグの検証だけでなく周辺の関連機能も回帰テストするように管理者は指示しておく。
理由は、ブロッキングバグの修正で、デグレが起きていないか、他機能への考慮漏れが発生していないか、確認して欲しいからだ。
上記の例では、カート投入機能は既に成功しているが、もう一度最初から、カートへ商品を投入してカートから商品を削除するようにテストする。
これを周辺テストと呼ぶ。

Ver2.0のテストを実施していて、今回の機能改修でソースを修正しなかった機能のテストは、既に運用済みで品質が担保されている場合もありうる。
例えば、Ver2.0で念のために実施する必要があるものの、テスト工数や納期の関係で優先順位が低くテストしなくてもいい場合がある。

これらのテストケースをあらかじめ成功にするが、テストを実施して成功にする状態と区別するために、みなしOKというステータスにする。
但し、みなしOKのテストケースでもしバグが発生したら、結局全てのテストケースを再テストする必要がある。

上記をまとめると、テスト実行後のステータスは、未実施・成功・失敗・ブロック・みなしOKの5種類がある。
更に、テスト結果の検証に時間がかかる場合、検証中というステータスも欲しくなるだろう。
例えば、クレジットカードのシステムでリボ払いの計算結果を検証する時、テスト結果を取得するだけで、検証は後日行う場合があるだろう。
この場合では、テスト担当者とテスト検証者は異なる時が多いだろう。
つまり、ステータスは、未実施・成功・失敗・ブロック・みなしOK・検証中の6種類は最低必要ではなかろうか？

TestLinkでは、ステータスが未実施・成功・失敗・ブロックしかなく、GUI上からステータスを増やせない弱点はある。
しかし、Ver1.8以降では、設定ファイルcustom_config.inc.phpに下記の記述があるので、ステータスを増やせるかもしれない。

// $tlCfg->results['status_code'] = array (
// "failed" => 'f',
// "blocked" => 'b',
// "passed" => 'p',
// "not_run" => 'n',
// "not_available" => 'x',
// "unknown" => 'u',
// "all" => 'a'
// );

【2】後追いテスト、五月雨テストの概念

上記2枚目で、Ver1.0のリリースが目前に迫っている時だとしよう。
携帯のような組込み機器、業務システム、パッケージ製品のリリース直前では、1週間前～1ヶ月前からコードがFreezeされて、開発チームは、インストーラを作成したり、本番環境を構築する等のリリース作業に入る。
リリース確定後、出荷前までの期間で、テスト担当者が、みなしOKにしたテストケースをテストしたり、回帰テストを行うテスト手法を後追いテストと呼ぶ。

後追いテストの目的の一つは、空き時間を使って更なる品質チェックを行うことだ。
普通は、この時期では、製品に重大な支障が発生するようなバグは全て潰されているはずだが、表示がちょっとおかしかったり、UIをもう少し改善できるなど、些細な修正点はテストすればするほど出てくるはずだ。
そのようなプロダクトリスクの低いバグを洗い出し、次のVer1.1へマージしてリリースできるようにする。
但し、後追いテストで重大なバグが見つかった場合は、Ver1.0のリリースを延期することもあるだろう。

Webシステム開発では、リリースした本番ブランチ上のシステムに対して、リリース後に後追いテストで優先順位の低いテストを行う時もあるだろう。

一方、開発して単体テストが完了した機能から順次テストしていくテスト手法を五月雨テストと呼ぶ。
例えば、携帯のテストならば、SNSメール登録が先に開発できて、普通の携帯メール機能は開発中の場合、SNSメール登録を先にテストしてバグ出ししていく。
そのテスト結果を開発チームにフィードバックして、普通の携帯メール機能にも取り込んでいく。

アジャイル開発は基本は五月雨テストだと言える。
つまり、開発できた機能から順次テストしていく開発スタイル。
脱Excel！ TestLinkでアジャイルにテストをする － ＠IT自分戦略研究所で紹介した僕のテスト手法は、五月雨テストと同じだ。

僕がTestLinkを運用した時、テスト計画のテストケースが少ない場合、テスト計画をイテレーションに含めた。
逆に、テスト計画のテストケースが多い場合、開発のイテレーションから分離して、テスト計画を更に分割して、複数のイテレーションで順次テストしていった。
例えば、結合テストPh1・Ph2、システムテストPh1・Ph2・Ph3のようにテスト計画を順次実施していくテスト戦略になる。

僕のやり方とは別に、第5回　脱Excel！ TestLinkでアジャイルにテストをする - hokorobiの日記にあるhokorobiさんのテスト手法のように、1個のテスト計画で複数のビルドで管理する方法もある。
これは、Excelのテスト仕様書の管理と同じように、1個のテスト仕様書へ結果を追記していくのと同じやり方だ。

僕もこのやり方を試した時はあったが、アジャイル開発に組み込みにくかった。
理由は、イテレーションと言う概念を当てはめにくいから。
テストで一番嫌なのは、テストすればするほどバグが出て、バグ修正＆検証がエンドレスになってしまうこと。
イテレーションがあるからこそ、リリースが定期的にあり、プロセスを改善するタイミングが生まれやすい。

また、ビルドの途中でテストを中断して、次のビルドに移るから、テスト実行結果のステータスが曖昧になりがち。
そもそもブロックを使う必要もない。
ブロックや見なしバグなどが必要な理由は再テスト工数を計算したいからだ。
100件のテストを行う場合、10件失敗すれば、テスト工数は110件も膨れ上がる。
プロジェクト管理の基本はクリティカルパスの管理だから、再テスト工数を見積もるのは非常に重要なのだ。

又、テスターが少なすぎたり、テスト期間が短すぎたり、テストケース数が多すぎると、テスト計画を立てた時点でもはや全てテストできなくなる確率は大きい。
特に、デシジョンテーブルや直交表でテストデータのパターンを作りこむシステムテストでは、テスト網羅の観点からテストケース数が爆発しやすく、その危険は高い。
だから、イテレーションにテスト計画を組み込むことで、テスト工程のマネジメントを管理しやすくするのだ。

【3】とある勉強会で、最近のシステム開発の傾向は品質よりも納期を重視しているようだ、という話があった。

ビジネス的背景としては、3ヵ月後の景気すら誰も分からない状況で、数年もかけてシステム開発するのはリスクが非常に高い。
また、MixiアプリやGoogleのサービスのように、先にリリースした者がマーケットを支配する状況が多くなっているからだ。
だから、最低限の品質は担保した上で、小刻みにリリースしていく開発スタイルが多くなっているように思う。

更に、技術的背景としても、後追いテスト、五月雨テストのようなテスト手法がやりやすくなっている。
例えば、携帯電話やiPodのような組込み機器でも、リリース後にSWアップデート機能でアプリケーションだけでなくROMそのものも更新できるようになった。
Webシステムなら、サーバーにデプロイさえすればいいから、リリースしやすい。

つまり、後追いテスト、五月雨テストのようなテスト手法は昨今のSWテストにマッチしやすい特徴があると思う。

TestLinkはまだまだ機能改善の余地があるけれど、上手に使いこなせれば、テストプロセスの品質向上で大きな威力を発揮できると思う。

【公開】脱Excel！ TestLinkでアジャイルにテストをする － ＠IT自分戦略研究所

下記の記事を公開した。

脱Excel！ TestLinkでアジャイルにテストをする － ＠IT自分戦略研究所

上記の記事で、TestLinkで経験したこと、考えたこと、理解できたことは全て書いた。
記事のポイントは3つある。

一つ目は、TestLinkをアジャイル開発に組み込むための運用サイクルを工夫したこと。
基本は、TestLinkのテスト計画をイテレーションの一部、あるいは、開発とは別のイテレーションに見立てて、小刻みにテストしながらリリースしていく運用にする。
これによって、テストするほどバグが出て、延々とゴールのないシステムテストから解放される。

二つ目は、TestLinkに合わせたテストケースにすること。
結合テストやシステムテストで実際に使うテストケースを例にあげたので、理解してもらえると思う。
他人の話を聞くと、膨大な既存のテストケースをTestLinkにインポートする方法に苦労しているようなので、参考にして欲しい。

三つ目は、TestLinkとBTS(Redmine)と連携して、バグ修正とバグ検証をワークフロー管理すること。
この手法によって、バグ修正(PG)とバグ検証(テスター)がペアプロのように作業できるので、品質向上に役立つ。
更に、テストに失敗して影響範囲が大きい場合、テストケースをブロックする。
このブロックというステータスについても、詳しく説明した。
ブロッキングバグ、みなしバグという概念によって、再テスト工数が計算でき、最終的にはテストのクリティカルパスを導くことができる。
テストケースのステータスは「成功」「失敗」以外にも色々あることを知って欲しいと思う。

感想があれば是非フィードバックして欲しいです。

ソフトウェアテストPRESS Vol.9にあるTestLinkの記事

ソフトウェア・テスト PRESS Vol.9にありえるえりあさんによる TestLinkによるテスト管理記事が載っていたのでメモ。

【元ネタ】

TestLink使用レポート ― ありえるえりあ

TestLinkを検証しました ― ありえるえりあ

SWテストを管理者・開発者・テスト担当者の観点から書かれていて面白かった。
TestLinkの内容は上記のBlogと殆ど同じだった。

興味深かった点を書いておく。

【1】開発チームとは別にテストチームを作った理由が書かれていた。

元々、プログラミングによる開発が一番大事で、そもそもテストチームは必要とは思えなかった。
知っているテスト担当者から愚痴ばかり聞いていたから。
しかし、開発してテストしてリリースする一連の作業で、開発者だけの場合、開発者は実装するよりもテストする作業が半分以上に増えて、肝心の開発作業が滞りがちになった。
だから、開発者がバグ修正に専念できるように、テストチームを作らざるを得なかった、と。

この理由はなるほどと思わせる。
開発チームとテストチームの2つの部隊を作らざるを得ない理由は、マネジメントの問題なのだ。

単純な単体テストレベルならば、開発者もやっているが、システムテストや受入テストのレベルになると、テストの事前条件やテストデータの作りこみに手間がかかる。
更に、テスト結果の検証作業も、システムテストや受入テストでは、とても大変になりがち。
開発の片手間でできる作業ではない。
だから、テストチームの役割は、複雑なテスト作業とその検証作業の専任になる。
特に大規模開発ほど、この傾向は強いだろう。

又、テストチームのコストについて書かれた内容も興味深かった。
いわく、テストチームそのものは開発上のコストになるが、当社はパッケージ製品の開発が主業務なので、実際のテストは回帰テストが多い。
つまり、単純になりがちなので、テスト担当者が専門でテストした方が、開発者は実装の専念しやすい、と。

ハードと違い、ソフトはどんどんバージョンアップしていく。
だから、過去のバージョンの機能がデグレせずに正常動作することを検証する必要がある。
つまり、バージョンアップするに従って、テストケースは単調増加で増えていく。

過去のバージョンのテストは結局、回帰テストになる。
機能テストのレベルならばJUnitでテストを自動化できるが、システムテストや受入テストでは、UI周りのテストを自動化する速度よりも機能追加の速度が早くて追いつかず、結局、コストが合わない時が多い。

この辺りの解決方法の一つとして、TestLinkで手動のテスト作業の管理を効率化する点があるだろう。

【2】リリース判定条件として、信頼度成長曲線を止めて、タイムボックス形式(イテレーション)へ変更した理由が書かれていた。

ハードのように、信頼度成長曲線を書いてバグの歩溜まりになったらリリースする判定条件にしても、実際はリリース後に障害が数多く発生する時は多い。
その理由は、ソフトでは、信頼度成長曲線は人為的に操作しやすいからだ。
例えば、テストするスコープを狭めれば、確かにバグは減っていくだろう。

しかし、実際のソフトウェア開発は、仕様変更が任意に勃発するので、長期間スコープが固定化された状態はありえず、結局、バグはいつまで経っても収束しない時は多い。
だから、オープンソースのようにタイムボックスごとにリリースしていくのが一番現実的だ、と。

このリリース手法は、まさにアジャイル開発そのもの。
タイムボックスをイテレーションと見なせば、イテレーションというサイクルで小刻みに機能追加しながらリリースしていく開発スタイルになる。

アジャイル開発の場合、短い期間だけれどもイテレーションの間はスコープは固定されているので、品質を高めやすい利点がある。

例えば、イテレーション期間中に仕様変更が生じたら、次のイテレーションで対応するとアナウンスすればいい。
まずは目の前のイテレーションの機能を実装してリリースするのを目標とする。

又、品質とは、単に信頼性だけではない。
顧客にとっての価値とは、欲しい時に欲しい機能があることなのだから、納期も重要な制約条件だ。
品質重視でリリース時期が遅れたら、顧客のビジネスにも支障が出やすい。
だから、アジャイル開発では、スコープを制御することで、品質を保持し、納期を守るようにするのだ。

テスト工程のマネジメントは、上流工程のマネジメントよりもはるかに難易度が高い事実を改めて考える必要があると思う。

形式手法とHaskellについてメモ

いけがみさんの記事を読みながら、思ったことをメモ。
＃まとまっていないので、あくまでも妄想です。

【元ネタ】
Inemuri nezumi diary(2009-02-05)

2009-06-23 - a-sanの日記
不正な状態遷移を見つけるアルゴリズム - a-sanの日記

僕が形式手法に興味を持った理由は、設計工程でモデリング作業の品質を上げることができて、更にテストケースを生成してくれるのではないか、という期待があったから。
でも、形式手法は確かに凄いのかもしれないが、言語もツールもオープンでないので使いづらい。
いけがみさんの言う通り、完璧な仕様を求めようとして、結局無駄な力を注いでいるのかもしれない。

モデリングは結局、事前条件と事後条件をつなげて一貫性と整合性が取れているか、そして状態遷移図が矛盾なく整合性が取れているか、という作業に落ち着くと思う。
関数型言語Haskellでも、形式手法でやりたかったことが同様にできるのではないか？

少なくとも、「不正な状態遷移を見つけるアルゴリズム - a-sanの日記」にあるHaskellのプログラムは、状態遷移図の整合性チェックができることを示しているように思う。

Haskellも僕にとって難しかった。
モナドや遅延評価だけでなく、関数型言語そのものの発想がないから。

でも、プログラムだからいくらでも試せる。
Howを考えるのではなく、Whatを考えるようにHaskellプログラムを書けばいい。
Haskellを書きながら、問題設定を考えながら、仕様を考えているのだ。
できれば、Haskellプログラムからテストケースを生成したい。

現在、考えている荒筋は下記の通りだ。

MSのPairwise法ツールPICTをエンジンに持つテストケース自動生成ツールMTGに状態遷移表を書けば、パラメータの組み合わせを生成してくれる。
その結果をTestLinkCnvMacroに貼り付けて、ちょっとだけフォーマットを整えれば、テストケースを出力できる。
そのテストケースをTestLinkへインポートすれば、TestLink上でテスト作業を一括管理できる。

つまり、質の良いテストケースを出力できれば、後はTestLinkでテスト作業をコントロールすればいい。
そのために、MTG→TestLinkCnvMacroのツールを使う。

MTG プロジェクト トップページ - SourceForge.JP

TestLinkCnvMacro - SourceForge.JP

後は、MTGへ吐き出すためのパラメータや制約条件がHaskellや形式手法、あるいはUMLの状態遷移図から作れればいい。
実際は、その部分が自動化できておらず、手作業になっている。

チケット駆動開発や構成管理に比べると、テスト工程の自動化はとても難しいが、どこまで可能か考えてみたい。

テストケースの作り方

TestLinkを運用し始めて、改めてテストケースの作り方が重要と思うようになった。
TestLinkのマスタデータであるテストケースの品質がよくないと、TestLinkの効果が出ない。

「はじめて学ぶソフトウェアのテスト技法」も「知識ゼロから学ぶ ソフトウェアテスト」もテストケースの作り方について初心者向けに書かれているようなのでメモ。

テストケースは基本は、パラメータの組み合わせだと思う。
パラメータの洗い出しは業務や設計が分かっていないとできないけれど、そこからテストケースを作成するプロセスはツールで自動化できないか探っている。

MicrosoftのPairwaise法(All-pairs法)ツールPICTを利用したテストケース自動生成ツールMTGに着目している理由も、テストケース作成のコストを下げて、品質を保持したいから。

又、テストの本で不思議なのは、ブロックの使い方について説明した本が見当たらないことだ。
TestLinkのブロック機能は、テスト工程のマネジメントを掘り下げる重要な概念だと思う。

Nakaさんにその不満をぶつけた所、「基本から学ぶテストプロセス管理―コンピュータシステムのテストを成功させるために」がいいと勧められたのでメモ。

TiDDとWFとScrumとLeanの違い

開発プロセスの違いについて良い記事があったのでメモ。

【元ネタ】
[Agile]WFとScrumとリーンの違い | Ryuzee.com

WFの弱点は「計画に依存しすぎているので、計画が間違っていたらリスクが高い」「プロジェクトの終了直前のデプロイまで、何の価値も実現できない」点にある。
実際の現場では、結合テストで火を噴いてビッグバン統合に失敗する症状に全てが言い尽くされていると思う。

このWFを繰り返し型開発へ変形した場合、確かにリスクは減るが、最大の弱点は「ボトルネックが発生してしまい、それを制御できない」点にある。
全ての作業の遅れが積もり積もって、バッファを食い潰すのだ。
TOCのクリティカルチェーンの話を思い起こさせる。

Scrumではイテレーション単位に、Plan・Build・Test・Reviewが並行で動き、リリース前にReviewとDeployが行われる。
つまり、実装とテストとペアプロが一緒になっていて、実装した機能は常時統合される。

Leanの絵では、もはやイテレーションの概念が1日の単位に収まってしまう意味だろう。
Leanはアジャイル開発の究極の理想形だが、実際はなかなか実現できないだろう。

では、TiDDはどうか？
下記のようなイメージだと思う。

TiDDライフサイクル

View more presentations from akipii .

僕の経験では、Planでイテレーション計画、もっとスパンの長いリリース計画を立てて、イテレーション単位で機能を小刻みにリリースしていく。

当初、イテレーションにアサインされたチケットも、開発中に延期されたり、追加されたり、優先順位が変わったりする時もあるだろう。
だから、実際の作業は、チケットに従って、Plan・Build・Test・Reviewが並行で動く。
このフェーズまでは、RedmineのようなBTSで管理すればいいだろう。

そして、システムテスト、受入テストはイテレーション後半に別途実施する。
理由は、単体テストや結合テストを終えて常時統合できたからといっても、品質に不安はあるからだ。
顧客の観点からテストして、要件が実現されているか、検証するフェーズが必要だ。
そのフェーズは、全ての機能がほぼ動作するレベルが最低条件であり、Plan・Build・Test・Reviewが並行で動く最中で、システムテストや受入テストは実施しづらいからだ。
このフェーズでTestLinkを使うと有効だと考える。

本当はLeanのような開発ができれば、イテレーションのない世界、つまり、バージョンが必要なくなる。
しかし、実際のSW開発は複雑怪奇で、そんな綺麗な開発はありえない。
現実と妥協すると、アジャイル開発はTiDDに落ち着くのではないかと思っている。

プロジェクト管理インフラのふりかえり

プロジェクト管理インフラを使った履歴が書かれていたBlogがあったのでメモ。

【元ネタ】
僕はこんな開発インフラを使ってきた - watawata日記

以前は、VSS＋VisualStudioの環境がいまいち慣れなくて、CVS＋EclipseがJavaの開発環境で十分だと思っていた。
全てフリーだし。

そして、TracとSubversionが出た頃から、急激に開発環境が改善されつつあるように思う。
バージョン管理は、SVNからGitやMercurialへ発展している。
SVNでbranchの使い方が分かった。
そして、Mercurialを使いながら、可能性を秘めている分散バージョン管理について色々試している。

BTSは、Mantis、Tracもあるが、僕はRedmineが一番フィットしている。
Redmineで、リリース予定のバージョンを定めて、リリースできる単位でチケットを取捨選択するやり方がとてもアジャイルな感覚だから。
その方法から、クリティカルパスや工数管理などのプロジェクト管理につながる。

ビルドツールは、最初はContinium＋Mavenを使っていたが、ビルドはしてくれてもデプロイは手作業なのでイマイチだった。
Mavenも設定が多くて、あまり楽になった印象がない。
Antでビルド＆デプロイのスクリプトを自分で書き、Hudsonでビルド＆デプロイさせたら、ワンクリックでリリースできるようになった。
しかも、HudsonはRedmine、SVNと相性がいいので、非常に便利。

そして、テスト仕様書もExcelからTestLinkに変えて、テストのマネジメントの奥深さを色々考えている。
テストと品質保証はアジャイル開発の最後の難問だから。

ここ2、3年でプロジェクト管理ツールが急激に改善されている。
マネジメント手法そのものが、従来のExcelや文書でやり取りするやり方からツールでリアルタイムに情報共有するやり方へ改良されて発展している。
それらのツールはまだ発展途上で、ツール同士の連携も未完成だが、ツールが開発プロセスへ与える影響は今後大きくなるだろうと思う。

ITILのプロセス関連図

とある勉強会で、クレーム処理でITILの話が出てきたので、整理するためにメモ。
下記のプロセス関連図でITILは全て説明できる。

ITIL：Information Technology Infrastructure Library - Wikipedia

Itilプロセスフロー

View more presentations from akipii .

ITILのプロセスは、PDCAサイクルで覚えればいい。
但し、起点がPlanの変更管理とCheckのインシデント管理の2パターンがある。

RFC(変更要求)が来た場合、変更管理プロセスで、要求を実現するための計画を作る。
つまり、CAB(変更諮問委員会)がステークホルダーを集めて、例えば、実装方法やリリース作業、そしてレビューやテスト方法、評価などの方針を議論して、決定する。

次に、変更管理で作られた計画に従ってリリース管理で、作業者が対応を行う。
実際は、ソースを修正してテストして、リリースする。

他方、顧客からクレームが来た場合、サポートデスクでインシデントとして受け付ける。
サポートデスクは普通は、女性の事務オペレータだったりする。
インシデント管理では、クレームが障害なのか要望なのか単なる質問なのか、を整理する。
障害の場合、暫定対応を連絡する時もある。

次に、障害だと判明したら、問題管理に送られて、BTSへ登録し、根本原因の究明を行う。
問題管理では、原因調査と是正対策を取るのが目的であり、すぐに直すわけではない。

ここでよく出る言葉は、SLA(Service Level Agreement)、いわゆるサービス品質維持契約。
顧客とSIerで、運用するシステムの品質を契約にする。
インシデント管理におけるクレーム情報、問題管理における障害情報から、SLAを満たしているか評価するのに使われる時が多い。

そして、問題管理で作られた是正対策をインプットとして、変更管理で実装計画を立てて、リリース管理で実装・リリースを行う流れになる。

構成管理は、変更管理・リリース管理・インシデント管理・問題管理を支えるインフラであり、CMDB(構成管理データベース)で一括管理されている。
CMDBには、CI(構成アイテム)とCIの作業履歴が登録されている。
SVNリポジトリをもっと汎用化したもののようにとらえればいいだろう。

この流れを詳細化すればITILの用語や説明は分かる。
だからITILはそれほど難しくない。

でも、ITILの発想は、抽象的なPMBOKよりもSW開発の現場で非常に役立つと思う。
チケット駆動開発でも、ITILのプロセスフローを参考にした。
SW開発の現場リーダーは、ITILの考えに触れておくと、RedmineやTestLinkで何ができて何が利点なのか、よく分かるだろうと思う。

昨今、情報処理試験でも情報セキュリティとサービスマネージャ(ITIL)の資格が重視されていると聞いた。
ITILファウンデーションの資格は、このプロセスを詳細化したぐらいで簡単に合格できる。

アジャイル開発の最後の弱点

テスト工程のマネジメントは、ソフトウェア開発の上流工程におけるプロジェクトマネジメントよりもはるかに難易度は高い。
TestLinkを使ってみると、Redmineの運用よりもはるかに難しい。
一つでもバグが出るたびにブロックが発生して、前進できないのだ。

ブロッキングバグをストッピングバグとも呼ぶ事実を今夜初めて知った。
テストでは、ブロッキングバグ修正の優先順位付けがとても重要。
ブロッキングバグが直れば、ブロックした大量のテストケースを再開できるからだ。

そして、テストにもクリティカルパスがある。
プロジェクト管理の基本はクリティカルパスの管理だから、テスト工程のそれを見つけて、意思決定を間違えないように管理するのが凄く大事。

テストと品質保証はアジャイル開発の最後の弱点。
チケット駆動開発によって、SW開発のタスク管理やワークフロー管理はスムーズになる。
しかし、テスト工程では、チケットとテストケースは概念が全く異なるため、チケット駆動開発の効果が出ない。

もう少し考えてみる。

オープンソースのプロジェクト管理ツールの方が優れている理由

久しぶりにRedmineを使い始めた。
やっぱりTracよりもRedmineの方が楽しい。
バージョンにチケットをアサインして、チケットの取捨選択を考えたり、ソースコミット時にチケットNoを書いてリンクさせたり、チケットを消し込んでバージョンをリリースへ持っていくのが楽しい。

Redmineの方がチケット駆動というよりもバージョン駆動なので、その感覚がアジャイル開発とフィットしていてすごく好き。

TestLinkも最新バージョンを実験的に使い始めた。
テストケースやテスト結果にテスト予定日・実績工数・予定工数を入れると、TestLink上で集計する機能があるようだ。
まだまだ使い勝手は悪いけれど、TestLinkにテストの進捗管理機能ができてガントチャートを表示できるようになれれば、強力になるだろう。

MTGというPairwise法でテストケースを自動生成するExcelマクロを試している。

状態間の往復がある状態遷移のテストケースをPairwise法（All-pairs法）で生成する｜多種類テストケース生成ツール MTG （Multi type Test case Generation tool）

上記ツールを使った発表は、SQIP2009でも聞いた。
「Pairwise法と制約表による制御パステストのテストケース自動生成」　講演資料PDF

設計プロセスとテストケース作成をつなげられないか、形式手法など色々探ったけれど、Pairwise法を使ったExcelマクロでテストケースを生成するのが一番簡単な気がしてきた。

MTGを使うと、下記のような使い方ができる。

PictMasterでデシジョンテーブルを作成する !?｜多種類テストケース生成ツール MTG （Multi type Test case Generation tool）

PictMasterの結果表を使ってデシジョンテーブルを生成する｜多種類テストケース生成ツール MTG （Multi type Test case Generation tool）

PictMasterで「通常」の条件網羅の制御パステストケースを生成する｜多種類テストケース生成ツール MTG （Multi type Test case Generation tool）

状態間の往復がある状態遷移のテストケースをPairwise法（All-pairs法）で生成する｜多種類テストケース生成ツール MTG （Multi type Test case Generation tool）

僕が興味を惹いたのは、状態遷移図から状態遷移表を起こして、状態遷移のテストケースを自動生成する手法だ。
このやり方を使えば、状態遷移図の整合性を設計プロセスで考えることもできるだろう。

MTGのエンジンには、MSのPairwise法ツールPICTがある。
だから、テストケースの制約条件も考慮できるので、テストケース生成としてはかなり強力だと思う。

MTGが生まれた発端が下記に書かれていた。

なぜオールペア法なのか？｜多種類テストケース生成ツール MTG （Multi type Test case Generation tool）

最近思うのは、プロジェクト管理やテスト管理を楽にしてくれるツールやノウハウはどんどん公開して欲しいことだ。
それらのツールもノウハウもネット上には殆どなく、商用ツールだったり、特定の会社や非公開の勉強会でしかノウハウが得られない。
すると、せっかくのツールもノウハウも世間に普及せず、10年前と同じ手法でいつも失敗している。

Redmineも最初は機能もUIも未熟だったけれど、世界中の開発者がポテンシャルを感じて、たくさんのフィードバックをあげるうちに、Tracの開発速度を追い抜いて、優れたBTSになった。
TestLinkも日本語分科会の人達のおかげで、少しずつ普及し始めて、その可能性について色々議論している。

形式手法も優れた手法なのかもしれないが、ネット上で公開されておらず、オープンソースにもなっていないから、結局どう使っていいか分からない。

Googleの検索エンジンのおかげで、世界中の開発者のノウハウがつなげられれば、大衆の知恵のようになる。
今の時代は、一人の天才がツールを作るよりも、世界中の開発者がよってたかって作り上げる方が開発速度も品質も良くなるし、そしてその機能に込められたノウハウがベストプラクティスになる。

MTGにはすごくポテンシャルを感じているので、理解できたことを書いていきたい。

プロジェクト管理ツールの目的はプロセスの透明化

開発抽象化レイヤ - The Joel on Software Translation Projectを読み直して、もう一度考えを書き直す。

【元ネタ】
開発抽象化レイヤ - The Joel on Software Translation Project

開発抽象化レイヤーを担う人: プログラマの思索

RedmineやTracによって、Excelからタスク管理やワークフローをIT化する。
昨今の高機能なBTSによって、ワークフローやプロセス管理を開発者は特に意識せずに開発できる。

TestLinkによって、Excelからテスト管理をIT化する。
管理者やテスト設計者は、膨大なテストケースの管理や複雑なテスト計画・集計作業から解放される。

SVN、Mercurial、Gitによって、ソースだけでなく、WordやExcelのドキュメントもバージョン管理する。更に、BTSと連携してソースやドキュメントをチケットに紐付ける。
開発者も設計者も、ソースやドキュメントの変更理由をチケットから類推できる。

これらのツールが目指すのは、プロセスを透明化することだ。
ジョエルの言う開発抽象化レイヤを狭義に捉えると、開発者がプロジェクト管理を意識しなくてもクリエイティブに開発できるようにすることだ。

作業者がツールを使いこなせば、ツールの機能に隠されたベストプラクティスによって、自然にプロセス管理されている。
プロセス管理でがんじがらめな開発になるのではなく、複雑な連携作業やワークフロー管理はツールに任せて、開発者はクリエイティブに開発できる。
管理者も、マネジメント情報を収集する作業から解放されて、経営者のようにツールから出力されたマネジメント情報を使って、高度な意思決定に注力できる。

ソフトウェア開発において、プロジェクト管理やテスト管理、品質管理の問題が急速に言われ始めたのは、プログラミングを中心とする下流工程でここ10年大幅な技術革新が行われたのに、プロジェクト管理の技術が旧態依然のままで、プログラミングの速度に追いついていないからだろう。

Excelでチマチマと手作業で管理する技術は、RailsやSeasarのようなWebプログラミングの速度にマッチしていない。
わずか10～20人月のプロジェクトでLOCが1万行を超え、テストケース数も1千を超える規模では、ツールでプロジェクト管理を補完しなければ、せっかくのプログラミング技術の生産性も落ちる。

ツールに必要な物は何か？
それは、常に最新の作業情報、成果物、そして仕様。

最新の作業情報を入力データとして、BTSによるチケット駆動開発がプロセスを透明化する。
最新の成果物を入力データとして、バージョン管理ツールが開発プロセスのインフラを提供し、BTSとソース管理が連携して、成果物と作業情報を連携してくれる。

最新の仕様を入力データとして、ツールが仕様と成果物が紐づく。
この部分のツールは、TestLinkの要件管理機能のように、まだ不十分。
でも、昨今のように短期間で開発するには、作業情報と成果物と仕様が密接に連携できるツールを必要としている。

要件管理はテストの目的のために存在する

要件管理とテストの関連についてメモ。

【元ネタ】
Software Testing - Columns: VerificationとValidation

テスト管理のベスト・プラクティス

ソフトウェア開発のすべての規律はテストの規律と関連がありますが、その中でもテストと特に重要な関連を持つ規律がいくつか存在します。
* 要件管理
* 変更管理
* 構成管理
「要件管理」は、大部分のテスト作業に先行するもので、極めて多くのテストのモチベーション (動機付け) と検証のニーズを提供します。プロジェクトの個々の要件管理プロセスは、テスト管理のプロセスに大きな影響を及ぼす可能性があります。この関係をリレー競走に例えると、第 1 走者が要件管理で、渡されたバトンを受け取る次の走者がテスト管理です。
(中略)
「変更管理」は、ソフトウェア開発のすべての部分に影響しますが、追跡される変更のなかでテスト作業に最も関連が深いものは「欠陥」です。欠陥はしばしばテスト・チームと開発チームの間の主な意思疎通経路の役割を果たします。また、欠陥から引き出される集計とメトリックスは、多くの場合、品質の指標としても使用されます。
(中略)
テストにはどのビルドをいつテストするかの追跡が不可欠であるため、「構成管理」はテスト管理にとって重要です。構成管理では、ビルドに加えて、テスト管理がテストの実行のために追跡する環境も管理します。
(後略)

テストが変更管理に関係するのは、バグという変更要求が正しく実装されたか検証するプロセスとして必要だから。
テストが構成管理に関係するのは、どのバージョン、どのビルド番号のモジュールでテストしたのか、という観点が必要だから。

テストが要件管理と絡むのは、要件がテストの目的そのものだから。
テストにはV&Vという考え方がある。

Verification(検証)は、正しいプロセスで、仕様通りに動いているか、テストする。
Verificationは普通、コンポーネントとして単体テストや結合テストで行う。

Validation(妥当性)は、製品が意図された要求を達成しているか、テストする。
Validationは普通、システムテストや受入テストで行う。

要件管理が必要なのは、Validationのテストにあると言っていい。
システムに単にバグがなければ、品質がよいわけではない。
製品として魅力的でなければ、システムの価値は下がる。

要件を意識したら、テストの目的が明確になり、テストケースもその観点で詳細化されるだろう。
要件は受入テストのために存在するのだ。

せっかく苦労してシステムを作ったのに、次から次へと改善要望がやって来る場合、製品としてまだ成長途中か、あるいは、ユーザの欲求不満があるのかもしれない。
つまり、要件をきちんと管理できていなかったのが原因の一つなのかもしれない。

もう一つのテスト管理ツールRTH

TestLinkに似たもう一つのオープンソースのテスト管理ツールRTHを見つけたのでメモ。

RTH - Requirements and Testing Hub | Get RTH - Requirements and Testing Hub at SourceForge.net

Feature list ? RTH Blog

RTH Demo / Live System ? RTH Blog

RTH - Requirements and Testing Hub

デモサイトでいくつかの画面を触ってみた。
TestLinkよりも機能は少なく、デザインもシンプル。
しかし、テスト管理だけでなく要件管理もデフォルトで付属しているのが目を引いた。

テスト管理ツールもBTSぐらい普及して欲しいと思う。

TestLink・BTS・SVN・Hudsonの関連構造

TestLinkのポテンシャルについて考えたことをメモ。

【元ネタ】
要件とテストを関連付ける「テスト管理ツール」---目次 - 要件とテストを関連付ける「テスト管理ツール」：ITpro

第1回 テスト管理ツール：表計算ソフトの限界超える - 要件とテストを関連付ける「テスト管理ツール」：ITpro

第2回 テスト管理ツール：要件とのひも付けがカギ - 要件とテストを関連付ける「テスト管理ツール」：ITpro

第3回 テスト管理ツール：管理者支援型か開発者支援型か - 要件とテストを関連付ける「テスト管理ツール」：ITpro

第4回 テスト管理ツール：導入時の二つの課題 - 要件とテストを関連付ける「テスト管理ツール」：ITpro

【1】TestLinkを使う人達は主に、発注側や品質保証部門。
TestLinkを使う対象は、結合テスト以降、特に受入テストで使う。

TestLinkはテストの計画・記録・集計の為にある。
テストの自動化に直接役立つわけではない。
TestLinkは、テストケースそのものがプロジェクトの資産になる状況、つまり、結合テスト以降、特に受入テストで大きな威力を発揮する。

だから、TestLinkを使う状況は、発注側が受託したシステムの受入テストだったり、品質保証部門が開発部隊が作ったパッケージ製品の受入テストだったりする。

上記のようなTestLinkの特徴を上手に用いれば、XPのプラクティスであるユーザテストで使って、効率をあげることができる。

【2】TestLinkの要件カバレッジ機能を要件管理に使う。

Software Testing - Columns: テストカバレッジによれば、「仕様書の要件をどれだけテストしたか、という指標は、仕様カバレッジや要件カバレッジと呼ばれます。」

TestLinkの要件解析画面は、要件から紐付けたれたテストケース一覧を出力できる。
従って、この画面では要件カバレッジを見ることができる。

TestLinkCnvMacroを使うと、テストケースのキーワードに要件管理IDを紐付けることで、TestLinkのテスト結果画面で、キーワード別のテストの状態を集計してくれる。
従って、この画面ではテストカバレッジ、つまり、要件が何％までテストで検証されたか、を見ることができる。

たったこれだけの単純な機能だが、凄いポテンシャルを感じている。
その理由は、下記のようなトレーサビリティを実現できるからだ。

TestLink,BTS,SVN,Hudsonの関連構造

View more presentations from akipii .

現在、BTSチケット・SVNリビジョン・Hudsonビルド番号は、各々のツールで相互リンクが実現されている。
つまり、BTSチケットからビルドモジュール、あるいは逆にビルドモジュールからBTSチケットへ追跡できる。
従って、「このバージョンのモジュールに、あのバグ修正は反映されているか？」という疑問に回答できるインフラが既にある。

更にTestLinkのテストケースを経由して、要件まで遡れれば、「このバージョンのモジュールで実現された要件は何か？」を探すことができる。
あるいは、「ユーザの要望で仕様変更に対応する場合、要件に紐づくテストケースや機能、チケットから、影響範囲は大体これぐらいになる」という作業も機械的にできる。

しかし、TestLinkの要件管理機能は1階層のCSV形式でしか登録できない。
本来は、要件とBTSチケットを相互リンクさせたり、要件と機能のトレーサビリティマトリクスを表示したり、テストケースから紐付けられた要件の一覧(つまりトレーサビリティツリーみたいなもの)を表示したい。

市販の要件管理ツールやテスト管理ツールは多々あるが、ツール同士の関連がない。
現場で欲しいのは、プロジェクト全体の成果物を相互リンクしてトレーサビリティを実現してくれるプロジェクト管理サーバーなのだ。

TestLinkはPHPでオープンソースで作られているから、誰でも手を加えることができる。
誰か大幅に改造してくれないだろうか？

PICTで出力したテストケースをTestLinkへ取り込む

組み合わせテストケース自動生成ツールPICTを使って、TestLinkにテストケースを取り込めたのでメモ。

本当は、garyoさんやshimauchiさんが行ったallpair.exeを使おうとしたが、PICTの方が多機能。
PICTでは、制約条件を考慮できるし、以前生成した組合せテスト結果を再利用して他の組合せを追加できる機能もあるから。

AllPair法で作成したテストケースをTestLinkにテストケースとして読み込むツールallpairs2testcase.rb - Rubyの魔神 - はてな？Rubyグループ

TestLinkメモ(2) - 科学と非科学の迷宮

TestLinkメモ - 科学と非科学の迷宮

【元ネタ】
オールペア法テストケース作成ツール（PICT）と TestLink の連携 - hokorobiの日記

組み合わせテストをオールペア法でスピーディに！：第2回　PICTの基本的な使い方｜gihyo.jp … 技術評論社

pict : tech.kayac.com - KAYAC engineers' blog

TestLinkCnvMacro - TestLinkTools - SourceForge.JP

【手順】
1. PICTのインプットファイルを作る。

参考：組み合わせテストをオールペア法でスピーディに！：第2回　PICTの基本的な使い方｜gihyo.jp … 技術評論社

例：input.txt
OS種別: Windows Vista | Windows XP | Windows 2000, Linux, Mac OS X
HD容量: 250GB, 500GB, 750GB
HDインターフェース: USB2.0, IEEE1394, eSATA

2.PICTで生成する。
pict input.txt > output.txt

例：output.txt
OS種別 HD容量 HDインターフェース
Linux 750GB USB2.0
Mac OS X 250GB eSATA
Windows Vista 500GB USB2.0
Mac OS X 750GB IEEE1394
Windows XP 250GB IEEE1394
Linux 500GB eSATA
Mac OS X 250GB USB2.0
Windows 2000 750GB eSATA
Linux 250GB IEEE1394
Mac OS X 500GB IEEE1394

3.TestLinkCnvMacroのSuiteDTへ上記の組合せを貼り付ける。
　期待値、テストスイート等も記載して、テストケースらしく整える。
　最後に、XMLを出力する。

4.TestLinkへXMLをインポートすればOK。

PICTの結果さえできれば、TestLinkへの取り込みはすぐに終わる。

PICTを使う場面は、Webシステムならば、システムテストや受入テストで、本番用データのデータパターンと業務フローに従ってテストする時だ。
あるいは、組込み製品やパッケージ製品ならば、OSやハード、ブラウザ等の複数の環境で最後の受入テストをする時だろう。

本番リリース前のテストでは、ユーザに近いレベルのテストが多く、普通は単体テストで見つかるようなバグは無いのが普通。
だが、実際の本番データを使うと、予期していなかったデータが原因でシステムが正常動作しない時はままある。

そんな時、PICTを使って、データパターンを機械的に生成できるのは工数削減に役立つ。
と言うのも、本番リリース前のテストでは、テストデータを用意して、どのテストケースでどのテストデータを使うか、というテスト設計に一番工数がかかるからだ。
もはや仕様が分からなければ、テストケースもテストデータも作れない。

PICTやTestLink、TestLinkCnvMacroを使い始めて分かった事がある。
それは、テスト工程では、仕様がはっきりと分かっていて、仕様の直交性が保障されていなければ、テストしても工数の無駄ということ。

直交表やAllPair法を使うには、テストするパラメータとそのデシジョンテーブルが必要だ。
そのためには、デシジョンテーブルと同値であるシステムの状態遷移図が作れていなければならない。
しかし、設計が曖昧だと、システムの状態遷移図すら設計者が詰め切れていない場合もある。

ツールによって、単純作業は効率化できる。
しかし、ツールで使う入力データ、仕様というマスタデータの質が悪ければ、PICTやTestLinkをいくら使いこなしても無意味なのだ。

要求管理プロセスのポイントは要件カバレッジとトレーサビリティマトリクス

要求管理プロセスについて良い記事があったのでメモ。

【元ネタ1】
＠IT：みんなが悩む要求管理（8） 最終回 要求管理ツールの賢い使い方

　まず、要求をWordのような文書ソフトで管理すると、要求の属性や履歴の管理が難しく、要求間でトレーサビリティが設定できないという欠点があります。
一方、要求を表計算ソフトで管理すると、要求を文脈の中で表現することが難しく、要求間でトレーサビリティを設定するのが難しいという欠点があります。
いっそのこと、要求を管理するためにデータベースをカスタマイズしたツールを使うケースがありますが、この場合でも、要求を文脈の中で表現することが難しく、ツールの保守にコストがかかります。
ある程度、大規模なシステム開発の場合は、市販の要求管理ツールを用いた方がメリットの出るケースが多いと思います。

IBM Rational RequisiteProを使った要求管理の事例。
興味深いのは、トレーサビリティマトリクス（追跡可能性マトリクス）だ。
これは、清水吉男さんが提唱する派生開発プロセスXDDPにもあるTM(トレーサビリティマトリクス)と同じだ。

TMは、上位要件を行、下位要件を列で表示したマトリクス。
上位要件に下位要件が紐づいている場合、マトリクスのセルに印が付く。
このセルがトレーサビリティを示す。

つまり、TMで印を付ける作業が、上位要件に紐づく下位要件の過不足が無いかを確認する作業に相当する。
これこそが要件カバレッジだ。
この要件カバレッジ機能を意識して設計すれば、要件を詳細化していくプロセスで、要件漏れや設計漏れをなくして、設計プロセスの品質を高めることができる。

【元ネタ2】
テスト管理のベスト・プラクティス　要件ベースのテストを使用する

要件管理では、要件漏れ・テスト漏れがないかという要件カバレッジ、つまりMECEの観点が一番大事だ。
要件カバレッジがあるからこそ、要件からソースコードやテストケースまでのトレーサビリティが実現される。
逆に、バグが発生した場合、バグの影響範囲を要件カバレッジによって即座に見極められるので、ブロッキングバグの修正・検証工数も最終的には計算できる。

特に、後者の機能は、要件カバレッジを利用して、バグから本来の要件に遡って、バグが発生した要件に関係する要件から修正対象ソースへ追跡できるという点で重要だ。
この手法は仕様変更にも使えるからだ。

そして、要件カバレッジの機能は、手作業ではなく、ツールでサポートすべきだ。
理由は、要件が数百、テストケースが数千もある場合、もはや手作業でカバーできないから。
TestLinkの要件管理機能は現在は不十分でも、すごく潜在性を感じる理由でもある。

【元ネタ3】
＠IT：みんなが悩む要求管理（7） 第7回 要求管理と変更依頼管理の違いを理解しよう

変更依頼管理プロセスと要求管理プロセスの関係の図が素晴らしい。
変更依頼管理や要求管理は最終的には、ITILの変更管理に落ち着く。

大規模プロジェクトほど、ユーザからやって来る膨大な改善要望や障害修正の要求は、一旦溜め込んで、すぐに判断しない。
要件定義や設計チームの代表者が集まった変更審査委員会（CCB：Change Control Board）が、一旦貯めた要求リストから、次バージョンで実現すべき要件を抽出し、優先順位付けしていく。
開発者は優先順位付けされた要件リストに従って開発し、テスト担当者は検証していく。

つまり、上記の計画プロセスと実装・検証プロセスは、ITILの変更管理とリリース管理にピッタリ当てはまる。
要求管理や変更依頼管理は、ITILの変更管理プロセスできちんと追跡できるように管理すべきなのだ。

また、要求を一旦溜め込んで優先順位付けするプロセスは、Scrumのスプリント計画やXPのイテレーション計画に相当する。
すなわち、プロダクトバックログにまずはユーザの要求を溜め込んでおき、どのスプリントで実装するかは保留にしておく。
スプリント計画を立てる時に、プロダクトバックログからスプリントバックログへ実現すべき要求を移す。
これが本来のマネジメント、あるいは要求管理になる。

そして、このプロセスはツールで実現されるべきだ。
大量の要求の一覧を優先順位付けして、どのバージョンでリリースされたか、追跡できるようにするには、Excelで手作業で行うのはもはや難しい。
ツールのサポート無しでは作業漏れも発生しやすい。

このインフラは、おそらくチケット駆動開発で実装できる。
つまり、BTSと要件管理機能を組み合わせれば、上記のプロセスを実装できるだろう。

ツールで要求管理をサポートする。
要求管理を含むチケット駆動開発こそが、仕様変更に強いアジャイル開発を更にパワーアップしてくれるはずだ。

ソフトウェア開発の諸問題はソフトウェアで解決する

「要件とソースとテストを関連付けて管理する開発保守環境構築をめざしてBy Suzuki 」というスライドを偶然見つけた。
どうやら2005年頃の発表資料らしい。

要件とソースとテストを関連付けて管理する開発保守環境構築をめざしてBy Suzuki

View more presentations from ikuo5710.

課題と今後の目標
* ソースと要件の結びつけはできる
* でも、テストケースとソース、 テストケースと要件の結びつけが できていない
* テストケースのバージョン管理って どうやればいいんだろう？
* ツールは？
* エクセルはもう使いたくない

この回答は僕は持っている。
TiDD＋TestLinkがその答えになる、と。

下記の記事を偶然見つけた。

プロジェクト管理は専用ツールを使うのが鉄則 － TechTargetジャパン

(前略)
プロジェクトマネジャーがプロジェクト管理専用のツールを使わない場合、それは彼らがしかるべき教育と訓練を受けていない証拠なのだ。
　WordやExcelを使ってプロジェクト管理を行うと、間違いなくビジネス全体に悪影響がある。例えば、リソースの利用可能量やプロジェクトの状態、プロジェクトポートフォリオ全体の健全性が見えにくくなってしまう。プロジェクトの観点から見ると、プロジェクト管理ツールを使わないことによる大きな弊害は、きちんとしたスケジュールを持たず、個別のタスクを管理するだけになってしまうことだ。プロジェクトの規模が大きい場合や、リソースに制約がある場合、期限が厳しい場合、作業の依存関係が多い場合には、これではリスキーだ。
(後略)

以前のソフトウェア開発では、期間も長く、資金も潤沢にあった。
そして何よりも、コンピュータ資源のコストが高く、誰もが湯水のように使える代物ではなかった。
だから、ツール無しで開発するのが普通だった。
プログラミングも机上デバッグが普通だったし、プロジェクト管理もマネージャ個人の能力に依存していた。

しかし、現在のソフトウェア開発は短納期で低コストで開発せねばならない。
従来と全く異なる条件は、コンピュータ資源のコスト、プログラミングのコストが劇的に安いことだ。
Webサーバーは素人でも1万円以下で構築できるし、Railsのような優れたWebフレームワークのおかげで、技術力さえあれば簡単にWebアプリを作れる。

現在のソフトウェア開発がSubversionやGit、Mercurialのようなバージョン管理無しで開発できないように、プロジェクト管理もRedmineやTracのようなツール無しではマネジメントの品質も落ちる。
更に、テスト工程におけるテスト計画・実施・集計のようなテスト管理も、TestLinkのようなツール無しでは、プロセスの品質を担保できない。

これらのツールには、マネジメントのベストプラクティスが含まれている。
ツールを使いこなせば自然に誰でもマネージャとして意思決定できる。

昨今のわずか20人月のソフトウェア開発でも、LOCは数万行を軽く超えて、テストケースは数千を超える。
これだけ複雑になったソフトウェア開発のプロジェクト管理を、Excel上でチマチマと手作業で管理するのはもはや現実的ではない。

巷にはソフトウェア開発のプロジェクト管理、テスト管理、品質管理、ソフトウェア工学に関する本が溢れている。
でもそれらは殆どが抽象的過ぎて、実際の現場で運用するにはハードルが高い。
特にソフトウェア工学に関する知識は、とても勉強になるが、実際の現場では使いづらい。
ソフトウェア信頼性モデル、要件カバレッジ、テストカバレッジ、障害管理などいずれの概念も、ツール無しでは実現できない。

ソフトウェア開発の諸問題は、過去の経験から得られたノウハウを専用のツールの機能へ実装して、そのツールで解決していくしか方法がないのではないか？

ツールでプロセスを改善する。
ソフトウェアでソフトウェア開発の諸問題を解決していく。

アジャイル開発のFAQ

アジャイル開発のFAQについてメモ。

【1】アジャイル開発のような繰り返し型開発は、作業やリソースの重複が多くて生産性が低いのではないですか？

【回答】最初のイテレーションは試行錯誤しがちですが、イテレーションをこなすたびに慣れていき、生産性は上がっています。

特にSW開発は常に新技術を取り入れているので、開発者の学習曲線を考慮する必要があります。
アジャイル開発では、開発者の成長を意識的に支援するプラクティスが含まれています。

例えば、イテレーション毎にふりかえりMTを開いてプロセス改善する意識を開発者に植え付けますし、ペアプログラミングで開発者と技術や設計思想を共有するプラクティスもあります。

特に、プロジェクトファシリテーションでは、開発者の成長を促進するプラクティスが多々あるので参考にしてみてはいかがでしょうか？

【2】開発を繰り返すから、コストが高いのでは？

【回答】最初のイテレーションはコストは高いですが、トータルのコストはWF型開発よりも減るはずです。

1，2回目のイテレーションでは、実現できる機能も少なく、開発者も開発よりもリリース作業に手間取って、試行錯誤するので、コストはかかります。
しかし、イテレーションをこなすたびに、リリースのリハーサルを何度もしているので、リリース作業よりも開発に専念でき、開発者もシステム設計や業務に慣れていくので、後工程ほど生産性も上がります。

しかし、WF型開発の場合、仕様変更やリスク対処などの手戻り作業に工数を取られて、後工程ほど本来の作業に混乱が生じがちです。
そして、最後の一発リリース作業でいろんな問題が発見されると大きなコストがかかります。
更には、リリース後の不具合修正や改善要望が膨大に来た場合、更にコストは増えます。

アジャイル開発では、イテレーション単位に開発するため、顧客のフィードバックや障害修正を次のイテレーションで解決する方向へ進めるので、リスクを早期に対処する余地があるのです。

【3】アジャイル開発のような短期間の繰り返し型開発は、何でも早くリリースするから、品質が悪いのではないですか？

【回答】アジャイル開発と言っても、品質管理に奇策はありません。
InfoQ: James Shore氏「アジャイルの衰退と凋落」のように、戦略のない単なる繰り返し型開発は、本来のアジャイル開発ではないのです。
リリースする時点で品質を確保できてなければ、リリース後に山のようなクレームがやってきます。

また、アジャイル開発でもXPは、テスト駆動開発や継続的インテグレーションのように、コードラインの品質管理について、従来の開発にはない観点をもたらしています。

【注意】
アジャイル開発での品質管理は、上記の回答では不十分で、まだ弱点があるように思う。
従来の開発スタイルに比べて、その優位性を明示できていないように思う。
そこに、RedmineやTestLink、Mercurialなどのツールでアジャイル開発を補強できる余地がある。

要件定義の疑問

要件定義や設計という上流工程について以前から感じていた疑問をメモ。

【1】以前から、オブジェクト指向モデリングやらデータモデリングやらビジネスモデリング等の本を漁ってきたけれど、どれもあまり役立たない気がしている。
何故だろう？

モデリングや要求分析が必要になる場面は、新規顧客の受託開発で、顧客からシステムの要件をヒヤリングしたり、その後の仕様確認の時だ。
つまり、設計しながら要件を詰めていく作業で、モデリング技術が必要になる。

しかし、OOAもDOAもあまりピンと来ない。
RUPは確かに勉強になるが、膨大すぎて現場の実践に向かない。

UMLを使ってモデリングするのは確かに思考の整理に役立つが、それはむしろ実装に近いフェーズだ。
概念モデルのクラス図を書いたとしても、ユースケース記述で業務仕様を書いたとしても、何か物足りない。

むしろ、OOAよりもDOAの方が実践的だと感じる時がある。
テーブル設計をしながら、実際に実装している感覚だ。
特に、RailsやSeasarのように優れたフレームワークがあるおかげで、DBの箱さえ決まれば、RubyやJavaで簡単に作ることができる。

でも、DOAのデータモデルパターンは洋書しかなく和書が存在しない。
良書は、渡辺さんの本や「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」などごく一部だけだ。

OOAの本は抽象的過ぎる。
確かにクラス図を描くスキルは上がるが、実装モデルに程遠い。

OOAは最終的にはMDAがやりたいだけなのだろうと思う。
モデルさえ書ければ、プログラムを自動生成してくれるというMDAの発想。
その発想は理想的過ぎるように思う。

顧客の業務のフローやエンティティを導出するのにOOAは非常に役立つが、むしろ、システム設計ではクラス図よりも状態遷移図の方が重要だという気がしている。
我々SEがシステムエンジニアであるという意味は、業務を知ることよりも、業務をシステムへマッピングすることがSEの役割だからだ。

システム化する上で最も重要なポイントは、業務をシステムとみなした場合、システムの状態を導き出し、その遷移を全て記述することだ。
システムの状態とは、そのシステムで最も重要なエンティティの状態を表し、DBに落としたらフラグとして現れる。
そのフラグのCRUDを表した物がシステムの状態遷移図に当たる。

システムの状態遷移図を緻密に描くほど、システムの整合性を考えやすく、そこから要件漏れや設計漏れに気づく。
状態遷移図があれば、それからテストケースを作ることができる。
そして、普通は、システムが大きいほど状態遷移図は複雑であり、状態爆発を起こす。
テストケースは膨大になり、どこまでテストすれば品質を担保できるか、SEとしての技量を問われる。

【2】要件定義でいつも疑問な点は、システム化する技術力よりも顧客へのヒヤリング能力と言う人間関係構築能力の方を重要視されることだ。
昨今の人間系、特にファシリテーションもその一環と捉えることもできるだろう。

しかし、技術力が軽視されていないか？
ヒヤリング能力が重要と言っても、顧客の業務をロジカルに整理して、要件の一覧をMECEで導き出す技術も必要なはずだ。
ヒヤリング能力、ファシリテーションだけでは、要件定義を解決できない。

その点で、清水吉男さんが提唱する派生開発プロセスXDDPに興味はある。
XDDPでは、要求を発見することよりも、要求を表現することに力点を置く。
要求仕様と機能仕様を厳密に区別し、変更理由も書きながら、要求仕様を機能仕様へ階層化しながら詳細化していく手法。
この手法ならば、機能仕様へ詳細化する時に、仕様に漏れがないか、重複がないか、自然に考えれるようになる。

また、XDDPで面白いと思ったのは、要求には機能要件だけでなく、保守性や信頼性、性能要件のような非機能要件も含めるという点だ。

例えば、保守性の要件では、関数の複雑度は15以下とする、など。
信頼性や性能要件でも、ボタン押下後のレスポンスは1秒以内とする、など。

これらの非機能要件は実際のSW開発では設計漏れしがちなのだが、漏れなく仕様化できるプロセスがXDDPにはある。

普通のSW開発では、顧客はSEでないからシステム化の技術に疎く、顧客の言うがままに作ってしまうと、必ず要件漏れが発生する。
要件定義では、要件を漏れなく全てを洗い出すこと(MECE)が重要だと最近は思う。

【3】アジャイル開発は、要件定義に関して一種の諦めがあるように思う。
アジャイル開発における要件定義の特徴は、仮説検証スタイルであることだ。
つまり、短期間のイテレーションを繰り返して開発しながら、顧客のストーリーを少しずつシステム化しては、顧客に確認してもらい、フィードバックを受けながら、更に修正していく。

この繰り返し型開発スタイルは、全ての要件は最初に決められないという仮定の下で、安定した重要な要件から少しずつ開発していくという発想に基づく。
WF型開発のように、最初に全ての要件を決めていくのは現実のSW開発では無理で、すごくリスクがあるという仮定に基づいている気がする。

また、オンサイト顧客というXPのプラクティスでは、顧客を開発チームの近くに置き、常に要件を確認できる状態にする。
実際の受託開発では、顧客を開発チームの内部に配置できないケースも多い。
その場合、顧客と関係が近く業務が詳しい上級SEが顧客の代わりになるという顧客プロキシという手法もある。

また、Scrumのプロダクトバックログというアイデアもある。
顧客の要求を一旦バックログと言う貯蔵庫に貯めて、リリース計画から、そのスプリントで実現する要求をプロダクトバックログからスプリントバックログへ移す。
つまり、要求をリリース計画や優先度に基づいてふるいにかけるというマネジメントが含まれている。

アジャイル開発では、要件定義や開発スタイルに関しても、従来のWF型開発では明示されない解決方法を提示しているように思う。
まさに「1回のリリースは100回のレビューに勝る(プログラマの思索)」。

【4】要件定義や設計プロセスで重要だと思う点は、要件カバレッジと要件の追跡だ。

顧客が提示した要件は、漏れなく全て、仕様書やプログラム、テストケースに反映されているか？
顧客が提示した要件が、どの設計書に仕様化されて、どのプログラムに実装されて、どこでテストされて、どのバージョンのモジュールに反映したのか？

現場では、上記の作業をプロジェクトリーダーやSEが手作業で確認し合っているようなものだ。
だからすごく非効率で生産性が低く、結果的にシステムの品質も低い。

開発プロセスが整っていないプロジェクトでは、要件や仕様にIDが振られていない時が多い。
すると、今どれだけの要件がテストで検証されたか、どこまで要件を網羅しているか、集計できない。

「要求は数えられたら品質が上がる(プログラマの思索)」のだ。

要件にIDが振られて初めて、要件の追跡が可能になる。
現状のチケット駆動開発では、「BTSチケット→SVNリビジョン→Hudsonのビルド番号」までは相互のトレーサビリティを実現できている。
そして、TestLinkでは「要件→テストケース」の相互のトレーサビリティが実現できている。
だから、BTSとTestLinkの間のトレーサビリティを可能になれば、要件やテストケースがチケット経由でビルドモジュールのビルド番号まで追跡可能になる。

このアイデアを膨らませたものが「プロジェクト管理サーバー」。
そのアイデアは「アジャイル開発の弱点をプロジェクト管理サーバーが助ける: プログラマの思索」に書いた。

つまり、「プロジェクト管理サーバー」の最終ゴールの一つは、要件カバレッジと要件の追跡をリアルタイムに集計して、管理作業を減らし、本来の開発作業に専念できるようにすることだと思っている。

ブロッキングバグの事例

TestLinkのテスト実行画面には「成功」「失敗」の他に「ブロック」がある。(ソフトウェアテスト標準用語集 日本語版Ver 1.3)
普通は、失敗時に、失敗したテストケースに依存するテストケースをブロックにして、テスト保留にする。

ここで、ブロッキングバグとは、失敗したテストケースの機能のバグのうち、リリースを妨げるような重大なバグを指す。
ブロッカーバグとも言われるらしい。
更に、ブロックしたテストケースの機能は、みなしバグと呼ばれる。

Tracのチケットでは、緊急性が最も高い優先度が「blocker」になっているが、ブロッキングバグはそれに当たると思う。

このブロッキングバグの事例を見つけたのでメモ。

【事例1】
ある会社の新人チームが開発後テスト中にブロッキングバグに遭遇した事例が書かれている。
緊迫した内容がリアルで、とても素晴らしい。

コラム[直し壊しのテストフェーズ]‐株式会社アーツテック[ARTSTECH]

特に、結合テストやシステムテストでは、バグ修正と同時にテストデータの準備や本番環境の構築作業を行わなければならない。
この時に、どの作業を優先して行うか、意思決定が迫られる。

普通は、ブロッキングバグを最優先に直すのが先だ。
理由は、ブロッキングバグが直らないと、未検証の機能はみなしバグの状態になってしまい、テストしても無意味だからだ。
ブロッキングバグはまさにリリース不能にさせるバグ、プロジェクトの動き全体を文字通りブロックしてしまう危険なバグなのだ。

【事例2】
Mozillaが安定していなかった頃のQAメールのやり取り。

もじら組フォーラム [One Topic All View / Re[7]: Mozilla 1.3 for Mac OS X でメールフォルダ名が文字化け / Page: 0]

(前略)
ただですらユーザの少ないMac版のしかも日本語処理のバグなんで声を出さないとなかなか注目を浴びないと思います。
Bugzilla-jpでバグを立てると国内の有志が協力してくれるとしょう。
どちらも内容的にはブロッキングバグになってしかるべきものと思います。
(後略)

もじら組フォーラム [One Topic All View / Re[1]: Mozilla 1.4 リソースリーク? / Page: 0]

(前略)
1.4は1.0.xに変わる安定系という役割なのに、何を焦っているのか、ブロッカーバグをつぶさずリリースしたことが、今回の失態につながっている。
MozillaはともかくNetscape 7.1は大問題だと思う。
これさえなければ、Netscape復活といえる出来なだけに誠に残念。
ショボイOSにも問題はあるが、早急に修正版を出して欲しい。
(後略)

ブロッキングバグを無視してリリースしてしまった為、ユーザから製品に対する信頼を落とした事例として非常に耳が痛い。
ブロッキングバグを残したままリリースした場合、ブロックした機能は未検証のため、品質に疑問符が付いたままになる。

結局、ユーザにブロックしたテストケースを再テストさせているようなものだ。
つまり、みなしバグをユーザがテストして、はっきりとバグと判明させたようなもの。
プロの技術者として恥ずかしいだろう。

テスト管理には、プログラミングとは違った特有の技術があるように思う。

TestLinkの要件管理機能

TestLinkの要件管理機能についてメモ。

【元ネタ】
要件のテスト - watawata日記

TestLinkの可能性: プログラマの思索

要求管理(要件管理)ツール RaQuest

要求管理ツールRaQuest・要求項目の作成

要求管理ツールRaQuest・ツリーと一覧を駆使した要求項目の効率的な管理

要求管理ツールRaQuest・要求の追跡

TestLinkの機能とV字モデルの関係 (Testlinkjp-users) - TestLink日本語化 - SourceForge.JP

テスト管理ツールTestLinkには不十分だが、要件管理機能が付いている。
TestLinkCnvMacroを使えば、TestLink要件をTestLinkキーワードを経由して、TestLinkテストケースとN対Nの関係に持ち込むことができる。

この紐づけによって、要件カバレッジが可能になり、キーワード別にテスト結果を集計できるため、要件が今どこまでテストで検証できたか、を表示することができる。

つまり、TestLinkの要件管理機能を使って、要件定義や設計工程で要件カバレッジを取りながらテスト設計すれば、W字モデルのような開発が可能になる。
すなわち、上流工程でテスト設計の作業ができるので、設計工程の成果物を検証する作業も可能になるだろう。
テスト駆動開発を製造工程だけでなく設計工程など上流工程へ持ち込めるだろう。
特に、要件カバレッジはテストケースの品質に大きな威力を発揮する。

この場合、TestLink要件を顧客の本来の要件と対応させた時、その要件は受入テストのテストケースに対応付けられる。
すると、単体・結合・システムテストのテストケースに相当するTestLink要件は一体何に当たるのか？

そのTestLink要件は、単体・結合・システムテストの上流工程に当たる製造・内部設計・外部設計の仕様に当たるだろう。
各工程の仕様を網羅する観点で、テストケースを作っていけばいい。

すると、各工程の仕様や要件はどのように関連付けられるか？
それは、要件から外部・内部・詳細設計の仕様までの関係、ツリー上に詳細化されていくと考えてよいだろう。
製造工程における仕様は遡れば、要件まで辿りつく。

つまり、要件はツリー構造であるべきだ。
すなわち、TestLink要件は現状のCSV形式の1階層の構造ではなく、TestLinkテストスイートのように階層構造を持つべきだ。
そうすれば、顧客の要件から製造工程の仕様まで追跡可能になる。

更には、TestLink要件の各階層が単体・結合・システム・受入テストのテストケースと対応づけられればよい。
そうすれば、単体～受入テストの各工程で仕様・要件カバレッジが可能になる。

TestLinkの要件管理機能は正直使い勝手が悪く、発展途上の機能。
TestLinkの要件管理機能のあるべき姿は、EnterpriseArchitectの要求管理ツールRaQuestのように、要件の状態管理や履歴管理、要件の追跡機能が実現されることだろう。
そうなれば、要件カバレッジ機能がより簡単に使えて、テストケースの品質アップに大きく貢献するだろう。

オープンソースのテスト管理ツールTestLinkには大きなポテンシャルがあると思う。

レビューをTestLink＋Redmineで管理できないか？

SQIP2009の森崎さんの講演「レビューの壁を破る」を聞きながら、考えたことをメモ。
＃後でまとめる。

SW開発の品質UP、プロセス改善を目指すと、最終的には設計工程でどれだけバグを潰せるか、という点に落ち着く。
上流工程の品質UPが鍵を握る。
そのためには、設計レビューが必要で、きちんとすべきだね、という話にいつも行き着く。

しかし、設計レビューそのものの品質が低いように思う。
僕がいつもレビューで問題と思う点は、二つある。

一つは、レビューのプロセスがあいまいできちんと定義されていないこと。
例えば、レビューする際の観点がレビューアによってまちまちだったりする。
レビューのチェックリストがあるにはあるのだが、形骸化しており、機能していない。

もう一つは、レビューで指摘を受けた内容を反映する作業のチェックがおろそかであること。
例えば、レビュー後修正の品質チェックが個人任せで、他人のチェックができていない。
その原因は、レビューアの人数不足でレビューそのものが遅れがち、などがある。

議論を聞きながら思ったことは、「レビューを設計工程のテスト」を考えられないだろうか？
設計書をレビューのチェックリストに基づいて、ウォークスルー形式で検証しているのではないか？
となると、レビュー後修正は、設計のバグ修正に当たるのではないか？

つまり、レビューを設計のテストと考えると、下記の相関関係が成り立つのではないか？

レビューのチェックリスト＝TestLinkのテストケース
レビュー結果＝TestLinkのテスト結果
レビューで指摘を受けた内容を修正＝Redmjneでバグ修正

すると、TestLinkのビルド、ブロックはレビュー工程でどのように対応するのか？
まだ分からない。

設計工程やレビューでいつも腑に落ちないのは、Excelばかり使っていて、作業状態の把握や集計作業が大変なこと。
チケット駆動開発にレビュープロセスをのせることができれば、プロセスをBTSのワークフローで管理できるし、レビューの漏れがなくなるのではないか？

RedmineやTestLink、Mercurialなど各種ツールを使いこなすと、下流工程のプロセスはツールで制御できるようになる。
しかし、上流工程、つまり要件定義や設計をチケット駆動開発が制御するのは不十分。

色々考えてみたい。

TestLinkの運用例part2

allpair法をTestLinkに使う方法が書かれた記事があったのでメモ。

【元ネタ】
TestLinkメモ - 科学と非科学の迷宮

AllPair法で作成したテストケースをTestLinkにテストケースとして読み込むツールallpairs2testcase.rb - Rubyの魔神 - はてな？Rubyグループ

allpair法は、組み合わせテストのテストケース作成技法の一つで、同じ値のペアが最低1回現れるように組み合わせてテストケースを作成する方法。
直交表に比べると、テストケース数を少なくできる。

実際のテストケース作成時は、複数の入力項目の組合せテストが非常に多い。
例えば、組込製品やパッケージ製品ならば、ドライバやOSのバージョンを組み合わせたテストケースを作っているだろう。
業務システムならば、業務のパターンや状態を組み合わせてテストケースを作りこんでいるだろう。

実際の現場では、直交表からテストケースを作ると、ケース数が爆発してしまい、限られた工数ではテストできない時が多い。
その時に、直交表よりもallpair法を使えば、少ないテストケースでたくさんのバグを見つけることができるはず。

TestLinkのテストケースへ出力する方法は、garyoさんが作ったRubyスクリプトを使うのが一番よいだろう。
僕は実際に使ったことがない(使いこなせなかった)が、上記の方は実際に試されているので非常に参考になる。

TestLinkでテスト工程をマネジメントする場合、インプットのデータであるテストケースの品質が一番重要だ。
テストケースの品質が悪く、テストケースの粒度にばらつきがあったり、テストケースそのものに間違いや仕様漏れがあると、TestLinkを使う利点が半減する。
実際、TestLinkの要件カバレッジを使ってみると、テストケースに紐づかない要件がよくあるので、要件漏れが頻繁に発生している時が多い。
すると、テストしていない要件、機能があるため、そこから潜在バグになる危険がある。

結合テスト以降のテスト仕様書は、Excel上で仕様書を見ながらテストケースを増幅して作る時が多く、非常に工数がかかる。

TestLinkを運用するようになって、テストケースはTestLinkのマスタデータなのだ、と思うようになった。
マスタデータが狂っていると、TestLinkでいくらテスト管理を頑張っても効果は半減する。
テスト仕様書は設計書を書いているのと同じレベルなのだ。
だから、テスト仕様書をきちんとレビューしてもらい、間違いや漏れをなくすのが大事だ。

TestLinkが運用しづらい原因の一つは、テストケースと言うマスタデータを作りこむのが大変だという点もあると思う。
テストケース作成技術は、プログラミング技術とは異なる別個の重要な技術なのだ。

TestLinkを運用して気付いたことpart10～テストの制約条件

TEF関西のNakaさんの話を聞いて考えたことをメモ。

【元ネタ】
ソフトウェアテスト標準用語集 日本語版Ver 1.3

普通のプロジェクトは結合テストで火を噴く。
理由は、結合テストで初めて、システムが稼動するのを顧客も開発者も見れるから。
そこで、初めて、要件漏れ、認識相違、仕様漏れに気付く。

でも、それだけの理由だけではないという指摘を受けた。

ソフトウェアテスト標準用語集 日本語版Ver 1.3には「プロダクトリスク」「プロジェクトリスク」の用語解説がある。

プロダクトリスクとは、「テスト対象に直接関係するリスク」。
プロジェクトリスクとは、「（テスト）プロジェクトの管理（マネジメント）と制御（コントロ－ル）に関係するリスク。例えば、スタッフの不足、厳しい締め切り、変更管理などがこれに当たる。」

実際のテスト、特に結合テスト、システムテスト、受入テストのようにプロジェクト後半になるにつれて、テスターやバグ修正担当者の不足、間近に迫る納期という工数不足、つまりプロジェクトリスクがすごく大きい。
テスト工程はプロジェクト後半のため、元々リソースが少ない。

だからといって、逆にテスターを増やしたとしても、ブロッキングバグが多発してみなしバグが増えれば、いくらテストしても無意味だ。

また、開発が遅れに遅れて、テスト期間がそもそも短い場合、リリースできる品質をテストで確かめることができず、全ての機能をテストできないままリリースせざるを得ないかもしれない。
その場合、リリース後にたくさんの苦情が開発チームに押し寄せる。

つまり、テストには制約条件が非常に多い。

まず、テスト計画を立てた時、与えられた期間と手持ちのスタッフ数から、実施できるテストケース数の上限という制約条件がある。
この上限を超えたテストケースを作った場合、スタッフを増やして徹夜させて納期に間に合わせるか、あるいは、納期を遅らせてテスト工数を確保するか、という選択を現場リーダーは決断せねばならない。
ここで、アジャイル開発を実践しているならば、スコープを削ることで品質と納期を確保する選択肢も取れるだろう。

でも、アジャイル開発であろうとも、残りの期間でテストしてリリース可能な品質を保証できる機能は、上記の上限から限られるのだ。

極端には、テスト計画を立てた時点で、そのプロジェクトは既に死んでいる場合もあるのだ。
つまり、テストケースが多すぎて工数を確保できず、プロジェクトリスクをどうやっても解決できないプロジェクトはありうる。

次に、テストの失敗率から、ブロックされるテストケースが増えすぎてテストできない状態になる上限がある。
つまり、ブロッキングバグがある上限を超えると、殆ど全てのテストケースがみなしバグとなってしまい、テスト不能になる状況が考えられる。

だから、バグを発見したら、どのバグを最優先で直すか、優先順位を付けてブロッキングバグの修正に最優先に対応する。
あるいは、結合テストでそもそもブロッキングバグが出ないように予防しておくべきだろう。

実際は、障害件数をあらかじめ予想しておき、障害修正工数や再テスト工数も予測しておけば、テスト実施のクリティカルパスが見える。
そこから、どのブロッキングバグを最優先で直して、次にどこのテストケースをテストするか、というふうに先を見通して手を打たねばならない。

上記のプロジェクトリスクを解決できずにリリースした場合、顧客からの膨大なクレームや不良品による返品などといったプロダクトリスクで跳ね返ってくる。

テスト工程のプロジェクト管理が上流工程のそれよりも難しいのは、上記のような制約条件に対するリスク管理が非常に難しいからだろう。

TestLinkでは、テストケースのカスタムフィールドに予定工数やテスト実施予定日を入力すれば、テスト計画の総予定工数をあらかじめ予測できる。
また、TestLinkのテストケースの情報を出力してTestLinkCnvMacroに取り込めば、Excelで解析することができる。

そこから、リスクを洗い出し、プロジェクトリスクやプロダクトリスクに分ける。
おそらく、プロジェクトリスクには、アジャイル開発のプロジェクト管理の基本であるスコープ・納期・コストで対応すればいいだろう。
プロダクトリスクには、優先順位付けして最優先で対応する戦略を取ればいいだろう。

テスト工程のプロジェクト管理には、上流工程とは異なる特有のマネジメント手法があるのだと思う。
色々考察してみたい。

チケット駆動開発が進むべき道

さかばさんのBlogにTiDD(チケット駆動開発)の分析が書かれているのでメモ。

【元ネタ】
必然から生まれたチケット駆動開発 - XP祭り関西2009 その３-: ソフトウェアさかば

TiDD：チケット駆動によるアジャイル開発法: ソフトウェアさかば

TiDD：チケット駆動開発: ソフトウェアさかば

[TiDD] チケット駆動開発とXPの共通点: ソフトウェアさかば

[TiDD]チケット駆動開発と見える化: ソフトウェアさかば

[TiDD] チケット駆動開発によるフロントローディング: ソフトウェアさかば

[TiDD] プラクティスから方法論へ: ソフトウェアさかば

TiDDとアジャイル開発に強い関連性があると色んな観点から分析されている。
TiDDはまだ定義すらない曖昧な概念であり、プロセスですらない。
今後進むべき方向は、方法論やベストプラクティス集を定義することだろう。

僕はTiDDを実践してみて、TiDDはアジャイル開発のベストプラクティス集みたいなものだと直感している。
それは丁度、オブジェクト指向のデザインパターンのようなもの。
目に見えないけれど誰もが理解できる抽象概念でありながら、実際のプログラミング言語で実装して試すことができる。

そして、方法論よりもベストプラクティス集の方が現場でははるかに役立つ。
オブジェクト指向の方法論はRUPだと思うが、あまりにも重過ぎる。
確かにその内容は勉強に値するし、なるほどと思う部分は多々あるけれど、実際の現場で試そうとするとあまりにもハードルが高い。

アジャイル開発もウォーターフォール型開発やRUPなどの重厚プロセスのアンチテーゼとして生まれたが、誰にでも使えるように抽象化するほど、現場で運用する時のギャップが大きくなる。
TiDDはBTSというツールに依存しすぎている、という批判を受けた時があったけれど、現場ですぐに実践できるなら、僕はそれでいいと思う。

実際のソフトウェア開発で、目の前にあった問題を解決しようとしたら、RedmineやTestLinkのようなツールが必要だっただけ。
むしろ、それらのツールが持つ機能が一つのベストプラクティスなのだ、と気付き、過去に読んだ本の専門用語が対応する経験を通じて、プロセス改善におけるツールの重要性を感じている。

アジャイル開発がこれだけ注目され、その有効性が理解できているのに実践できないのは、単に技術力がないだけなのだ、と直感している。
ソフトウェア開発の諸問題はTiDDのような技術力で全てカバーできるという確信を更に考察していきたい。

TestLinkを運用して気付いたことpart9～後追いテスト

TEF関西のNakaさんから「後追いテスト」というテストの用語を教えてもらったのでメモ。

【元ネタ】
ソフトウェアテスト標準用語集 日本語版Ver 1.3

まず、ソフトウェアテスト標準用語集 日本語版Ver 1.3には「リスク」「プロダクトリスク」「プロジェクトリスク」の用語解説がある。

テスト工程での「リスク」は「将来、否定的な結果を生む要素。通常、影響度と発生可能性として表現する。」という意味で定義されている。

プロダクトリスクとは、「テスト対象に直接関係するリスク」。
プロジェクトリスクとは、「（テスト）プロジェクトの管理（マネジメント）と制御（コントロ－ル）に関係するリスク。例えば、スタッフの不足、厳しい締め切り、変更管理などがこれに当たる。」

つまり、テスト工程のリスクを、プロダクトリスクとプロジェクトリスクに厳格に分けている点が重要だ。
組み込み製品なら1回リリースするために数千～数万のテストケースをクリアする必要があるが、この時のリスクとして、テスターとPGが不足しているためにテストの進捗が悪くなるリスクはプロジェクトリスク。
テストできずにリリースして、後で品質問題に直結するリスクがプロダクトリスク。

ソフトウェア開発の基本は、プロダクトリスクの高い機能を優先して開発することだ。
そして、RedmineやTestLinkなどの各種ツールを駆使して、スタッフ不足や複雑な変更管理などのプロジェクトリスクを技術力でカバーするのが、プロジェクト管理の醍醐味だと思う。

ここで、「後追いテスト」とは「リリース後にプロダクトリスクの低いバグ潰しのテストを行う」意味らしい。

つまり、「リリース前のテストではプロダクトリスクの高いバグを最優先で潰すが、プロダクトリスクの低いバグは残したままリリースせざるを得ない。だから、リリース後の後追いテストで、プロダクトリスクの低いバグを潰していく」意味だと思う。
この手法は、特に新規顧客に対する受託開発の初めてのカットオーバーでよく使われるだろう。

例えば、新規顧客の受託開発を請け負った場合、顧客の要望を吸い取る要件定義がすごく難しい。
理由は、顧客の距離感が分からないからだ。
つまり、顧客が欲しいと思う機能は実際に使ってみたら違っていたり、開発チームが顧客の業務や会社の体制を完全に理解できないために要件を勘違いしたりする場面はいくらでも発生する。
だから、結合テストで実際に動かし、受入テストで顧客に初めて届けた時に、契約していたシステムと違っていた、という場面が多々発生しやすい。

その場合、機能も大事だが納期もすごく重要な時が多い。
特に業務システムは、他の運用中のシステムや会計システムと連動する時が多いから、納期の厳守がリリースの制約条件になる時が多い。

従って、開発方針としては、プロダクトリスクの高い機能を早く開発して、顧客に早めに叩いてもらい、フィードバックしてもらう手法がBetterだろうと思う。
そして、プロダクトリスクの低い機能やバグは、リリース後に後追いテストして、小刻みにリリースしていく開発スタイルになるだろう。
この時に、本番運用と機能追加のコードラインを別々に管理する並行開発が十分に機能すれば、後追いテストという手法を故意に選択することもできるだろう。

TestLinkでは、テスト実施結果をビルド、実施するテストケースをテスト計画という概念で別管理しているため、後追いテストの管理がやりやすい。
例えば、テスト計画に「Ver1.0リリース」「Ver1.1リリース」などのように、後追いテストのテストケースを別途分けたり、リリース済みのテストケースを使ってデグレしないか確認するために回帰テストすればよいだろう。

テスト工程のプロジェクト管理は、アジャイル開発や従来のソフトウェア開発にはなかった特有のマネジメント手法が存在しているように思う。

TestLinkのFAQ

TestLinkを運用する時のFAQをまとめたみた。
TestLinkは癖があるために運用しにくいと思うので是非参考にして欲しい。

【元ネタ】
【公開】ETWest2009講演資料「TestLinkでアジャイルにテストする」: プログラマの思索

簡易マニュアル - TEF有志によるテスト管理システムTestLink日本語化プロジェクト

連載：きちんと学びたいテストエンジニアのためのTestLink入門｜gihyo.jp … 技術評論社

TestLinkCnvMacro

【テスト計画】
【1】TestLinkをインストールしましたが使いこなせません。TestLinkはSW開発のどの工程で運用すれば効果的ですか？
【回答】
TestLinkを運用する場合、結合～受入テストで導入するのが良いでしょう。
TestLinkは手動のテストを管理するためのツールなので、自動化しやすい単体テストよりも、業務シナリオをベースにした結合～受入テストのテストケースやテスト実績を一括管理するのが効果的です。

【2】テスト計画はどんな単位で扱えばいいですか？　テスト計画にリリースバージョンを当てはめていいですか？
【回答】
TestLinkのテスト計画は、例えば「結合テストのPh1」のように、一つのテストサイクルのように扱えばよいでしょう。
つまり、テスト計画はせいぜい数百ぐらいのテストケースにグループ化して、テスト計画を順次テストしいてく戦略を採るのが無難です。

そして、テスト計画を複数回実施した場合、TestLinkのビルドで回帰テストの結果を残す運用にすればいいでしょう。
例えば、全てのテストが終了後、ビルドにビルド番号を振り直す運用にすれば、もっと分かりやすくなるでしょう。

【3】TestLinkをアジャイル開発と連携する時の注意点はありますか？
【回答】
TestLinkのテスト計画をXPのイテレーション又はScrumのスプリントのように扱えばいいでしょう。
例えば、設計から開発・単体テストまでは、1個のイテレーションでアジャイルに開発後、結合～受入テストは別のイテレーションと見なし、TestLinkの「テスト計画」として実施する運用がよいでしょう。

【テストケース】
【4】TestLink上でテストケースを登録するのが面倒です。数百～数千のテストケースを一括インポートする方法はありますか？
【回答】
最もお勧めな方法は、Excelで作りこんだテストケースをTestLinkCnvMacroへコピーして、XML出力後、TestLinkへインポートすることです。
他に、マインドマップで作ったテストケースをMmToTestLinkでインポートしたり、C/Java/Ruby/C#のテストユニットのタグからインポートしたりする方法もあります。

参考：
TestLinkCnvMacro

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

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

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

【5】TestLinkのテストケースと既存のテスト仕様書の形式が合いません。どのように落とし込めばいいでしょうか？
【回答】
基本は、テストスイートでテストケースを階層化して、上手に分割することです。
結合テスト以降では、一つの業務シナリオに対し、複数のテストケースがあり、それぞれにテストの目的があります。
例えば、下記のような形式にすればいいでしょう。

(TestProject)小売システム
(TestPlan)結合テスト
(build)9月リリース
(TestSuite1)xx画面
(TestSuite2)姓名の入力チェック機能が正常であることを確認する
(TestCase-ID)テスト仕様書のケースID
(TestCase-概要)xx画面の姓名に値を入力する(ex. y1, y2...)。
(TestCase-ステップ)zzボタン押下
(TestCase-期待値)xx画面でE1メッセージを表示する

【再テストするワークフロー】
【6】テストに失敗した場合のワークフローはどんな流れになりますか？
【回答】
基本は、テストに失敗した症状をBTSチケットに記載し、テストチームと開発チームの間で、BTSチケットをやり取りする運用になります。
テストチームが無い場合は、開発チームのテスターと開発者が連携することになります。

注意すべきポイントは2つあります。
一つ目は、失敗したテストケースとBTSチケットを必ず紐付ける運用にすること。
TestLinkは各種BTSと連携する機能があるため、活用すればいいでしょう。
失敗したテストケースが増えて面倒だったとしても、BTSチケットと連携しなければ、いつ再テストすればいいか分からなくなります。

二つ目は、BTSのワークフロー機能を使って、バグ修正とバグ検証のワークフローを管理すること。
Redmineの場合、ワークフローを柔軟に作れるので、テスターと開発者のそれぞれが作業中のステータスをチケットに追加できるように運用すればいいでしょう。

TestLinkでは、BTSチケットのステータスを一覧表示する機能があるので、再テストするタイミングが分かりやすい利点があります。

【ブロック】
【7】ブロックの使い方が分かりません。どのように使えばいいですか？
【回答】
ブロックとは、事前条件を満足できないためテスト不能な状態を表します。
(参考：ソフトウェアテスト標準用語集 日本語版Ver 1.3)

つまり、「失敗」したテストケースに依存するテストケースに「ブロック」を付けて、テスト保留とします。
例えば、小売系Webシステムでカート画面のDB更新のテストケースが失敗したら、注文フローのテストケースは全て「ブロック」になります。
つまり、ブロックとなるテストケースは、例えば、最下層のテストスイートに含まれる未実行のテストケースや、バグが出た要件に紐づくテストケースなどがあるでしょう。

上記のように、「失敗」したテストケースは「ブロッキングバグ」、ブロックするテストケースは「みなしバグ」と言われるそうです。
つまり、「みなしバグ」はテストしていないから失敗してないし、バグも出ていないが、テストしたらバグが出る可能性が高いことに注意して下さい。
「みなしバグ」のテストケースは一生懸命テストしたとしても、ブロッキングバグが解消されたら再検証する必要があるので、工数の無駄です。

TestLinkでは、ブロックを上手に使うことが大事です。
バグの状況に応じて、テストを中断したり、別のテストを行ったりする意思決定がテスト戦略になります。

【要件カバレッジ】
【8】要件カバレッジの使い方が分かりません。どのように使えばいいですか？
【回答】
TestLinkでは、要件とテストケースを紐づける機能があります。
この機能を使えば、要件カバレッジを行うことができます。
例えば、テストしていない要件がないか、チェックすることにも使えるでしょう。

TestLinkCnvMacroには、要件とテストケースを紐付けてインポートできる機能があるので、それを使えばいいでしょう。
例えば、下記の運用になります。

例：テストケース
(TestProject)小売システム
(TestPlan)結合テスト
(build)9月リリース
(TestSuite1)xx画面
(TestSuite2)姓名の入力チェック機能が正常であることを確認する
(TestCase-ID)テスト仕様書のケースID
(TestCase-概要)xx画面の姓名に値を入力する(ex. y1, y2...)。
(TestCase-ステップ)zzボタン押下
(TestCase-期待値)xx画面でE1メッセージを表示する
(keyword1)1-1.1　←要件管理IDを振る

例：要件リスト
要件仕様-タイトル：小売システム
要件仕様-スコープ：小売システムの要件
要件リスト-要件名：1-1.1　(注：要件管理ID)
要件リスト-DOC-ID：1-1.1
要件リスト-タイトル：1-1.1
要件リスト-スコープ：xx画面/姓名は必須で、全角文字40文字まで入力可能

TestLinkでは、テスト実績の要件カバレッジも一覧表示できるので、リアルタイムに要件のテスト網羅率を確認することができます。

【メトリクス分析】
【9】テスト終了後、TestLinkに溜まったテスト実績を分析する方法はありますか？
【回答】
TestLinkCnvMacroを使えば、下記の観点でメトリクスを出力できます。
テストプロセスの進捗や品質について考察する資料になるでしょう。

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

TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス

僕はテスト技法を体系的に知らないが、TestLinkを過去1年間実践してみて、テスト戦略やテストケースの作成方法について、ノウハウは色々溜めてきた。

TEF関西のNakaさんからテスト技法の専門用語を教えてもらい、そのノウハウに専門用語が付けられているのを知ったので、まとめてみる。

【元ネタ】
JSTQBテスト技術者資格認定-シラバス（学習事項）・用語集-

ソフトウェアテスト標準用語集 日本語版Ver 1.3

【1】みなしバグとブロッキングバグ

TestLinkのテストケースには「ブロック」という状態がある。

ソフトウェアテスト標準用語集 日本語版Ver 1.3 によれば、ブロックとは「事前条件を満足できないため、実行不能のテストケ－ス」を指す。
つまり、失敗したテストケースに依存するテストケースがブロックの対象になる。
例えば、小売系Webシステムならば、カート画面のDB更新のテストケースで失敗したら、注文フローは全てブロックになるだろう。

Nakaさんによれば、失敗したテストケースのバグを「ブロッキングバグ」、ブロックしたテストケースを「みなしバグ」と言うらしい。

つまり、ブロックしたテストケースは、「ブロッキングバグ」が直らなければ、再テストできない状態にある。
ブロックしたテストケースは「みなしバグ」だから、一生懸命テストしたとしても工数の無駄だ。
実際のテストでは、バグが出るたびに「みなしバグ」のテストケースを判別するのが非常に難しく、テスト工数を無駄に浪費してしまいがちだ。

管理者は、バグが出るたびに依存するテストケースをブロックして、他のテストを指示したり、再テストのタイミングを図る。
TestLinkでは、テスト実績やバグチケットの状態をリアルタイムに表示できるため、再テストの指示がやりやすくなる。

「ブロッキングバグ」は滞留時間が長くなるほど、ブロックしたテストケースのテスト工数も加算すれば、再テスト工数が大きく増える。
テスト工程は普通、プロジェクト後半という時間が限られた状況にあるため、管理者は、再テストのタイミングを図りながら、バグ修正の優先順位付けをする意思決定が重要になってくる。

テストケースをブロックする判定条件は、どんなものがあるだろうか？

TestLinkにはテストスイートという階層構造があり、テストスイートに、システムの機能(大・中・小)・テストの目的・業務シナリオなどの項目を当てはめる。
例えば、結合テストのように業務シナリオや画面遷移のパターンでテストする場合、一つのシナリオに複数のテストケースが属している。
従って、シナリオに含まれる一つのテストケースが失敗した場合、それ以降のシナリオのテストケースは全てブロックになる。

TestLinkでは、テスト実行画面でテストスイートの単位でテストケース数が集計表示されるので、どれくらいのテストケースがブロックになるか、判断しやすい。

しかし、TestLinkのブロックしたテストケース一覧画面には、ブロッキングバグの発生源である失敗したテストケースとリンクする機能が無いのが惜しい。

【2】周辺テスト

「周辺テスト」とは、再テスト時に、ある観点にグループ化されたテストケース群を回帰テストすることを呼ぶらしい。

例えば、小売系Webシステムで、カート画面で商品削除のテストケースで失敗したとしよう。
バグが直っていない場合、カート投入したテストケースは「成功」、カートから商品削除のテストケースは「失敗」、注文フローは全て「ブロック」になっているだろう。

そして、バグ修正して、バグ検証が終わり、ブロッキングバグが解消されたとする。
すると、カートから商品削除のテストケースは再テストして「成功」にできるが、カート投入したテストケースももう一度回帰テストすることを「周辺テスト」と呼ぶ。

「周辺テスト」をやる理由は、ブロッキングバグの修正でデグレしていないかのチェックをしたいからだ。
実際の運用では、シナリオに従って画面からデータを作り直して再テストするから、失敗したテストケースの前に既に成功を確認したテストケースを自然に回帰テストしているだろう。

TestLinkでは、テスト結果の履歴を保持できるため、回帰テストを管理しやすい利点がある。

【3】みなしOK

VerUpしたシステムのテストをする場合、ソース修正されていない機能のテストケースは「みなしOK」として、テストしない判断をする。
おそらく管理者や設計者がその判断を下しているだろう。

本来ならば、ソース修正されていない機能のテストケースも回帰テストでテストすべきだ。
なぜなら、機能追加によって、他の部位にも影響が出てバグが発生しているかもしれないからだ。

しかし、実際はテスト工数を確保できないため、この要件は単体テスト済みなのでテスト不要、とか、このテストはシステムテストでやるから今のテスト計画ではテストしない、などのテスト戦略を採用しているだろう。

あるいは、既に本番稼動して特に問題ないので、この機能は運用品質を満たしているという判断を下す場合もあるだろう。

「みなしOK」の判断はとても難しく、設計者の技量を問われる部分でもある。

【4】テストケースにもクリティカルパスがある

テストに失敗してバグが増えると、ブロックしたテストケースは飛躍的に増える。
すると、テストケースの失敗率のある上限値を超えると、テスト計画に含まれる全てのテストケースがブロックになってしまい、テスト不能になる状況が考えられる。
つまり、テスト不能の状況は、全てのブロッキングバグを最優先に修正しなければ、テストしても無駄な状態を意味している。

TestLinkのテスト計画をXPのイテレーション、Scrumのスプリントのように扱って順次テストしていく戦略を採る場合、テスト工数にバグ修正とバグ検証の工数も考慮する必要がある。
つまり、テストケースにはクリティカルパスの概念がはっきりと存在する。

例えば、テスト計画が小売系Webシステムの結合テストのPh1だったと仮定しよう。
TestLinkのテスト計画をXPのイテレーションに見立てると、２～４週間で全てのテストが終わる前提でテスト戦略を作る必要がある。

ここで、それぞれのテストケースにテスト予定工数を記入しておいたとしよう。
TestLinkでは、テストケースにテスト予定工数のカスタムフィールドを用意すればいいだろう。
すると、テスト予定工数の総和がテスト計画の最低限の予定工数となる。

更に、テストスイート単位の予定工数も計算できるので、ブロッキングバグが発生した場合、再テストの予定工数も計算できる。
この場合の予定工数は、失敗したテストケースの工数、ブロックしたテストケースの工数の和、バグ修正の工数の3つの和になる。
従って、ブロッキングバグのチケット単位で再テスト工数を一覧表示できる。

テストケースは普通シナリオベースのため、先行・後行関係があるから、テストケースのPERT図に再テスト工数を入れれば、そこからクリティカルパスを見出すことができる。

つまり、テスト計画から想定されるバグ数から、再テスト工数も予想で計算できるので、それを足せば、テスト計画の予定工数になる。

バグが頻発した場合、管理者はテストケースの依存関係と再テスト工数の一覧を見ながら、どのバグを最優先で直して再テストすべきか、という意思決定ができる。
あるいは、テストチームは開発チームへ、このバグは再テスト工数と納期を考慮すると、MM月DD日までに修正してもらわないと納期に間に合いません、と連絡することもできる。

これがテスト工程における本来のマネジメントなのだろう。

現状のTestLinkでは、工数計算やスケジュール管理の機能は無く、クリティカルパスを見つけるのは難しい。
TestLinkCnvMacroでテストケースとテスト実績をExcelで出力して、Excel上で解析するしかない。

【まとめ】
オブジェクト指向プログラミングでは、デザインパターンと言うベストプラクティス集がある。
デザインパターンがあるからこそ、他の開発者と概念を共有できるし、プログラムも綺麗になる。

同様に、TestLinkはオープンソースのため、世界中の技術者の要望が組み込まれたテストに関するベストプラクティス集の集まりみたいなもの。
「ブロック」や「ビルド」のように、TestLinkの機能には、先人の知恵が詰まっている。

最近思うのは、RedmineにせよTestLinkにせよ、オープンソースの管理ツールには、ベストプラクティスがたくさん詰まっていること。
Redmineにある「ワークフロー」の柔軟な機能を上手に使えば、ITILの変更管理に似た運用ができる。
更に、Redmineを使いこなせれば、チケット駆動開発を実践できて、自然にアジャイル開発になる。

同様にTestLinkも使いこなせれば、テスト技法の理論を試しながら、テスト技法の経験を積むことができるだろう。

【告知】Shibuya.trac第4.5回勉強会で発表します

ソフトウェア品質シンポジウム2009で講演するために上京する際に、Shibuya.trac有志の方のおかげで、下記の勉強会を開催して頂ける事になりました。
僕も、チケット駆動開発とTestLinkについて発表するので、ご興味のある方はご参加下さい。

【内容】
Shibuya.trac第4.5回勉強会

日時: 2009/9/11(金) 19:00-21:00
場所: 未定(都内を予定)

１・タイトル：「RedmineとTracの機能比較～TiDDに必要な必須機能」
概要：RedmineとTracの機能を比較した後、チケット駆動開発に必要な機能を提示してみます。

２・タイトル：「TestLinkを運用するための6つの方法」
概要：TestLink運用のハードルを下げるための6つの実践ノウハウを説明します。

などその他。

システム開発に必要な役割

プログラマやテスターの能力に関して考えたことをメモ。

【元ネタ】
小野和俊のブログ:1・10・100、それぞれの力

小野和俊のブログ:プログラマー風林火山

プログラマと呼ぶ時、すぐにイメージするのはGoogleのように独創的なプログラムを書く人をイメージする。
しかし、実際の現場では、色んな役割の人達が必要になってくる。

新規顧客の新規開発の場合、初めてのフレームワークを元に、スクラッチで作っていく。
最初に必要な人は、何も無い所から動くものをまず作る役割。
このタイプは、新しい技術の飲み込みが早く、試行錯誤するのが好き。

新しいフレームワーク、新しい言語を使う場合、独特のプログラミングの書き方がある。
その作法に慣れるまでに、普通の開発者は時間がかかる。
だから、最初は、新物好きの技術者にプロトタイプを作ってもらい、そのサンプルを真似ながら、普通の開発者は作っていく。

そして、システムにどんどん機能追加されて、一つのシステムとして稼動するようになった時に必要にされる人は、テスターの役割。
バグを発見し、バグを検証し、一つずつ積み重ねながら、品質を上げていく。
このタイプは、設計書をこまなく読んで理解でき、丁寧に、地道な作業ができる人。

実際の開発では、結合テストやシステムテストでこの役割の人が重要になってくる。
この工程で初めて、開発者も自分たちのソースが動く所を見れるから、初めて実装のミスマッチに気付く。
テスターは、プログラマが何もない所で切り開いた道をなだらかにする。

RedmineやTestLinkを運用していると、プログラマとテスター、設計者の連携作業が実はボトルネックだったという事実によく気付く。

例えば、仕様変更があったとしても、アサインしたタスクに漏れがあったりする。
あるいは、せっかくバグ修正したとしても、たくさんのバグを発見しすぎて、バグ検証が遅れたりする。
又は、一つのバグを見つけたら、それに関連する機能や要件はテスト不要なのに、無駄にテストしてしまう。

チケット駆動開発やテスト管理のツールは、この連携作業をサポートするのが一番の目的だ。

そして、アジャイル開発は、システムを小刻みにVerUpさせる戦略を意図的に採用することで、品質維持と機能拡張という矛盾する目的を実現しようとする。
このアジャイル開発のタスク管理やテスト管理をサポートするツールが、Redmineであり、TestLinkであったりする。

色んな役割の人達が集まったチームに対し、開発インフラを提供し、そのコミュニケーションを支援するのが、チケット駆動開発であり、プロジェクトファシリテーションだったりする。

色々試してみたい。

TestLinkを運用して気付いたことpart7～要件カバレッジは難しい

TestLinkの要件カバレッジを振り返って気付いたことをメモ。

TestLinkを約1年使ってみて、そして過去のテスト実績を分析しながら、特に結合～受入テストの難しさを改めて痛感している。

TestLinkでテストの進捗管理はやりやすくなるが、やはり一番大事なのは、テストケースそのものの品質だ。
テストケースの粒度が殆ど同じで、テスターがすぐに理解できる内容にする必要がある。

そして、テストケース作成で最重要な点は、要件カバレッジ。
テストケースが要件を全てカバーしていないならば、そこからテスト漏れ、引いてはバグになる。

実際のテストでは、この要件は単体テストで保証済み、とか、この要件は最後のシステムテストで確認するから保留、などのように、テストすべき要件を間引いて、最小のテストケース数でもってテストしていく。

TestLinkでは、要件とテストケースが相互リンクしているので、要件がどのテスト計画のどのテストケースに紐づいているか、追跡できるため、要件カバレッジを確認する作業が格段に楽になる。

でも、要件カバレッジは非常に難しいのが実情だ。
TestLinkで要件カバレッジを分析してみると、一つのテスト計画で全ての要件を100％でカバーできない。
僕の経験では、テスト方法によるが、一つのテスト計画で約60％ぐらいしかカバーできない。
複数のテスト計画(単体・結合・総合・受入テストなど)を実行して、初めて100％になる。

理由は、TestLinkのテスト計画をXPのイテレーションと同一視して運用するため、２～４週間と言う短い期間だから、せいぜい数百個ぐらいのテストケースしかこなせない。
全ての要件をカバーできるテストケース数をこなすには、複数のテスト計画が必要だからだ。

逆に言うと、テストしやすいようにテスト計画(イテレーション)の単位で管理しているため、テストそのものの進捗管理はやりやすくなっている。

従って、要件カバレッジを100％にするためのテスト戦略が必要になってくる。

最も現実的な戦略は、要件をテスト工程別に分割して、それぞれのテスト工程で検証していくことだろう。
つまり、境界値分析しやすい要件は単体テストでみっちりやる、とか、画面の複雑な状態遷移の要件は結合テストで色んなパターンでテストする、などのように、テストの観点を分けてみる。

要件をテスト工程別に分割する利点は、要件を仕様へ詳細化していく流れと一致しやすいことだろうと思う。
要件定義や外部設計の段階では、そもそも要件はぶれやすく、変更や追加が多いだろう。
詳細化していくに従って、要件も具体化されて、仕様としてある程度固定化できる。

この時に、テストケースの分類項目と要件の分類項目の粒度を合わせられるとよい。
TestLinkでは、テストケースをテストスイートで階層化できるため、分類しやすい。
最新のVer1.8以降では、TestLinkの要件も階層化できるようになったから、要件の階層とテストスイートを紐づけできればなお良いだろう。

要件カバレッジをコードカバレッジのように扱うことで、テストケースの品質や観点を向上できるだろうと思っている。

TestLinkの運用例

TestLinkの運用例を見つけたのでメモ。

【元ネタ】
TestLink使用レポート ― ありえるえりあ

記事から類推すると、かなりのテストケース数でテストしているのではないかと思われる。
下記にまとめてみた。

【従来】
・テキストベースでテストケースを管理していたから、把握しにくい。
・毎日メールでテスターから進捗を連絡してもらったが、進捗管理しにくい
・不具合が発生した場合のワークフローが曖昧
・テストケースそのものが読みづらい

【TestLink運用後】
・テストスイートごとにテストケースの数を表示してくれるので、テストの範囲や工数を把握しやすい。
・テスト計画やテスターの単位で進捗率を表示してくれるので、進捗が分かりやすい
・テスト実行画面からケースを絞り込んでテストできる。
・テスト結果画面から、不具合一覧を見れる
・テストケースが単体で存在し、文章に色や下線、箇条書きなどで装飾できるので、テストケースが読みやすい

【TestLinkで物足りない点】
・過去のテスト仕様書を移行するのが大変
・実行結果に登録したチケット番号はテストケース自体へは反映されない
　→記事によると、テスト計画終了後に、テストケースのカスタムフィールドに「過去の不具合」を作り、そのフィールドにBTSチケット番号を書き記している。

最後の点は、なるほどと思わせる。
TestLinkでは、テストケースとテスト実施結果は1対多の関係にあり、別個の存在である。

しかし、テスト仕様書として出力する場合、テストケースの履歴で特に過去の不具合内容は全て書いておきたいものだ。
その場合、テストケースと過去の不具合のチケット番号は、1対多(実際は0以上)の関係になるだろう。

従来のExcelのテスト仕様書では、テストケースの行には、「関連１」～「関連５」のような項目が5個ぐらい存在している時がある。
以前、その「関連１」～「関連５」の使い道を聞くと、テストケースの依存関係を示すテストケースNoを振るためのものだと聞いた時があった。

僕がTestLinkを運用した時、「関連１」～「関連５」には、要件管理IDを振って、要件カバレッジに使っている。
しかし、それだけでなく、過去の不具合チケットNoやブロックの発生源となったテストケースIDも振りたいものだ。

つまり、「関連１」～「関連５」は、テストケースの要件、あるいは、テストケースの実施結果の発生源と紐付けたい。
すなわち、テストケースとテスト実施結果が1対多となる関係をもっとたくさんの種類で色づけしたいのだ。

それらは、例えば、テストケースのキーワード、あるいは、テストケースのカスタムフィールドで表現されるべきなのだろう。

TestLinkにはまだまだ使い勝手の向上の余地があるけれど、テストに対し、色んな気付きを示唆してくれる。

プロジェクト管理サーバーのメトリクスは教科書みたいだ

プロジェクトが一段落したから、メトリクスを出力してみた。
その時に気付いたことをメモ。

【元ネタ】
プログラマの思索: プロジェクト管理サーバーとは
プログラマの思索: アジャイル開発の弱点をプロジェクト管理サーバーが助ける

【各種ツール】
BitNami :: Trac
All In One TestLink JP
TestLinkCnvMacro
StatCVS - Repository Statistics
StatSVN - Repository Statistics

Tracから、カテゴリ、マイルストーン、解決方法、種類などの観点のチケット集計結果。

TestLinkにあるテスト実績からTestLinkCnvMacroを使って、テストケースの成功・失敗・ブロックの累積グラフ、曜日別・時間別・ピーク時間別のテスト実績、そしてテスター毎の生産性グラフ。

SVNリポジトリやCVSリポジトリから、StatSVNやStatCVSを使って、システム全体・サブシステム毎のLOCの累積グラフ、プログラマ毎の生産性グラフ。

これらのメトリクスは、上記ツールですぐに出力できる。
そのメトリクスを印刷して、メンバーにメトリクスの意味を説明したら、「まるで教科書みたい！」と言われた。

理由は、基本・応用・高度情報処理試験でSW工学や信頼度成長モデルの問題が出てくるが、実際の現場では今まで使ったことがなかったから、とのこと。

メンバーのその言葉を聞いて、SW工学の座学だけ知っていても、実際の現場で使えなければ無意味なんだな、と思った。
普通の現場にいるSEやPGは、基本・応用・高度情報処理試験の知識をどれだけ現場で使いこなせているのだろうか？
実際は、それらの知識は殆ど役立っていないのではないか？

普通の現場リーダーは、コストと納期に追われて、従来と変わらないKKDのプロジェクト管理しか知らない。
だから、現場で得られたメトリクスとSW工学の知識を組み合わせて、事実に基づいた意思決定を行うというマネジメントの基本スキルを普通の現場リーダーは知らない。

チケット駆動開発は、メトリクス出力を背後で自動集計する機構があるから、このメトリクスを正しく分析することで、効果的な意思決定を行うことができる。

更には、僕が考えるプロジェクト管理サーバーのインフラがあれば、プロジェクトマネージャにとって必要なマネジメント情報はいつでもすぐに得られるし、そこから良質の意思決定ができるようになるだろう。

TestLinkを運用して気付いたことpart6～テスト工程のプロジェクト管理

TestLinkでテストケースを作りこんで、テストしていくと、色んなことに気付く。
TestLinkでテストしていきながら感じたことをメモ。

【1】ウォーターフォール型開発では、下流工程にテストが来る。
単体テスト、結合テスト、システムテスト(総合テスト)、受入テストの違いをきちんと使い分けているだろうか？

テストは基本的に、V字モデルの左側の工程の検証作業になる。
単体テストは開発工程の検証だが、結合テストの違いは何だろうか？

単体テストは、最低限動作することを保証すること。
Exceptionが発生するようでは話にならない。
ホワイトボックステストで、最低限、分岐網羅(C1)を検証する。
だから、コードカバレッジが非常に重要になる。

結合テストは、複数のモジュール同士を結合して動作するのを検証する。
普通のプロジェクトでは、結合テストで火を噴くことが多い。
理由は、結合テストになって初めて、顧客だけでなく開発者も、実際にシステムが動くのを見れるからだ。
システムは、いくら設計をやったとしても、動かさないとイメージが湧きにくい。
そこで初めて、設計漏れ、要件漏れに気づくことも多い。

【2】Webシステムならば、結合ストで、複数の画面の間で遷移するテストになる。
結合テストでは、単に画面遷移するだけでなく、画面の状態のパターンに対してテストする。
つまり、システムの状態遷移図に従って、正しく遷移するか、おかしな遷移はしないか、を確認することになる。

結合テストで火を噴きやすい理由は、システムの状態遷移図に設計漏れがあったことに初めて気付く工程だからだと思う。
状態の数がわずか数個でも、その状態遷移のパターン数はすぐに爆発する。
全ての状態遷移を設計し尽くすのは、かなりの労力がかかるし、高度なモデリング力を必要とする。

例えば、Amazonのような小売系Webシステムの結合テストを考えてみよう。
商品は、会員によって商品検索で発見され、カート画面に入って、注文フローを通って注文完了されて、ようやく終わる。
その間の商品のステータスは、「カート」「注文中」「注文完了」が最低限あり、それらのステータスを結ぶと、状態遷移図が出来上がる。

この状態遷移図から結合テストのテストケースを作る時、「カート→注文中→注文完了」だけでなく、「カート→注文中→カート→注文中」「カート→注文中→カートから削除」など、フローを逆に戻るようなケースも必要だ。
この時に、実装漏れ、設計漏れが判明しやすい。

更に、注文完了後に、商品の配送前に注文取消ができる要件があったとしよう。
すると、「商品の配送前に注文取消できる」「商品の配送後は注文取消できない」というケースも出てくる。
この2個のケースに上記のケースも組み合わせると、テストケースは指数関数的に増えていく。

結合テストでは、他のステータスも考慮するから、画面に出てくるオブジェクトのステータスが多いほど、テストケースは爆発的に増えるから、納期までにテストを終えるのは高度なプロジェクト管理能力が必要になってくる。

【3】そして、システムテストでは、時間軸に沿って、業務シナリオに従ってテストする。
販売期間中の商品を注文した場合、商品をカートに入れたまま放置して販売終了になった場合、など、色んなフローを時間軸と絡めてテストケースを作る。

システムテストでは、システム間同士の結合テストも含まれる時がある。
特に、フロントのWebシステムと、バックエンドで動くバッチあるいはメインフレームのインターフェイスを確認する時が多い。
ここでも、初めて稼動するのを開発者も見るから、初めて仕様の本来の意味が分かる時も多い。

そして最後は、顧客が実際に使えるかどうか、受入テストを実施する。
このテストケースは今までのテストケースがほぼ流用されるが、顧客はこの工程で初めて触れるから、本来の要件がずれているのを初めて気付いたり、やっぱり使いやすくして欲しい等と言った仕様変更が大量に押し寄せる時がある。
特に、新規顧客で、第1次開発案件で最初のリリースでは、開発チームと顧客の距離感が分からないため、要件の認識相違が非常に多い。

【4】それぞれのテスト工程では、テストの目的は大きく異なる。
だが、一番注意すべき工程は、僕の経験では、結合テストだ。
その結合テストで一番の肝は、システムの状態遷移図を漏れなく、整合性を取りながら書ききれるかどうかにかかっている。

そして、その結合テストでもう一つ重要なのは、要件カバレッジだ。
実際は、仕様を全てテストで検証されているか、仕様のカバレッジを考慮しているか、ということ。
実際の現場では、そもそも要件や仕様にIDが振られておらず、テストケースはどんな背景から作られたのか、という作成理由が曖昧なまま作る時が多い。
すると、必ずテストされていない仕様や要件が出てきて、そこが潜在バグになる。

TestLinkを運用して使いこなしていくと、テストケースそのものの品質が重要になってくる。
テストケースがシステムの状態遷移を全て網羅していないならば、テストされない遷移からバグが出る。
テストケースが全ての要件や仕様を網羅していないならば、テストされない要件からバグが出る。

TestLinkでは、要件管理の機能があり、テストケースと要件を紐付ける機能がある。
この機能を使い要件解析すると、テストされていない要件を簡単に探すことができる。

また、TestLinkのテストケースは階層構造にできるため、状態遷移図のステータスやフローの種類でグループ化することができる。
これによって、テストケースを管理しやすくなる。

運用保守では、リアルタイムに保守されない仕様書よりも、過去に使われたテストケースの方がはるかに重要だ。
テストケースこそが、仕様そのものだからだ。
そのテストケースを再利用して回帰テストを行えば、デグレ防止にもなる。

【5】現場リーダーも開発者も、要件定義から開発までの上流工程のプロジェクト管理に関心が行きがちだが、実は、下流工程に当たるテスト工程のプロジェクト管理の方がはるかに難易度が高い。

TestLinkを運用してから、テストの進捗管理やバグ修正＆検証フローが非常に管理しやすくなり、テスト工程のプロジェクト管理がものすごく見える化できるようになった。
他にも考えてみたい。

バグはマインスイーパーみたいだ

「品質がスケジュールよりも優先される理由: プログラマの思索」を書いた後に思ったこと。
バグはマインスイーパーみたいだ。

1個のバグが出るたびに、周辺の機能は正常動作が確認できなくなる。
わずか10％のバグが出たとしても、殆ど全ての機能がみなしバグになってしまい、テストしても無意味になる。

ほんのちょっとの地雷があるだけで、その周辺の広範囲は地雷原になってしまう。

ハードウェアでは、ある程度の不良品を出さなければ、逆にきちんとテストできているのか、不審がる。
信頼度成長曲線のような品質保証のモデルが既に理論的に作られている。

でもソフトウェアでは、バグはなるべく出さない方がいい。
バグが少ないほど、品質は安定し、スケジュールも短縮化し、工数も少なくなる。

品質はスケジュールよりも優先する。

品質がスケジュールよりも優先される理由

CMMIを作ったハンフリーが書いた本「ソフトウェアでビジネスに勝つ」を読んでいる。
mgさんのコメントを書きながら、考えたことをメモ。

【元ネタ】
アジャイル開発は受託開発の方が向いている: プログラマの思索

「ソフトウェアでビジネスに勝つ」の本は、経営者向けに書かれたソフトウェア管理に関する考察した本。
第1章に、SW管理の原則が3ついきなりあげられるが、その一つに「品質がスケジュールよりも優先する」という原則がある。

SW開発に従事している人ならば、この原則をいつも実感しているし、逆に、この原則に逆らうような仕事をしているのも事実だ。
設計や開発という工程よりも、テスト工程でこの原則を実行すべきかどうか判断に迷う。

仕様変更が来たけれど、バグ修正を優先すべきか？
バグ修正よりも、目先のタスクをこなすべきか？
全てのテストをし尽くしてバグをたくさん出してから、バグ修正すべきか？

今、僕はTestLinkで結合～受入テストを管理していて、「品質がスケジュールよりも優先する」の原則の重要性を改めて感じている。

TestLinkでは、テスト実施結果をリアルタイムに表示できるので、テスト実施数だけでなく、成功ケース数、失敗ケース数、ブロック数を毎日集計できる。

仮に、テスト中のテスト計画にあるテストケース数が500ケースあったと仮定しよう。
開発チームあるいはテストチームは、500個のケースをこなしていくと、必ず失敗するケースが発生して、バグが出てくる。

この時に、テストケース同士で依存するケース数が平均10個だと仮定しよう。
例えば、Amazonのような小売系Webシステムならば、カート画面のテストの次に注文画面のテストケースがあるから、カート画面と注文画面のテストケースは依存していることになる。

すると、テストケースが1個失敗するたびに、バグが1個増えて、依存するテストケース10個が「ブロック」になる。
理由は、依存するテストケースは、テストしたとしても必ずバグが出る「みなしバグ」だからだ。
つまり、ブロックしたテストケースは、一生懸命にテストしたとしても工数の無駄だ。
バグが修正されなければ、テストしても無意味なのだ。

今、仮に、テスト計画の全テストケースを実施して、失敗率が5％だったと仮定しよう。
すると、失敗ケース数やバグ数は25件あり、依存するテストケースは250件だから、ブロックするテストケース数は250件になる。
つまり、500件のテストケースのうち45％しかテストで「成功」、つまり、品質が確保されたに過ぎず、残りの55％はテストで確認すらされていない状況になる。

更に、失敗率が10％だったと仮定しよう。
すると、失敗ケース数やバグ数は50件になり、ブロックするテストケースは単純に数えると500件になる。
つまり、10％以上失敗したら、殆ど全てのテストケースが「みなしバグ」の状態なわけで、もはやテストしても工数の無駄。

結局、テストよりもバグ修正を優先しなければ、テストすら終わらない。
バグ修正よりも仕様変更を優先したとしても、みなしバグが多発した状態で機能追加したとしても、状況は一段と悪化するだけだ。

「ソフトウェアでビジネスに勝つ」本では、品質が良ければテスト工程が短縮されてスケジュールは前倒しになる、と書かれているが、おそらく上記のような事実を指しているのだと思う。

TestLinkの良い所は、上記のような事実を過去のテスト実績から集計して分析できることだ。
過去のテストから、バグが頻発した要件は注意したり、あるいは、過去の開発でバグが多発した要件のテストケースを再利用して、念入りにテストするといった戦略を取る事もできる。

アジャイル開発というよりもソフトウェア開発のプロジェクト管理が、品質・コスト・納期の三角形ではなく、スコープ・コスト・納期の三角形でマネジメントする理由も同じだ。

ソフトウェアの品質を優先すれば、自然にコストは下がり、スケジュールも短縮できる。
「品質がスケジュールよりも優先する」原則をIT技術者は再考すべきではないか？

チケット駆動開発の運用例part2

八朔さんによるチケット駆動開発の運用例をメモ。

【元ネタ】
チケット駆動開発 - Live a meaningful Life

プロジェクトの作業をWBSの観点で、要件→成果物→作業のツリー構造へ分解している。
プロマネらしく、チケットの構造が上手だと思う。

このやり方ならば、ソース←【チケット(作業)】→【チケット(要件)】の観点で追跡可能だ。
【チケット(要件)】で集計すれば、顧客向けの進捗報告として、進捗率や工数を集計できる。

アジャイル開発の観点では、要件はストーリーカード、成果物や作業はタスクカードに割り当てられると思う。
顧客の観点でシステムの価値を表すのがストーリーカードであり、チケット駆動開発における成果物は、開発者の観点で捕らえるべきだろうと思う。
そうでなければ、開発者が作業するレベルにならないからだ。

後で、八朔さんに聞いたら、要件のチケットから実際のテストケースへ落とす所まで考えておられた。
つまり、テストケースは、要件とストーリー(ユースケースぽい業務シナリオ)のマトリクスで作れるはず、と。

そうすれば、チケット(要件)→テストケース→バグ→ソースコミット　という形で追跡可能になる。
僕は今、TestLink上で要件管理とテストケース管理を紐づけているが、最終的にはRedmine上で要件管理も行いたい。
その方が、スケジュール管理や工数管理もやりやすいからだ。

昨日のPFP関西WSでは、Redmineをタスク管理に実際に使っているという人もチラホラいた。
今、チケット駆動開発は熱いのかもしれない。

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 の連携 - かおるんダイアリー

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

事象にユニークな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技術者としての基本動作も含まれているような気がするのだ。

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

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

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

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

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

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

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

1.テストケースは、結合テストの観点も入れた業務シナリオベースで作る。
2.テストケース数は 500 強。
3.テスト計画は１個だけ。つまり、全テストケース500個余りがアサインされている。
4.リリースモジュールがβ１、β２、β３、最終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によるテスト管理には、まだまだ色んな可能性があると思う。

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

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

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

View more documents from akipii.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TestLinkにあるアジャイルの概念

下記の記事を読んで気づいたことをメモ。

【元ネタ】
TestLinkを検証しました ― ありえるえりあ

【引用】
テストケースの管理と、テスト計画(=テスト実施の記録)の管理のふたつの軸があるのがポイントです。
RDBアプリ風に言えば、前者がマスター(リソース)、後者がトランザクション(イベント)的な構造です。
テストケースは手順と期待値の記述で、何度も実施されればその度ごとに結果レコードができます。
テストケースの1レコードに対して、実施結果のレコードは1対多の関係で存在します。

テストケースと実施結果が1対多の関係になるのは、言われてみれば自然で当り前の構造なのですが、バグトラッキングシステム(BTS)とは違うんだという現実に改めて気づきました。
昔、wishlistもBTSで管理している話を書きました(http://dev.ariel-networks.com/Members/inoue/wishlist-management)。
実を言うと、テスト管理もBTSでできるのでないかと漠然と考えていたことがあります。
テストの実施をテストエンジニアにアサインして、実施後に結果がでるという一連の流れがBTSの一連のフローと似たようなものだと思っていたからです。
実に浅はかでした。
テスト管理ツールにはテスト管理ツールの存在意義がありました。先人の知恵を無視してはいけません。

【プロダクトバックログとスプリントバックログの違い】
上記の記事のポイントは2つある。
一つは、テストケースとテスト結果は1対多の関係になること。
もう一つは、テスト管理はBTSのワークフローでは制御しにくいこと。

前者は、TestLinkにある「テスト仕様」と「テスト計画」の概念の違いと同等だ。
(正しくは、「テスト仕様」と「ビルド」である)
つまり、Scrumで例えるならば、TestLinkの「テスト仕様」はScrumのプロダクトバックログ、「テスト計画」はScrumのスプリントバックログに相当する。

Scrumでは、顧客からの改善要望や障害報告などは、まず、プロダクトバックログに全て放り込まれる。
そして、スプリント計画を作成する時に、どのスプリント(XPのイテレーション)でその要望を実現するか、を吟味する。
プロダクトバックログにある要望がスプリントに追加されて、そのスプリントで何をリリースするか確定したら、スプリントバックログが確定される。
つまり、プロダクトバックログは、スプリントにアサインされていない要望の貯蔵庫なのだ。

同様に、TestLinkのテスト仕様もテストケースの貯蔵庫と言ってよい。
テスト仕様にあるテストケースから、実施するテスト計画へテストケースを追加していく。
テスト計画に追加されたテストケースは、実施予定のテストケースであり、テスト仕様のテストケースと実体は同じでも、意味合いは大きく異なるのだ。

Scrumのようなアジャイル開発では、頻繁な改善要望に対応するために、イテレーション(スプリント)に入れる前の要望を管理するプロダクトバックログという概念が必要になったと思われる。

つまり、プロダクトバックログで要件管理を行っているのだ。
スプリント計画を作る時に、プロダクトバックログにある要望を優先順位付けするという作業が必要になる。
この作業が本来のマネジメントでもある。

後者は、素のBTSには、プロダクトバックログつまり要件管理の概念が無いことから生じるのだと思う。
BTSは障害報告票をデジタル化して運用するために作られたので、プロダクトバックログのように障害報告を貯蔵する仕組み(つまり要件管理)の無いBTSでは運用しづらいだろう。

特に、単体・結合・総合・負荷・受入テストなど全てのテストケース数を合計したら、ちょっとした業務システムでも、テストケースは軽く1万ケース近くに膨れ上がるだろう。
だからこそ、２～４週間以内に完了できるテストケース数に抑えないと、回帰テストを実施できないだけでなく、全テストケースを流し切ることさえできないだろう。

つまり、テスト仕様には1万個ものテストケースを一旦貯めておき、複数回のリリース(開発)を前提として、複数個のテスト計画を順次実行する運用にしなければ、実施できないテストケースが出てしまい、システムの品質以前に、テスト工程に大きな問題が出ることになる。

僕としては、開発とテスト工程のワークフロー管理は、BTSとTestLinkで使い分ければよいと考える。
無理して、一つのツールで運用する必要も無い。

ツールでプロセスを改善していく。
ツールでアジャイル開発のハードルを下げられればいい。

チケット駆動開発を開発プロセスへ理論化できるか？

下記Blogで、これがやりたいことなんだ！と思ったのでメモ書き。

【元ネタ】
実践バグ管理―プロジェクトを成功に導くための (単行本) - watawata日記

まあ要するに僕が読みたいのはバグ管理も含めた構成管理とか開発プロセスの本なんだｗ。

僕が考えるプロジェクト管理サーバーのイメージは下記の通り。

RedmineやTracのようなプロジェクト管理機能を持つBTSをチケット駆動でタスク管理する。

Subversionで、ソースコードだけでなく、WordやExcelの仕様書もバージョン管理する。
更に、trunkとブランチを上手に使い分けて、メインラインモデルとしてコードラインを並行開発する。

Hudsonで、継続的インテグレーションを実現するだけでなく、並行に走らせて、ビルドや自動テストの工数を短縮する。

TestLinkで受入テストを効率化する。

VMWareでテスト環境、本番環境を仮想化して、複数の環境を作り、並行テストしてみる。
あるいは、複数のブラウザや複数のバージョンのOSのクライアント環境を仮想化して、ブラウザ依存、OS依存の検証をできるようにする。

上記のようにツールを駆使して、SW開発のプロジェクト管理からExcelをなくす。
プロジェクト管理サーバーを用意して、アジャイル開発の弱点を補強して、アジャイル開発のハードルを下げる。
ツールに合わせた運用によって、現場独自の開発プロセスを編み出す。

ツールはあくまでもSW開発を楽にするための道具の一つ。
特にオープンソースのツールには、世界中の開発者のベストプラクティスが含まれている。
ツールの運用に慣れれば、自然に開発者のスキルも上がる。

それらのツールをまとめたものが、プロジェクト管理サーバーと言う概念。
実際の開発プロセスはチケット駆動開発(TiDD：Ticket Driven Development)。

その運用プロセスを一つの開発プロセスへ昇華できないか？

おそらく、その開発プロセスは、ハンフリーのPSPやTSPに似た開発プロセスになるのではないか？

Personal Software Prcess

Team Software Prcess

プロジェクト管理やテスト工程をクラウド化する

Hudsonの下記記事を読んだ感想をメモ書き。

【元ネタ】
Hudson Selenium PluginでHudsonクラスタをSelenium Gridに - 川口耕介の日記

近年、HadoopやSeleniumなど、複数のサーバ上で動作する事が前提のツールが増えてきており、マルチコア化・クラウド絡みで、このトレンドは今後も続くと予想されます。
ところが、こういったツールはセットアップと運用保守に手間がかかるという欠点があります。
Hudsonで僕がやろうと思っている事の一つは、Hudsonのクラスタ上にこういったツールをインストールするのを簡単にすることです。
Hudsonのクラスタはインストールがとても簡単ですし、プラグインのインストールも容易なので、この環境の上に他のツールをオーバーレイすることで、手間なく様々なツールを利用できるようになります。

「ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」本にラストマイル問題という話がある。

※元ネタ
プログラマの思索: Antリファクタリングカタログ

長年、継続的に機能追加されて肥大化したシステムへいかにアジャイルにリリースできるか？という「ラストマイル」問題を提示している。

XPが提示したプラクティス「継続的インテグレーション」「テスト駆動開発」は、高速・高品質な開発を可能にした。
しかし、本番環境へのデプロイ＋リリースのプロセスではその恩恵がない、と。
理由は、3つある。
一つ目は本番環境は大変高価であり、二つ目は検証が複雑で、三つ目は検証の工数が大きすぎるからだ、と。

アジャイル開発の最終目標は「バージョンのないソフトウェア」を提供することにある、と。
つまり、仕様変更の要求が発生したら、それを開発して完成したら、すぐにリリースして本番稼動できることだ、と。

この問題は、アジャイル開発が目指す最終目標につながると思う。
アジャイル開発を実践することで、いわゆる下流工程は高速・高品質な運用が可能になった。
しかしながら、上流工程や上流工程を検証するテスト工程(結合～受入テスト)が大きなボトルネックとして浮き彫りになってきたように思う。

今の僕が考えていることは下記だ。
RedmineやTracを基盤としたチケット駆動開発によって、アジャイル開発のプロジェクト管理はIT化できるし、アジャイル化できる。
テスト駆動開発や継続的インテグレーションの恩恵をあまり受けないユーザテストでは、TestLinkというテスト管理ツールを入れることで、アジャイル開発の弱点を補えると思っている。

上記の3つのラストマイル問題には、僕なら下記のように回答する。

1.本番環境は大変高価で複雑であること

僕なら、VMWareで本番環境を仮想化して、複数の環境を作っておけばいいと思う。
これによって、いつでも仮想化された環境で本番検証できる。
更に、IEやFirefoxなどのWebブラウザのバージョンごとに仮想化されたクライアント環境も作れば、リリースしたWebシステムの動作を色んな観点で検証できるようになる。

普通は、本番環境は世界中に唯一つしかないSWプロジェクトが殆どだろう。
だから、本番リリースを一度失敗すると、非常に危険になる。

仮想化の技術はVMWareの普及と共に、急速に技術革新が起こっている。
上手に使いこなせれば、テスト工程の品質Upができるだろう。

注：下記のVMWareの記事が優れているので参考にしたらいいと思う。
VMwareとっておきの使い方 － ＠IT自分戦略研究所

2.検証が複雑で難しいこと

僕なら、TestLinkでユーザテストのテストケースを一括管理し、TestLinkとSeleniumを組み合わせて、ユーザテストを自動化してしまえばいいと思う。

XPはテスト駆動開発のプラクティスを導入したが、それは単体テスト工程で威力を発揮しても、結合テストや受入テストなどでは、うまく使いこなせなかった。
受入テストでは、テストケースが全ての要件をカバーしているかという要件カバレッジの観点の方がはるかに重要だからだ。

TestLinkを導入することで、テストケースの品質を上げることができるし、上流工程でテスト計画やテストケース作成などの作業も入れるW字モデルの開発も運用できるだろうと思う。

TestLinkの最新バージョンでは、XML-RPCのAPIが提供されているので、今後、TestLinkの操作でテスト自動化も可能になるだろう。

3.検証に手間がかかること

一つのシステムをリリースできる品質までに必要なテストケースを数えたことはあるだろうか？
単体テストから結合テスト、システムテスト、受入テストに必要なテストケース数は最低でも数千～数万の桁が必要だろう。
逆に言うと、それだけのテストをこなさなければ、システムの品質を保証できない。
すると、それだけのテスト工数をどうやって確保するのか、という話になってくる。

今までは、大量のテスターを動員して、Excel上でテストケースや進捗を管理するしかなかった。

僕なら、JUnitやSeleniumをビルドに含めて、複数のHudsonを走らせて、並行ビルドしてしまえばいいと思う。
数千～数万のテストケースを自動テストする時に、数百～数千台のサーバー上でHudsonを並行に走らせられれば、受入テストを大幅に効率化できるだろう。

上記のHudson記事のよれば、複数のハードウェア、複数のプロセスでビルド作業を走らせることができるようにHudsonは改良されているようだ。

この流れは、Googleが提唱したクラウド化と同じ。
安いハードウェアを湯水のように使い、マシンパワーに物を言わせて、システム開発を推し進めて、品質を確保する。

現時点では、Hudsonの機能もまだ不十分だろうが、じきに実現されるだろう。
VMWare、TestLink、Hudsonを使えば、更にプロジェクト管理をIT化できる。

もはやIT産業も、大量のメンバーを動員して開発する労働集約的なビジネススタイルが、そろそろ成り立たなくなりつつあるのではないか？
大量の資金を使って、設備投資で大量のサーバーを準備して、マシンパワーでSW開発を大幅に効率化させる。
その時に必要な技術は、Googleが編み出したMapReduceのように、並列プログラミング、関数型プログラミングなのだろう。

昨今のビジネスがITとは切っても切れないように、SW開発のプロジェクト管理もテスト工程もIT化して、クラウド化していくのではないか。

【告知】TestLinkでアジャイルにテストする

ETWest2009のTEF関西のコミュニティセッションでTestLinkについて話します。
TestLink＋アジャイル開発の運用経験を熱く語る予定です。

【概要】
名　　称 Embedded Technology West 2009／組込み総合技術展　関西
会　　期 2009年6月4日(木)、5日(金)　10:00～17:00
会　　場 インテックス大阪　5号館
大阪市住之江区南港北1-5-102 　TEL: 06-6612-8800

【内容】
2009年6月4日 (木) 12:30～14:30 6号館2F 会議室F
TEF関西勉強会　てふかん in ETW2009

13:40～14:30
TestLinkでアジャイルにテストする

【講演概要】
近年、システム開発のプロジェクトマネジメントが重視されるが、要件定義、設計、プログラミングまでの工程に注力する一方、開発工数の半分以上を占めるテスト工程が軽視される傾向にある。
これに対し、XPを代表とするアジャイル開発手法は単体テスト工程にテスト駆動開発を導入したが、結合テスト工程以降には適用し辛く品質保証が難しい。
本セッションでは、これらの問題に対し、テスト管理ツールTestLinkを効果的に運用した実例を体験談を交えて解説する。

Redmineの運用例その2

Redmine運用例の記事があったのでメモ。

【元ネタ】
[Think IT] 第2回：ProjectKeeperに見る開発方法論 （1/3）
[Think IT] 第2回：ProjectKeeperに見る開発方法論 （2/3）
[Think IT] 第3回：SIOS Applicationsの過去未来 （1/3）
[Think IT] 第3回：SIOS Applicationsの過去未来 （2/3）
[Think IT] 第3回：SIOS Applicationsの過去未来 （3/3）

【特徴】
プロジェクト管理ソフトウェアProjectKeeperのタスク管理にRedmineを使っているらしい。
WebSphere＋DB2で動作するから、IBM系列と思われる。
記事を読むと下記の運用ルールがあると思われる。

1・Redmineには、製品ロードマップ、顧客要望、バグ情報などが一元管理されている。
　変更管理/構成管理は、Excel＋CVSからRedmine＋Subversionへ移行した。

2・トラッカーは「要望」「機能拡張」「障害」の3種類がある。

3・「要望」はストーリーカードのような位置づけ。「承認済み」ステータスになると「機能追加」のチケットへタスク分割される。

4・「要望」は下記のステータスになる。
オープン→承認待ち→承認済み→対応中→対応済み

5・「機能拡張」「障害」は下記のステータスになる。
オープン→アサイン済み→開発中→確認アサイン済み→確認中→終了

6・全てのソース修正にはチケットを必要とするルールがある。

7・単体テストと結合テストのテストケースはTestLinkでテストケース、実施記録を一元管理している。

8・TestLinkを導入したが、担当者が手動でテストを実施している。テストの自動化はできていない。

興味深いのは、「要望」を要件管理、「機能追加」は実際の開発のタスク管理に使い分けていること。
しかも、要望のチケットが承認後に、タスクに当たる機能追加のチケットが作られていること。

ストーリーカードが決定されたタイミングで、タスクカードが作られる運用がされているようだ。
これは、RedmineのScrumプラグインと同じ機能だ。
この機能が実現されなければ、変更管理、要件管理を制御するのは非常に難しいだろう。

また、TestLinkも導入しているのが興味を惹く。
TestLinkを運用している利点の一つは、過去のテストケースを再利用しやすいこと。
どこまで運用されているのか分からないが、この利点が品質向上につながってるのだろう。

惜しむらくは、Redmineサマリが公開されていないこと。
Ruby1.8やSKIPのように、Redmineサマリが公開されていれば、そのチームの運用ルールは一目で分かる。

Redmineチケットの属性にあるトラッカー、カテゴリ、バージョンをどのように決めるか、という点は、まさにRedmineサマリという進捗報告のために存在すると言っても過言でない。

金曜にバグを発生させるコミットが多い

昨年7月のSEA関西プロセス分科会で教えてもらったソフトウェア工学の論文「When Do Changes Induce Fixes? (On Fridays.)」をもう一度読み直している。

プログラマの思索: ソフトウェア・リポジトリ・マイニング～Web2.0をソフトウェア工学に応用する

論文は、下記で公開されている。

【PDF1】
When Do Changes Induce Fixes? (On Fridays.)

【SlideShare】

When do changes induce fixes?

View more presentations from Thomas Zimmermann.

【PDF2】
Don’t Program on Fridays! How to Locate Fix-Inducing Changes

上記の論文の主張は「ApacheやEcipse(又はMozilla)プロジェクトでは、金曜にバグを発生させるコミットが多く、金曜はバグ修正のリスクが高い。金曜はプログラムを書くな！」というもの。
SlideShareでは、「Fridays are Risky, Tuesdays are not ;-) 」というタイトルもある。

すごく面白い。

今の自分のプロジェクトで、SVNリポジトリやTestLinkでメトリクスを出力しているのだが、上記の論文の主張が当てはまるような気がしている。

少なくとも、SVNコミットのピークが金曜の場合、そのプロジェクトで開発しているシステムの品質は経験的に良くない。
TestLinkに溜め込んだテスト実績から曜日別のテスト結果を出力すると、品質に問題があったテスト計画では、金曜にテスト実施数や失敗テストケース数のピークが来ているようだ。

理由を考えると、色んな諸条件でSW開発の生産性が低いため、学生症候群のように、週後半に作業のピークが来るように経験的に感じる。

こういうソフトウェア工学の知識を持っているだけでも、SW開発のリスク管理は大きく異なる。
こういう経験値をSW開発のプロジェクト管理、リスク管理に応用できないか？

そして、チケット駆動開発へ上記のようにSW工学の基盤を理論的に付与できないか？

変更管理の基盤は構成管理が支えている

SW開発には、たくさんの落とし穴や地雷がある。
地雷原を走り抜けてゴールにたどり着くまでに慎重に進むと、時間切れになる。

アジャイル開発をRedmine上で実践して気付いたことは、変更管理プロセスを制御できるかどうかという観点がプロジェクト管理の殆どを占めていることだ。
仕様変更、タスクの優先度など、SW開発は路線変更が多く、それを制御するのが難しい。
顧客と合意した要件で開発してリリースしても、その後に膨大な改善要望がくる時すらある。

以下メモ書き。

【1】顧客要求を安易に受けてしまう人の良いSE－ ＠IT自分戦略研究所

スコープのずれがコスト増にすぐにつながる。
アジャイル開発の肝はスコープ管理だ。
スコープ、コスト、納期の3つのバランスのうち、スコープでしか調整しづらいのがSW開発の最大の特徴。

スコープ管理の一例としては、CCBなどの変更管理会議で変更管理プロセスを制御することがある。
つまり、仕様変更など開発対象のスコープにつながるものは全て、顧客・SIer・開発者などのステークホルダーが全て集まって合意を経ないと、変更できないようにする。

しかし、僕の経験では、人数が多い会議ほど時間がかかるだけで何も決まらない。
CCBに出るステークホルダーは、業務やシステムに詳しい人とは限らない。
全員の合意を得るのは難しい。

大規模プロジェクトになるほど、ステークホルダーが増えるので、指数関数的に変更管理プロセスの難易度は上がる。
チケット駆動開発を応用しても、運用のハードルは高いだろう。

【2】【福井信二が語る：第3回】構成管理・プロジェクト管理の原理原則 - 組み込み開発 - Tech-On!

「構成管理とは同じ成果物の状態の変化を管理すること」というフレーズにアンテナが響いた。
SW開発では、一つの成果物が設計・開発・テストの工程を経るごとに、中身も状態も変化する。
記事で紹介されているように、成果物は段階的に詳細化されていくのだ。

要件は、設計工程で、システムの一つの仕様に落ちる。
そして、その仕様はプログラムで実装されて、初めて目の前で動く。
しかし、たくさんのテストをこなすたびに、一つの仕様には、たくさんのパッチが当てられて、ソースコードはどんどん複雑になっていく。

その過程を制御するのが構成管理だ。
つまり、要件からソースコードまで一貫したトレーサビリティを保証するインフラが構成管理。
しかし、Rational製品が提供するツールは重くて実用的ではない。

チケット駆動開発では、チケットとソースコードのリビジョンを紐づける運用がある。
その運用のおかげで、チケットという仕様に紐づくソースコードの履歴を辿ることができる。
逆に、ソースコードの変更履歴からチケットの仕様を探り出すこともできる。

僕が考えているプロジェクト管理サーバーでは、

HudsonビルドNo
→SVNリビジョン
→RedmineチケットNo
→TestLinkテストケースID
→TestLink要件ID

のトレーサビリティを作れるから、リリースされたモジュールにあるパッチから、要件まで辿ることができるはず。

上記の記事にあるベースラインの概念は、Redmineのバージョン、Subversionのリリースタグ、XPのイテレーション、Scrumのスプリントに相当するように運用できると思う。

変更管理と構成管理は密接に絡んでいる。
チケット駆動開発は、二つのプロセスをコントロールしやい開発プロセスだろうと思う。

Web2.0の本質はデータマイニングにあり

レコメンドエンジンの話を知りたくて、「集合知プログラミング」という本を買ってみた。
内容はいわゆるデータマイニング。
全て読めてないけど、すごく面白かったので、考えていることをメモ書き。
＃後でロジカルに書く。

【1】僕が「集合知プログラミング」を読んで思ったことは「Web2.0の本質はデータマイニングにあり」。

【元ネタ1】
プログラマーに最適なデータマイニングの教科書 『集合知プログラミング』 - 図書館情報学を学ぶ

集合知プログラミングが凄すぎる件について - プログラマになりたい

オープンソースのレコメンドエンジン　Taste - プログラマになりたい

オープンソースのレコメンドエンジン　Taste

Web2.0の成功例としては、Amazonの関連商品、iTunesのお勧め曲表示、はてなブックマーク、GoogleのpageLankによる検索エンジンなどがあげられるだろう。

これらの本質は、データマイニングにある。
売れた商品データ、売れた音楽データ、ネット上にあるリンク情報など、大量に溜まったトランザクションデータから、関連性のある情報を吸い取り、ユーザーに提示する手法。

この手法が面白いのは、一つは、プログラミングとマーケティングが直結すること。
もう一つは、プログラミングのアルゴリズムが面白いこと。

前者は、優れたプログラミング技術があれば、経営層や営業マンが気付かないマーケティング情報を数値で出力できること。
よく言われる例は「紙おむつとビールが良く売れる」というもの。
この手法が進むと、昔から言われていたエキスパートシステム、エージェント、人工知能につながるだろう。
今まで特別な人しかできないと思われていた高度なマネジメント手法を、誰でも手軽に使える可能性が広がるかもしれない。

後者は、大量のトランザクションデータを解析するには、それなりの数学的知識やコンピュータ科学を必要とすること。

いわゆるレコメンドエンジンのアルゴリズムは殆どは、協調フィルタリングと呼ばれるものだろう。
僕が理解している内容では、例えば、ユーザーIDとユーザーが購入した商品IDのハッシュマップをリストで保持し、複数のユーザのリストを並べて、色んな観点(アルゴリズム)で類似性を導き出すというもの。

このレコメンドエンジンのアーキテクチャは例えば、バッチ処理で売上データTblから類似性のある情報を計算して、フロント側にある画面からHTTP経由で、XML化された関連する商品データを取得するものが多いだろうと思う。
つまり、バッチ処理とWebサービスを組み合わせるやり方がレコメンドエンジンの殆どの実装方法と言えるだろうと思う。

このアーキテクチャにする理由は、一つは、大量の売上データを解析するのは時間がかかるため、バッチ処理の方が向いていること。
更に、Webサービス経由で関連商品情報を取得できるインターフェイスならば、他サブシステムからもHTTP経由で簡単にXMLを取得できるから。

でも、本来はバッチ処理ではなく、リアルタイムに計算できるようにしたい。
今はコンピュータ資源がいくらでもあるから、大規模分散計算のアルゴリズムMapReduceをフルに使えば、より質の高い情報をもっと速く提供できるのではないか？

技術的に面白いのは、リストで比較して類似性を計算する手法は、関数型言語と相性がいいこと。
HaskellとかScalaで実装できないのか？

オープンソースのレコメンドエンジンとしては、Tasteとかあるらしい。

【2】僕がデータマイニングを一番使いたい場面は、プロジェクト管理やSW工学だ。

【元ネタ2】
[Think IT] 第1回：エンピリカルソフトウェア工学を学ぶ前に (1/3)

森崎修司の「どうやってはかるの？」 エンピリカルとは : ITmedia オルタナティブ・ブログ

エンピリカルソフトウェア工学とは、エンピリカル：ソフトウェア工学への実証的アプローチ - nobusueの日記にもあるように、「"experimental"と"experienced"を合成したものだそうです。文字通り、「事実に基づくソフトウェア工学の構築」を目指したもので、ソフトウェア開発に対して科学的にアプローチしようという試みです」。

チケット駆動開発の仕掛けはBTS(バグ管理システム)にある。
データマイニングを使って、BTSに溜まった情報から、プロジェクトの進捗やシステムの品質に関するメトリクスを出力し、管理者が意思決定する情報として使いたいのだ。

丁度、経営者が毎月の売上データ、四半期ごとの決算書を予定・実績で比較検討した後に意思決定するように、チケット駆動開発のインフラであるBTSから出力された情報をプロジェクトのリスク管理として使いたい。
データマイニングの仕掛けは、協調フィルタリングではないだろうが、その発想は応用できるはずだ。

Redmineならば、サマリの画面で、トラッカー(チケットの種類)・担当者・バージョン(イテレーション又はマイルストーン)・カテゴリ(コンポーネント)などの観点でチケットのステータスを自動集計して表示する機能がある。
更に、ガントチャートやカレンダーをリアルタイムに出力できるし、そして、月別にバージョンで実績工数をクロス集計する機能もある。
これらの機能を使えば、プロジェクトの作業進捗やすぐに分かるし、そこからリスクを嗅ぎ取り、是正対策を取ることもできる。

statSVNというツールを使えば、Subversionリポジトリから、コミット日や開発者毎のLOCやコミット回数などを集計してくれる。
この結果から、システムのLOCがどのように増大しているか、開発者の貢献度は？などが分かる。

又、テスト管理ツールTestLinkを使えば、溜まったテスト実績から、テスト進捗や、バグの数からテスト工程の品質が分かる。
要件カバレッジの機能もあるから例えば、この要件はバグが多いので注意しよう、などの対策を取ることができる。

これらの手法をもっとお手軽に一つのパッケージとして提供できないか？

「集合知プログラミング」の本では、たくさんの例とたくさんのアルゴリズムがPythonで説明されている。
JavaやRubyに慣れている人ならば問題なく読めるのではないだろうか？
この本の読書会は開かれていないのかな？

TestLinkのテスト実績からメトリクス出力

TestLinkに溜まったテスト実績を下記ツールで分析してみたら、面白い傾向に色々気付いた。
以下メモ書き。

【EXCEL試験書からのXMLファイル変換マクロ】
v37b_TestLinkCnvMacro.tar.gz　ダウンロード - TestLinkTools - SourceForge.JP

【主な機能】

(中略)

６ テスト結果の統計データのエクスポート
・指定された期間のビルド単位の試験結果の推移をグラフ化できます。
・試験者を指定した試験結果の推移をグラフ化できます。
・試験結果の累計数は、各テストケースでの最後に実施した結果の累計数です。

７　要件カバレッジのエクスポート
・プロジェクト内の全要件のカバレッジを、EXCELシートに取込めます。
・要件カバレッジは、指定されたビルドの各テストケースでの最後に実施した結果より求めています。
・要件カバレッジは、要件にアサインされているテストケースの「成功」の割合です。

・仕様カバレッジは、要件仕様にアサインされているテストケースの「成功」の割合です。
・全仕様カバレッジは、全要件仕様にアサインされているテストケースの「成功」の割合です。
・これらは、要件仕様ないで重複してアサインされているテストケースを１個としてカバレッジを求めています。

８　要件カバレッジの統計データのエクスポート
・指定された期間のビルド単位の全要件仕様カバレッジの推移をグラフ化できます。
・要件仕様を指定した要件仕様カバレッジの推移をグラフ化できます。

９　時間帯別の試験結果の統計データのエクスポート　
・指定された日のビルド単位の時間帯別の試験結果をグラフ化できます。
・試験者を指定した時間帯別の試験結果をグラフ化できます。

１０　試験結果のピーク時間帯の統計データのエクスポート
・指定された期間のビルド単位の試験結果のピーク時間帯の推移をグラフ化。
・試験者を指定した試験結果のピーク時間帯の推移をグラフ化できます。

１１　曜日別の試験結果の統計データのエクスポート
・指定日または、指定期間のビルド単位の曜日別の試験結果をグラフ化できます。
・試験者を指定した曜日別の試験結果をグラフ化できます。

１２　時間当り実施数の統計データのエクスポート
・指定期間のビルド単位の時間当り実施数の推移をグラフ化できます。
・試験者を指定した時間当り実施数の推移をグラフ化できます。

１３　試験者別時間当り実施数データのエクスポート
・指定期間のビルド単位の試験者別時間当り実施数をグラフ化できます。
・指定した試験者の指定期間の時間当り実施数をグラフ化できます。

【感想】
【1】上記と似たものとして、SVNリポジトリから、コミット日単位でLOCを表示したり、開発者ごとに曜日・日時単位のコミット数などをHTML出力する下記ツール「statSVN」がある。
＃同様に、CVSリポジトリ統計出力するstatCVSもある。

StatSVN - Repository Statistics - Introduction

僕が重宝するのは、開発者ごとに曜日・日時単位のコミット数などを出力する下記の画面。

StatSVN - Repository Statistics - StatSVN Developers

上記ツールをクーロンで定時にHTML出力する運用をした所、下記の特徴があるという経験をした。

１・駄目なプロジェクト、生産性の低い開発者
・18時以降にコミット回数が多い。
　最悪なのは、夜中1時以降にコミットしている。
　つまり、低い生産性を残業でカバーしようとしている。
・コミット回数の山が金曜や土曜、日曜に来る。
　進捗の遅れを休日出勤でカバーしているから。

２・生産性の高いプロジェクト、開発者
・18時以降のコミットは殆ど無い。
・11時、17時にコミット回数の山が来る。
　おそらく昼前、退社前にコミットするから。
・コミット回数の山が水曜に来る。
　そうしないと、金曜までに作業が終わらない。
　休日出勤しないので、当然、土日はゼロ。

テスト工程も同様の特徴があるだろうと思う。
特に結合テストやシステムテストは元々、コストやスケジュールに余裕が無いので、１のパターンになりやすいと思う。

【2】時間帯別の試験結果グラフを見ると、品質があまり良くなかったテスト計画(イテレーション)では、納期前ほど18時以降にテストが多く、更に全般的に、18時以降のテストは失敗数が多い傾向があった。

又、曜日別の試験結果グラフを見ると、品質が良いテスト計画(イテレーション)では、火曜や水曜など週の前半に山が来る傾向があった。

理由を類推すると、テストケースをどんどん消化できる場合はそもそも18時以降まで残業してテストする必要はない。
テストが遅れると18時以降まで残業し、そこでバグを見つけてしまい、バタバタしてしまうから。
更に、バグを潰していっても、最後の一つのバグが納期直前までなかなか直せない場合が多かった。

逆に、テストケースを順調に消化できる場合は、午前中などで早めにバグを見つけて、18時までに解決しているパターンが多かった。
テスト進捗が順調だから、残業してまでテストする必要はない。

【3】statSVNでSVNリポジトリのコミットする時間帯・曜日別をいつも見る理由は、開発者やテスターの作業負荷を見たいから。

作業負荷が高まると、18時以降に残業してカバーするようになり、休日出勤でカバーするようになり、どんどん状況は悪化していく。

生産性の低さを残業や休日出勤でカバーしようとすると、月曜や火曜のような週の初めや、午前中などの早い勤務時間の生産性がすごく低くなる。
金曜の夜に進捗の遅れがあっても、土日でカバーすればいいや、という学生症候群が生まれてしまう。

そうなるまでに、現場リーダーとしては、対策を考えて手を打ちたい。
上記の資料があると、会社の上層部にも現状を説明しやすくなる。

【4】TestLinkのテスト計画をアジャイル開発のイテレーション単位に対応付ければ、イテレーションをこなすたびにテスト実績がたまっていく。
過去のテスト計画にあるテスト実績を上記マクロで、データマイニングして、メトリクス出力するのは非常に興味深く、又色んな気付きが得られる。

これは、Redmineによるチケット駆動開発でも同様。
ExcelではなくDBにあれば、好きなようにデータを集計して、色んな観点で、プロジェクトを分析できる。

TestLinkでテスト実績をためながら、上記マクロで出力したメトリクスをメンバー全員でKPTでふりかえり、プロセス改善できれば、強力だろう。

アジャイル開発とRedmine、TestLinkは非常に相性がいいと思う。

プロジェクト管理サーバーとは

僕が考えているプロジェクト管理サーバーについて良い記事があったのでメモ。

【プロジェクト管理サーバーのイメージ】
そろそろプロジェクト管理ツール群について一言言っておくか - Talking Nonstop

プロジェクト管理サーバーの目的は、SW開発で必要なインフラを提供することにある。

基本は、タスク管理(Redmine・Trac)とバージョン管理(Subversion)。
タスク管理の目的は、プロジェクト内部の作業全てを見える化して、一元管理すること。
RedmineやTracの運用の鍵は、タスクをチケットにどこまで分割して、アジャイル開発のイテレーションへどのように落とし込むか、という点にある。
つまり、分割したチケットをリリース単位にまとめて、小規模リリースできるか、という観点が大事。

バージョン管理の目的は、プロジェクト内部で発生する全ての成果物を一元管理すること。
バージョン管理の本質は、エディタのように成果物のUndo/Redoができることにある。
対象は、ソースコードだけでなく、ExcelやWordなどの仕様書やビルドスクリプトなども含まれる。
仕様書を「画面定義書_yyyyMMdd.xls」と書いている時点で、バージョン管理すべき対象なのだ。

そして、ビルド＆リリース管理のHudson。
ビルド作業やリリース作業は、ジョエルテストにもあるように、ワンクリックでビルドできてリリースできるべき。

TestLinkは、結合テスト以降のテスト、特に受入テストで使う。
僕の経験では、設計から、開発、単体テストまでの作業はRedmineのチケットで管理するが、リリース前の受入テストに入ると、TestLinkでテスト作業を一括管理する。
受入テストでは、テストケースの実施数が作業実績になるからだ。

他には、プロジェクト内部で出てくる業務用語や技術用語はMediaWikiで管理するとか、SVNリポジトリの統計を出力するstatSVNを使う。

他に試したいものは、HyperEstraierというMixiで使われているらしい検索エンジン。
Subversionにある成果物一式をいつでもWebで検索できるようにしたいから。
そうすれば、開発者自ら、仕様の不明点を探して、自力で設計書を作れるようになる。

【プロジェクト管理サーバーの作り方】
Vine Linux 4.2 で Trac + SVN + Hudson + TestLink 環境を簡単に構築するスクリプト - かおるんダイアリー

プロジェクト管理サーバーは、複数のオープンソースの管理ツール群を組み合わせたもの。
上記は、スクリプトで一式インストールする。
Trac + SVN + Hudson + TestLinkだけあれば、少なくともプロジェクト管理に困ることはあまりないだろう。
できれば、上記ツール群をVMwareイメージにしてくれると、初期設定込みになるから、より簡単になるだろう。

しかし、プロジェクト管理サーバーがあるからといって、それだけでプロジェクト管理が楽になるわけではない。
ツールに合わせた開発プロセスで運用する必要がある。
ツールの機能を十分に知り尽くして運用しなければ、逆に生産性が落ちることもあるだろう。

僕の経験では、プログラマやテスターは上記のツールにすぐに馴染んでくれて、プロセスを大幅に改善できた。
彼らは新し物好きだし、これらのツールによって、自分のタスクが見える化しただけでなく、自発的にバグをチケットへ登録するなど、自発的に作業するようになった。

しかし、従来のマネージャ職の人達がなかなか上記ツールに馴染んでくれない。
そもそもSubversionの使い方を知らなかったり、チケット駆動開発で現れるワークフロー管理、そしてアジャイル開発のタスク管理という概念に馴染んでいなかったりする。
どうやら、従来のExcelによるプロジェクト管理に固執しているみたい。

でも、僕は、プロジェクト管理サーバーは特にアジャイル開発のプロジェクト管理を補強してくれるはずと確信している。

アジャイル開発の弱点をプロジェクト管理サーバーが助ける

Redmine、TestLink、Hudsonなどの各種ツールを運用してみて、これらはアジャイル開発を補強するツール群なのだと直感した。
アイデアをメモ。

【元ネタ】
Redmine - Overview

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

Hudsonを使ったアジャイルな開発入門：第1回　Hudsonの導入｜gihyo.jp … 技術評論社

Perl製のソースコードレビューソフトウェア「Codestriker」

VMWareの開発でも利用されているソースコードレビュー共有ソフトウェア「Review Board」

【1】アジャイル開発の利点

XPを代表とするアジャイル開発の有用性は、昨今、色々知られてきた。
アジャイル開発の中で最も有名と思われるXPで最も重要なプラクティスは、小規模リリースだと思う。

小規模リリースとは、イテレーションという短いサイクルで小さく作りこんで小刻みにリリースしながら、システムを機能拡張し、品質を向上していくプロセスを指す。
緊急のバグ修正、突然の仕様変更に対しても、次のイテレーションに取り込む手法で、柔軟に対応していく。

小規模リリースのプラクティスは、メインラインモデルと呼ばれる構成管理と密接に関係する。
メインラインモデルとは、本番環境で稼働中のモジュールと、裏で新規開発中のモジュールの2つのコードラインを並行開発するソース管理手法。
メインラインモデルのおかげで、バグ修正のbranchと機能追加のtrunkの2つのコードラインを小刻みにバージョンアップしながら、品質保持と機能拡張という矛盾した開発スタイルを可能にする。

また、イテレーションは２～４週間のリリース単位でもあるから、一つのイテレーションで実装可能な機能の数は限られる。
従って、ストーリーカードのサイズはおのずと分割され、更に、優先順位付けされて、イテレーションに取り込まれていく。
つまり、高度なマネジメント手法を小規模リリースは必要とする。

又、イテレーションを一つずつリリースしていくうちに、ビルド作業やリリース作業の重大な欠陥、仕様漏れや要件漏れをすぐに判明でき、そのフィードバックをノウハウとして蓄積していく。
これがプロセス改善になり、ナレッジデータベースにつながる。

【2】アジャイル開発の弱点

しかしながら、アジャイル開発を実際の現場に運用するのは難しいと思う。

小規模リリースを実現するには、メインラインモデルと言う高度な構成管理手法を必要とする。
Subversionを骨の髄まで知り尽くしておかねばならない。

小規模リリースしていくには、どの機能をどのイテレーションでリリースしていくか、というイテレーション計画を作らねばならない。
しかし、イテレーション計画は、緊急のバグ修正や突発的な仕様変更に対応せざるを得ないため、頻繁に変わる。
だから、タスク漏れしないようなリアルタイムなタスク管理のインフラを必要とする。
Excelによるスケジュール管理だけでは、イテレーションを管理するのは非常に難しい。

また、XPが提唱する継続的インテグレーションを実現するには、ビルド作業やリリース作業を自動化することが大事。
継続的インテグレーションは、コードラインの品質を保証してくれる重要なプラクティス。
継続的インテグレーションが実現されなければ、回帰テストが難しくなるから、テスト駆動開発のメリットも半減する。

そして、プログラマがあまり重要視していないXPのプラクティスの一つである受入テストが、実は大きな弱点の一つだと考える。
テスト駆動開発は単体テストの観点で、品質を保証するだけ。
XPでは、結合テスト以降のシナリオベースのテストの観点がは弱い気がする。
特に、普通の受託開発では、結合テスト以降のテスト工程で開発人員が最大化するため、メンバーの管理だけでマネージャは忙しくなる。
受入テストの進捗管理や品質管理の観点が弱いと思う。

そして、ペアプロのプラクティスもその重要性や有用性が直感できるにも関わらず、実際の現場では根付かない。
ペアプロの本質は、レビュー工程の代替手段にある。
しかしながら、普通のSW開発では、レビュー工程が実は最大のボトルネックになっていると思う。
設計書のレビュー工程は、要件定義の代替プロセスと化しており、実際の設計の品質向上につながっていない。
実装のレビュー工程は、レビューワーが業務ロジックを知り尽くしていないから、単なるコーディングルールのチェックに過ぎない。
また、従来のレビューでは、複数人が大量の紙を印刷して持ち寄って、長時間議論して、紙ベースでレビューの記録を残すから、レビュー漏れが発生しやすい弱点がある。

【3】プロジェクト管理サーバーがアジャイル開発の弱点を助ける

僕が考えるプロジェクト管理サーバーの概念は、SW開発のプロジェクトを立ち上げる時に必要な構成管理ツール群が乗っているVMwareイメージをWebサーバー上で動かすことだ。
つまり、現場リーダーがSW開発を運営するのに必要な開発インフラが、プロジェクト管理サーバーの機能を持つWebサーバーであるイメージ。

Redmine、Tracでチケット駆動開発を実践することで、イテレーション計画を制御し、小規模リリースを実現するためのタスク管理の役割を担う。

メインラインモデルの実現は、SubversionあるいはGitなどのバージョン管理を使う。
もちろんソースだけでなく、ExcelやWordの仕様書もバージョン管理する。

AntやMavenなどのビルドツールと、CIツールHudsonを組み合わせて、ビルド管理やリリース管理を自動化する。

TestLinkで受入テスト工程を管理することで、テスト工程の進捗管理と、発生したバグ修正をRedmineのようなBTSと連携する。

また、コードレビューはコードレビューWebシステムで行う。
例えば、VMWareの開発でも利用されているソースコードレビュー共有ソフトウェアReviewBoardやPerl製のソースコードレビューソフトウェアCodestrikerなどを使ってみる。

これらのツールの最大の特徴は全てWebシステム上で実現されること。
Webシステムであることの利点は二つある。
一つは、いつでもどこでも誰でもアクセスさえすれば、必要な情報を取得できて更新できること。
もう一つは、実績や作業履歴がDBに残るため、データマイニングを使って、品質や進捗に関するメトリクスを簡単に出力できること。

特に、メトリクスを出力できることは、高度なマネジメントを行うのに決定的に有効だ。

昨今、テスト駆動開発やRuby on Railsなどのように下流工程で大幅な技術革新が生まれているのに、プロジェクト管理やテスト管理は10年前と同じようにExcelで手作業で集計するなど、上流工程でボトルネックになっていることが多くないだろうか？

プロジェクト管理サーバーを導入することで、SW開発のうちで特にプロジェクト管理の部分を強化してみよう。

All In One Redmineの作り方

Fedora10上でTestLinkとBugzillaのVMwareイメージがあったので、更にRedmineをインストールしてみたら、正常動作できた。
このVMイメージさえあれば、All In One Redmine(正しくは、All In One Redmine＋TestLink)として使える。

作成方法をメモ。

【必要なもの】
ダウンロードURL-Fedora7にTestLinkとBugzillaをインストールしたVMwareのイメージ-PukiWiki - TEF有志によるテスト管理システムTestLink日本語化プロジェクト

VMware Player

【戦略】
上記のFedora10には、既に下記がインストールされている。

Java 1.6.0_0(但しJREであってJDKではない)
php 5.2.6
perl 5.10.0
python 2.5.2
MySQL 5.0.67
Apache 2.2.0
Subversion 1.5.4
TestLink 1.7.4
Bugzilla 3.2rc1

故に、RubyやRedmineさえインストールすれば、殆どのツールが動く。
さっそくVMwareイメージにRedmineをインストールしてみる。

【前提条件】
1.VMPlayerをWindows上でインストール済み。
2.上記のFedora7にTestLinkとBugzillaをインストールしたVMwareのイメージをダウンロード済み。
※２Gあるので注意。

【作成手順】
1.上記のVMwareイメージを開く。
　ID・PWともtestlinkでログイン。
　更に、rootユーザ(パスワード:testlink)で入っておく。

2.Rubyをインストールする。
yum install ruby ruby-devel rdoc irb

ruby 1.8.6が設定される。

3.RubyGemsをインストールする。
yum install rubygems

rubyGems 1.3.1が設定される。

4.Redmineをダウンロードする。

wget http://rubyforge.org/frs/download.php/52944/redmine-0.8.2.tar.gz
tar zxvf redmine-0.8.2.tar.gz
mv redmine-0.8.2 redmine
chown -R testlink:testlink redmine
chmod 777 redmine

5.Railsをインストールする。
Redmine0.8.2は、Rails2.1.2が推奨のため、バージョンに注意する。

cd redmine
gem install rails -v=2.1.2

6.RedmineのDBを作る。

mysql -u root -p
create database redmine default charset='utf8';

7.Redmineの設定ファイルを修正する。

cd config
cp email.yml.example email.yml
cp database.yml.example database.yml
↓
mysqladmin -u root -p variable | grep socket
でソケットを探し、database.ymlのproduction部分へ
socket: /var/lib/mysq/mysql.sock
を追加

8.Railsのおまじないを実行する。

rake db:migrate RAILS_ENV="production"
rake load_default_data RAILS_ENV=production

9.Webrickを起動したら、、

ruby -Ku script/server -e production -d
※-dを付けるとデーモンになる
↓
http:localhost:3000
でRedmineの表示に成功！

10.ID・PW:adminでログインして、アカウントのリンク押下後、日本語を選択する。
すると、日本語が設定される。

以後は、ユーザを追加するなり、プロジェクトを作るなり、カスタマイズすればいい。

VMwareイメージはWindowsでもUnix上でも使えるから、上記のAll In One Redmineは、SW開発プロジェクトの立ち上げ時にそのまま使える。
何故なら、Redmineだけでなく、SubversionやTestLinkもあるため、SW構成管理の環境がほぼ揃っているからだ。
後は、JDKをインストールしてHudsonを入れたり、色々入れてみればいい。
僕としては、プロジェクト管理サーバーとしてAll In One Redmineを使いたかったから、すごくありがたい。

今後のプロジェクト管理は、Excelではなく、TracLightningやAll In One Redmineが主流になるのかもしれない。

テスト実績を見える化する

西山さん作成のTestLinkのExcelマクロがVer2.8へアップグレードしたので使った感想をメモ。

【元ネタ】
ニュース - EXCEL試験書からのXMLファイル変換マクロ(ver.2.8）をリリース　TEF有志によるテスト管理システムTestLink日本語化プロジェクト

【Ver2.8で追加された機能】
テスト結果の統計データのエクスポート　　

・指定された期間のビルド単位の試験結果の推移をグラフ化できます。
・試験者を指定した試験結果の推移をグラフ化できます。
・試験結果の累計数は、各テストケースでの最後に実施した結果の累計数です。

上記の機能のおかげで、TestLinkにたまったテスト結果をExportした後、上記のExcelマクロで取り込むと、実施日ごとに、試験数、成功数、失敗数、ブロック数の推移をグラフ化してくれる。

アジャイル開発とTestLinkを組み合わせた場合、TestLinkのテスト計画が一つのイテレーションに対応するように運用するだろう。
つまり、TestLinkのテスト計画にあるテストケース数百件～数千件を全て「成功」にしなければ、リリースできないようにする。
すると、システムをリリースする前に必ず、TestLinkのテスト計画の単位で、そのイテレーションの受入テストをクリアする運用になる。

この運用を開始してから、複数のテスト計画の実績がTestLinkにたまったわけだが、上記のマクロでグラフ化すると、受入テストでどれだけ苦労したかがすぐに分かる。

テスト計画の進捗グラフを見ると、例えば、最初はテストはスムーズで成功の件数が増えるが、ある時点から失敗とブロックが増えて、実質のテスト進捗が芳しくない時があった。
この場合は、バグが出ると、途端に関連するテストケースも失敗で更新されてしまい、そのシナリオに続くテストケースは、バグが直らないとテストできないので、ブロックにして保留にしていた。

あるいは、失敗やブロックの件数が増えても何とか潰して残り数ケースになったのに、全てのテストケースが完了するまで数日かかっている時もあった。
この場合は、バグを潰したものの、再テストすると又他のバグが出てしまい、なかなかテストが収束しない時だった。

そんな経験も踏まえて、リリース後にメンバーとKPTしたら、多くの気付きが得られるだろう。
また、複数のテスト計画をこのマクロできちんと分析すれば、テスト工数の見積の精度が高くなるだろう。

ただ、ここまでテスト実績が数値やグラフとして出力されると、テストの見える化を通り越して怖いと思うときがある。
もしTestLinkが開発チーム内部だけでなく、会社の上層部、あるいは、顧客と共有していたら、彼らは、テスト実績をこのマクロでテスト進捗をグラフ化するだろう。
すると、テストが遅れていたら、何故なんだ！対策は取っているのか！と開発チームに詰問してくるだろう。

TestLinkにたまったテスト実績には、たくさんのポテンシャルが秘められていると思う。

TestLink1.8 正式リリース！

ついにTestLink1.8が正式リリースされたというアナウンスがあった。

【元ネタ】
ニュース ～TestLink1.8.0正式リリース- TEF有志によるテスト管理システムTestLink日本語化プロジェクト

新機能の詳細はニュースを見て欲しいが、僕が一番気になる機能は、次の二つだ。

* (実験的に)GUIからのテスト自動化をサポート。
* テストを優先度を設定することが可能です。

前者は、PHPやRubyプログラムからXPL-RPC経由でTestLinkを操作できる機能(だと思う)。
この方法を使えば、TestLinkを受入テストで使うシナリオベースのテストケースだけでなく、JUnitのテストケースも入れて、テストの自動化を行うこともできる。

TestLink日本語分科会の人達のツールを使うと、Hudsonのビルド番号を取得してTestLinkのビルドへ設定する作業も自動化できるらしい。
つまり、TestLinkで回帰テストを自動化することが可能。

後者は、テストケースに優先度とマイルストーンを組み合わせて、テストの進捗を測定する機能。
実際のイメージは、川西さん提供の下記画像を見て欲しい。

【画像】TestLink 1.8RCにおける優先度ごとのテスト進捗結果

川西さんによると、下記の説明になる。

TestLink 1.8では、テストケースに優先度を設定できるようになる予定です。 また、マイルストーンには、いつまでにどの優先度のテストを何% 完了させるかという目標が 入力できるようになります（今でも入力だけは出来ますが......）。

そうするとレポートにもこの情報が反映されて、各マイルストーンで目標が達成されたかどうかを表示させることができます。

以下の画像の例だと、マイルストーン「優先度中のテスト完了」（二段目）に対して、「優先度【高】のテスト100%完了」という目標を達成しているのでグリーン、「優先度【中】のテスト100%完了」という目標を達成しているのでレッド、になっていると思います。

# beta 3ではこの機能にまだバグが残ってしまっているようです。
この例だとマイルストーン「優先度高のテスト完了」の表示がおかしい......
正式版では直るでしょう。

この機能を上手に使えば、マイルストーン毎にテストの予定・実績の比較ができるため、テストの進捗報告で威力を発揮するだろう。

残念ながら、v1.8.0は日本語化が不十分なので、v1.8.1まで待った方が安全だろう。
とはいえ、早くTestLinkの新機能を使ってみたい。

チケット駆動開発はプロセス改善を含む

チケット駆動開発を運用してみて、チケット駆動開発と朝会・ふりかえりは相性がよいことに気付いた。
以下メモ書き。

【元ネタ】
朝会について - sakuramateo.

朝会のパターン：立ってるだけじゃないよ

プロジェクトファシリテーション実践編：朝会ガイド

初めてのプロジェクトリーダー（6）
「ふりかえり」でプロジェクトを改善する

オブジェクト倶楽部の「プロジェクトファシリテーション 実践編 ふりかえりガイド」

【1】駄目な開発チームは、コミュニケーションが無い。

例えば、開発者はPCに座ったまま、一言も喋らずに黙々と作業するだけ。
設計から開発と単体テストまで順調であっても、結合テストで必ず火を噴く。

その時に、お互いのプログラムのインターフェイスが合っていないことが判明して、たくさんのバグが出て、そして収拾がつかなくなる。
責任のなすりあいに陥ったりする。

そういうチームは、フィードバックのプロセスが無い。
技術ノウハウや仕様のノウハウをためていくプロセス、問題を皆で解決していくプロセスが無い。

例えば、一人の開発者が問題を抱えている時、その問題を解決する作業をサポートする人がいない。
最終的には現場リーダーがサポートすべきだが、大規模プロジェクトほど数多くのメンバーを抱えて手一杯で、目が行き届かない。

フィードバックプロセスがあるチームは、コミュニケーションが活発。
一人のメンバーに問題が出ると、既に他のメンバーが解決方法を知っているならば、解決方法を共有することができる。
実装上の問題は、他のメンバーが既に解決方法を知っている場合は結構多い。

フィードバックプロセスの本質はプロセス改善。
つまり、プロセスは螺旋構造をなす。
問題解決の数をこなすほど、そのチームは成長していく。

【2】チケット駆動開発とプロジェクトファシリテーションのプラクティスである朝会・ふりかえりは相性がよいと思う。

朝会で最も大事なことは、各自が自分のタスクと役割を認識すること。
朝会が無いチームは、チームとしての一体感が無い。

ソフトウェア開発は、設計する人、プログラミングする人、テストする人、サーバーを構築する人など、色んな役割が必要。
その役割を各自が自覚して、チームとして成果物を出すことが大事。

朝会では、Redmineのロードマップ画面を見ながら、メンバー全員のタスクを確認する。
昨日の実績、今日やるべきタスクは、ロードマップやフィルタリングしたチケット一覧ですぐに分かる。
ロードマップ画面を見れば、チームの進捗が一目で分かるし、何が問題なのか、は一覧にあるチケットから分かる。
チームがイテレーションが終わる日までにタスクがどれだけ残っているか、という毎日の実績が一目で分かることは、チームがソフトウェア開発をコントロールできる自信につながる。

【3】ふりかえりで最も大事なことは、チームやメンバーが問題を解決する能力を保持し続けること。
ふりかえりが無いチームは、何度も同じようなミスを繰り返すから成長が無い。

リリース後にRedmineでサマリや工数レポート、リポジトリ統計、変更履歴などのチケット集計結果を見ながらKPTでふりかえる。

過去のイテレーションでリリースしたチケット数の差から、何故今回はこんなにチケットが多かったのか、どんな作業が多かったのか、などを自然にメンバーが考える雰囲気になる。
また、Redmineサマリ画面で、メンバーごとに起票数、担当数が変わるから、メンバーの貢献度合いも分かる。

僕がチケット駆動開発を運用してみて気付いたことは、Redmineのバージョンで区切られたイテレーションをリリースし終わった後に、自然に今回のリリース作業をふりかえる雰囲気が出てきたことだ。
どうやら、自分たちはこれだけのタスクをこなした、よく頑張ったぞ、みたいな雰囲気みたい。

チケット駆動開発では、チケットの種類に応じてステータスが異なるから、ワークフローをすごく意識する。
基本はバグ修正のフローで、開発者とテスト担当者が交互にチケットをやり取りする。
二人の目を通した成果物は少なくとも品質は確保できる。
つまり、XPのペアプロに似た作業をしているのに気付く。

すると、KPTしたら、メンバー毎のKeep・Problem・Tryの観点が大きく違ってくるのが面白い。
もし、今のワークフローではチケットをこなすのがやりにくかった、というProblemがあがったら、それについて皆で議論して、あるステータスを追加してみよう、などの解決方法に集約されて、Tryになっていく。

例えば、僕のチームでは、TestLinkによるバグ出しとバグ検証をRedmineチケットを紐付けた場合、どのように連携したらやりやすいか？というProblemがあがった。

つまり、Redmineのバグ修正のワークフローは「新規→担当→解決→終了」のため、TestLinkでバグ検証するステータスが無いから不便だ、という意見があがった。

結局、KPTを発端として議論した結果、「新規→担当→解決→検証中→検証完了→終了」のワークフローでTestLinkとRedmineをやり取りすることに落ち着いた。
そして、実際に運用した後のKPTでは、このワークフローで良かったという評価が得られた。

上記の経験は、チケット駆動開発を実践して、メンバー自らがワークフローを編み出し、プロセスを改善した事例の一つだと思う。

チケット駆動開発と朝会、ふりかえりを上手に組み合わせれば、開発プロセスの種類を増やせるし、色んな場面でワークフローを切り替える運用を開発チーム自身が学習する。
プロセス改善とは、そういうことも含むのだろうと思う。

見かけ上の進捗

【1】進捗報告のスタイルは色々あるだろうが、最も簡単な進捗報告は、完了ステータスと未完了ステータスの数値を先週・今週・来週で集計すること。

普通は、機能とステータスのクロス集計で、先週・今週・来週の数値を表示しているだろう。
この場合、「未着手→作成中→テスト中→レビュー中→完了」のワークフローにあるステータス毎に集計する。

前者と後者の違いは、実質の進捗と見かけ上の進捗の違い。
前者は、完了ステータスの数値＝実質の進捗。
後者は、未完了ステータスが「作成中」「作成中」「テスト中」「レビュー中」の4種類に更に分けて、見かけ上の進捗を集計している。

何故、後者のような見かけ上の進捗が必要なのか？
理由は、実質の進捗が芳しくない場合、開発チームが今どのような状態であるのか、を追跡したいからだ。

すると、部長クラスの人は、見かけ上の進捗の報告書を見て、ステータスごとの数値の差から、今チームがどんな状況なのか、を探るのが非常に巧みだ。
いわゆる計数管理が部長クラスの人は得意。

よくある例は、数少ないレビュー担当者とレビュースケジュールを調整できず、機能を実装してテストまで進むが、レビュー中で滞留してしまっている時がある。
この場合のボトルネックは、レビューの停滞だから、部長クラスの人は、レビュースケジュールを調整する対策を採ろうとする。

【2】Redmineのロードマップ画面では、バージョン毎の進捗バーが緑色と黄緑色の2色で表示される。
これは、緑色は実質の進捗、黄緑色は見かけ上の進捗を表す。

つまり、緑色は、ステータス＝終了のチケット累積数から実質の進捗を計算している。
逆に、黄緑色は、全チケットの進捗率から見かけ上の進捗を計算している。

だから、Redmineのロードマップを見れば、緑色が短く黄緑色が長ければ、完了間近の仕掛かり中の作業が多いのだろうと推測できる。

Tracのロードマップでは、実質の進捗しか表示しないため、開発チームの本当の進捗が分かりにくい弱点があると思う。

【3】同様にテスト工程でも、テストケース数が数千～数万以上の桁になるほど、実質の進捗と見かけ上の進捗による管理が重要になってくる。

TestLinkのテスト結果画面で「全ビルドステータス」画面では、「成功」「失敗」「ブロック」「未実行」のステータスごとにテストケースの進捗率を表示する。

テスト工程では、実質の進捗は、「成功」ステータスのテストケース数になる。
但し、「成功」テストケースは、1回目のテストで成功した場合だけでなく、1回以上失敗してバグ修正した後に成功になった場合も含まれる。

では、テスト工程の見かけ上の進捗とは何か？

テストの場合、テストケースの失敗が頻発した場合、いくらテストケースをこなしても、実質の進捗は進まない。
だから、テスト工程の進捗の本当の状態を知るには、「実施済み」のテストケース数を集計することが重要になる。

「全般的なテスト計画のメトリクス 」画面にある「完了率」は、実施済みのテストケース数の割合を表示していて、これが見かけ上のテスト進捗になる。
だから、実施済みのテストケース数が多くても、成功率が低ければ、バグが多いと予測できる。

【4】チケット駆動開発やTestLinkの利点は、見かけ上の進捗や実質の進捗を自動集計する機能があることだ。
RedmineやTestLinkでチケット管理やテスト管理の運用を徹底できれば、見かけ上の進捗や実質の進捗をリアルタイムにモニタリングできる。

進捗報告やテスト結果の数値から開発チームの状況や傾向を読み取る能力は、特に経営者に近い管理者は非常に得意だ。
チケット駆動開発やTestLinkの運用は、下流工程の構成管理だけでなく、プロジェクト管理全般の生産性向上にも非常に役立つはずだ。

TestLinkのテストケースを一括変換するマクロ

TestLinkのテストケースをローカルのExcelマクロで一括変換するツールが公開された。

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

v151a_TestLinkCnvMacro - TestLinkTools - SourceForge.JP

テストケース修正の流れ図の表示 - TestLinkTools - SourceForge.JP

そもそもの目的は、TestLinkに取り込んだテストケースを一括置換したい場合があること。
しかし、TestLinkにはテストケースの一部の文字列を一括置換する機能はない。
そこで、上記のExcelマクロを使うと、下記の手順で、テストケースを一括修正できる。

1.TestLinkから該当のテストスイートをXMLで出力する
↓
2.ExcelマクロへXMLをインポート(「caseToSheet 」シートで「XMLtoSheet」を実行)
↓
3.Excel上でテストケースを編集(テストケースIDは変更しない)
↓
4.ExcelマクロでXMLを出力(「caseToSheet 」シートで「MakeXML」を実行)
↓
5.TestLinkで"XML_CHANGE_testcase"としてXMLインポート

つまり、TestLinkにあるサーバー上のテストケースを一度ローカルに落とし、ローカル上で編集して、もう一度TestLinkへ上書きインポートする方法で実現する。

手間はかかるが、DBにあるテストケースをSQLで変更するのは危険だし、ローカルのExcelならば、一括置換に失敗しても、Undo＆Redoを何度でも試せる。

また、XMLを取り込んだローカルのExcelにあるテストケースはテストケースIDを必ず持ち、そのテストケースIDがTestLink上でユニークなので、テストスイートやテストケースの属性を好きなように後から変更できる。

更に、テストケースに紐づくキーワードも一括編集できるため、テスト実施中に仕様変更が生じて、要件とテストケースの紐づけも修正したい場合が発生しても、キーワードと要件の紐づけを修正すれば、いくらでも変更できる。
この変更で重要な点は、一括置換後にテストケースを取り込んだら、キーワード別テスト結果集計に要件カバレッジが即座に反映されることだ。

設計漏れや仕様変更によってテストケースの変更が、テスト実施中やテスト実施後であろうとも、TestLinkへリアルタイムに反映できるから、アジャイル開発と組み合わせれば、受入テストも楽になる。

まとめると、下記のイメージのようになる。

変換1：
v151a_TestLinkCnvMacroを使って、Excel→XML→TestLinkの順にテストケースをインポートする。
数千～数万のテストケースでも一括インポート可能。

変換2：
v151a_TestLinkCnvMacroを使って、TestLink→XML→Excelの順にテストケースをコンバートする。
このExcelは最終的には、納品用テスト仕様書になる。

TestLinkを使いこなせば、テスト工程をもっと楽にできるだろう。

TestLinkによる要件カバレッジ

TestLinkへテストケース、要件、テストケースと要件の紐づけの3種類をインポートするExcelマクロが公開された。
さっそく使ってみた感想をメモ。
＃作者の西山さん、ありがとうございます。

【元ネタ】
v10_TestLinkCnvMacro - TestLinkTools - SourceForge.JP

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

TestLinkTools運用の流れ図の表示 - TestLinkTools - SourceForge.JP

管理者の目的では、TestLinkを受入テストのテストケース管理として使いたい。
TestLinkのおかげで、テスト結果をリアルタイムにモニタリングできるため、進捗管理しやすくなる。
上記の要件カバレッジの機能があれば、どの要件は進捗が遅れているか、どの要件でバグがたくさん出ているか、を追跡することができる。

実際、バグが出る要件、テストが失敗しやすい要件は偏りがあるため、それらを数値として出力できることは、プロジェクトマネジメントの観点から非常に重要。

TestLinkで結合テストやシステムテストを代用する場合、数千～数万の桁のテストケースを作る必要がある。
それだけのテストケースをWeb上から逐一入力するのは手間がかかりすぎ。
そのため、上記のExcelマクロを使えば、数千～数万のテストケースも簡単に一括インポートできる。

上記のExcelマクロでは、要件とテストケースの紐付けデータもインポートできる。
すると、要件カバレッジをリアルタイムに見ることができる。

実際の画面キャプチャを見てみよう。

上記のExcelマクロでは、要件をテストケースの属性であるキーワードに紐づける。
この仕掛けのおかげで、テスト実行画面、テスト結果画面で、キーワードでフィルタリングすればよい。

テスト実行画面で、キーワードをフィルタリングした結果は下記の通り。

テスト担当者に使い方を聞いてみたら、アサイン＝自分、結果＝未実行でフィルタリングして、担当のテストケースを消化していくのが多いみたい。

テスト結果画面は下記の通り。
管理者はこの画面で、テスト結果をリアルタイムに進捗確認する。

テスト結果画面のキーワード別結果は下記の通り。
キーワードが要件に相当するため、どの要件で失敗ケース数が多いか、確認できる。

テスト結果画面の失敗したテストケース一覧は下記の通り。
最終的には、失敗テストケース数＝０にしなければリリースできない。
納期1ヶ月前に失敗テストケース数が50ケース以上ならば、おそらく納期までに間に合わないだろう。

テスト結果画面のバグ一覧は下記の通り。
「オープン」は未解決バグ数、「解決済み」は解決バグ数を表す。
最終的には、オープンのバグ数＝０にしなければリリースできない。

バグが50件以上ならば、システムの品質に問題があるだろう。
しかし、テストケース数が数千～数万の桁の場合、設計や単体テストの品質が良くなければ、バグは簡単に50件を超えるだろう。

TestLinkを運用して気付いたことは、テスト戦略の重要性だ。
数千～数万のテストケースのうちどれを優先してテストするか、バグが出た場合どのバグを優先して解決するか、という判断をいつも迫られる。
TestLinkは、管理者が考えるテスト戦略を見える化しているのだ。