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リリース」などのように、後追いテストのテストケースを別途分けたり、リリース済みのテストケースを使ってデグレしないか確認するために回帰テストすればよいだろう。

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

ドキュメントも構成管理すべきだ

SVNで構成管理する時の良い記事が公開されたのでメモ。

【元ネタ】
Subversionで簡単・確実にファイルを構成管理 － ＠IT自分戦略研究所

SVNの使い方の記事はネット上にいくらでもある。
しかし、上記の記事で重要と思われる内容は、構成管理や変更管理の考え方を初心者向けに分かりやすく説明している点と、ドキュメント管理に構成管理の考え方を入れるべきだという主張だ。

CMMIの観点では、ソフトウェア構成管理は「変更管理を含むソフトウェアの構成を制御・管理できていること」と定義されている。
この考え方に基づくと、バージョンとは実はプロセスのベースラインを意味する。
つまり、リリース時にバージョン(又はタグ)を付けるタイミングは、開発者から顧客へ、あるいは営業チームから顧客へ、などのように、他者へ成果物を手渡すタイミングと同一なのだ。

構成管理が変更管理と密接に関係する理由は、上記のような変更プロセスを制御するインフラが構成管理だからだ。

そして、後者のように、ソースだけでなく設計書などのドキュメントも構成管理の配置下に置くべきだ。
理由は、ソースと同様に、ドキュメントを提出するタイミングでバージョン付けする状況が発生するからだ。

SVNはWindowsクライアントTortoiseSVNが非常に優れていて、ExcelやWordの差分表示もできる。
従って、変更理由の検索やマージ作業がやりやすくなる。

また、ロックと言う概念の説明も分かりやすい。
VisualSourceSafe6.0の頃は、VSSの管理下のファイルは全てロックされていたため、安全なように思われていたがむしろ作業に支障をきたす時が多かったように思う。
CVSやSVNのようにロックをかけないチェックアウトの方がやりやすいと思う。

また、trunk/branch/tagの説明も分かりやすい。
SVNが構成管理ツールの中で最も画期的だったのは、ブランチと言う概念を明示的に導入したことだと思う。

実は、昨今のシステム開発は殆どが、SWプロダクトラインのように、trunkとリリースブランチの2本以上による並行開発のはずだ。

例えば、組み込み製品やパッケージ製品の開発に従事する開発者ならば、製品ファミリーの開発を通じて並行開発には馴染みがあるだろうし、その苦労を嫌ほど分かっているだろう。
また、オープンソースで開発しているシステムの殆どは、障害修正だけの保守ブランチと最新機能をどんどん追加するtrunkの2本で開発しているだろう。
そして、昨今の業務系Webシステムでも、本番環境で動くリリースブランチと裏で機能拡張しているtrunkの2本で並行開発しているはずだ。

並行開発の難しさは、コードラインが2本あるためにタスク管理がより増大すること、そして、マージ作業が大変になる2点にあると思う。

そしてこの2点の問題を解決する糸口は、構成管理にあると直感している。
つまり、タスク管理はチケット駆動開発のように、BTSチケットに構成管理情報を付与してタスクを管理しやすくする。
マージ作業は、分散バージョン管理のようにマージ作業をツールで自動化する環境をサポートする。

構成管理はVSSやCVSの頃に比べるとはるかに高機能になり、それにつれて制御できるプロセスの範囲も広がってきた。
特に分散バージョン管理には、構成管理に新しい発想を取り入れているように思う。

構成管理という最も基本的な考え方をIT技術者だけでなく、PCに触る一般人も慣れた方がいいだろうと思う。

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つの実践ノウハウを説明します。

などその他。

チケット駆動開発のFAQ

チケット駆動開発についてのFAQをまとめてみた。

他に聞きたい質問があれば、コメントして下さい。
チケット駆動開発のFAQを集めれば、チケット駆動開発を普及させるのに役立つと思うから。

【元ネタ】
チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

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

RedmineとTracの機能比較: プログラマの思索

脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所

Tracのワークフロー: プログラマの思索

ワークフロー機能のカスタマイズ方法 - かおるんダイアリー

そろそろTracのワークフローについて語っておくか - almost nearly dead

チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索

TracからRedmineへ移行しない、たった一つの理由 - almost nearly dead

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

【プロジェクト】
【Q1】Redmineにある複数プロジェクト機能はどのように使えばいいですか？

【回答】
複数プロジェクトを使う目的は、タスク管理を分割統治する点にあります。
チケット駆動開発では、メンバーが5人以上のチームの場合、チケットが多すぎて管理が大変になります。
だから、チケットを管理しやすい範囲になるように、プロジェクトでタスク管理のスコープを分割します。

例えば、「大規模プロジェクトにおけるサブチーム単位」や「ブランチやtrunkのようなコードライン単位」、「warやjarなどのコンポーネント単位」でプロジェクトを作ればいいでしょう。

【Q2】大規模プロジェクトでもチケット駆動開発を運用できますか？　運用上の注意点はありますか？

【回答】はい、大規模プロジェクトでも運用できるはずです。(私も経験ないですが)

今考えられる注意点は、最低限、下記があげられるでしょう。

一つ目は、サブチーム単位でプロジェクトを作り、プロジェクト内部でタスク管理することです。
Q1のように、5人以下でタスク管理することを勧めます。

二つ目は、チケット管理専門の担当者を置くことです。彼の役割は、全てのプロジェクトのチケット管理の最終責任者です。
複数のプロジェクトをまたがったチケット管理は、彼が課題管理会議(CCB)の議長になって、チーム間の調整をすべきでしょう。
そして、課題管理会議(CCB)は最低、週1回は開催して、チケットの棚卸しをすべきでしょう。

【ワークフロー】
【Q3】RedmineやTracでは、課題管理や顧客の問合せ管理がやりにくいです。いい方法はありませんか？

【回答】RedmineやTracは本来は障害管理ツール(BTS)なので、バグ修正が基本フローです。
そのフローだけでSW開発の全ての作業を管理することは元々おかしいです。
課題や問合せ用のワークフローを作るべきでしょう。

Redmineなら、トラッカー(チケットの種類)ごとに新しいワークフローを簡単に作れます。
例えば課題ならば「新規→設計中→問合せ中→回答済み→解決→終了」のようなワークフローが考えられるでしょう。

Tracのワークフロー: プログラマの思索

Tracなら、trac.iniを修正してみて下さい。

ワークフロー機能のカスタマイズ方法 - かおるんダイアリー

そろそろTracのワークフローについて語っておくか - almost nearly dead

【チケット】
【Q4】チケットは仕様書ですか？　チケットには何を書くのですか？

【回答】チケットは仕様書ではありません。チケットにはタスク(作業又は課題)を記入します。
チケットにタスクとその履歴を記録することで、タスクのステータスや進捗率、実績工数を管理することができます。

つまり、チケットをXPのタスクカードをデジタル化したものと見なせば分かりやすいでしょう。

※従来のBTSを拡張した上記のような管理手法をIssue Trackingと呼ぶ場合もあります。

【Q5】チケットはどれくらい詳細に書くべきですか？　チケットの粒度はどのように決めたらいいでしょうか？

【回答】チケット駆動開発にある「チケットファースト」の原則に従うと、チケットは「一つの成果物を一人の担当者が１～５人日以内で完成させる作業」まで細分化します。

但し、バグ修正はテスターと開発者が相互にチケットをやり取りし合うように、複数人が一つのチケットを連携する場合もあります。
ワークフローによってチケットを変えましょう。

【Q6】チケットを乱発したり放置してしまいがちです。どのようにすればいいですか？

【回答】まず、チケット駆動開発では、チケットがいつも最新化されている状態が大事です。
チケットの内容が古いと、リアルタイムに保守されないExcelの進捗報告と何ら変わりありません。
現場リーダーがチケットを最新に保守する最終責任者です。

チケット駆動開発 - Live a meaningful Life

チケットが乱発されやすい理由は、チケット登録のルールが決められていないからでしょう。
最初は、現場リーダーがWBSに落としたタスクをチケットに登録することから始めればいいでしょう。
チケット登録できる権限をサブリーダーまでに制限したり、開発者がチケット登録できる種類はリファクタリングやバグのみに限る、などのルールを作ってもいいでしょう。

また、リリース時期が不明なチケットを登録したい時があります。
例えば、リスクや将来の課題という優先順位の低いチケットがあるでしょう。
このチケットは、「内部課題」という特別なイテレーションで管理するなど、優先順位の低いチケット群として別管理したらいいでしょう。

Redmineを使って気付いたことpart7～イテレーションで追跡する: プログラマの思索

また、チケットが放置されやすい理由は、チケットの粒度が大きい場合があります。
成果物が最初は不明なチケットの場合、あるいは、最初に登録したチケットが予定工数よりも大きくかかる場合、一人の担当者だけでは解決できないと後で分かる時はよくあります。
遅延したチケットは、更に分割して、複数人の開発者で担当するように運用すればいいでしょう。

Redmineを使って気づいたことpart3～チケット分割のタイミング: プログラマの思索

【イテレーション】
【Q7】Redmineではマイルストーンはどれですか？　マイルストーンとバージョンの違いは何ですか？

【回答】Redmineでは、マイルストーンとバージョンは同一の概念になります。
Tracの場合、マイルストーンとバージョンは異なる概念として存在します。

マイルストーンは進捗報告のタイミング、バージョンはリリースするタイミングと区別されます。
普通は、一つのバージョンに複数のマイルストーンが含まれる運用になるでしょう。

Redmineでは、リリースのタイミング(バージョン)とマイルストーン(開発の一つの区切り)を故意に同一視することで、XPのイテレーションのように扱えます。
これによって、Redmineの方がアジャイル開発を自然に運用できるようになります。

【Q8】チケット駆動開発をアジャイル開発のように使うには、どの点に気をつければいいですか？

【回答】「イテレーションをどの単位で扱うか？」が一番のポイントです。
Redmineならバージョン、TracならマイルストーンをXPのイテレーション、Scrumのスプリントのように扱えばよいでしょう。
普通は、イテレーションを２～４週間の単位で区切り、そのイテレーションでリリースできる機能にシステムを分割し、その機能を実装するチケットをイテレーション(バージョン又はマイルストーン)に登録します。

2番目のポイントは「小規模リリースを実現する」ことです。
つまり、一つのイテレーションに含まれるチケットが全て終了ステータスになったら、そのイテレーションをリリースし、終了チケットはリリース履歴として残す運用になります。

アジャイル開発の最大のポイントは、スコープ・工数・納期の三角形でプロジェクト管理を行うことです。
チケット駆動開発では、一つのイテレーションで実装できないチケットは、次のイテレーションへ延期するか、却下することで、スコープと工数・納期のバランスを取る戦略になります。

つまり、プロジェクト管理をチケットの取捨選択に置き換えることで、マネジメントを見える化しているのです。

【ソース管理】
【Q9】チケットとソースをリンクさせるにはどうすればいいですか？

【回答】Redmineでは、SVNコミットログに「refs」や「fixes」を付けると、チケットにソースのリビジョンが相互リンクされます。
この方法を徹底できると、運用保守で過去のチケットからパッチの理由を推測することができるので、リバースエンジニアリングしやすくなる利点があります。

この手法をチケット駆動開発は重視しており、提唱者のまちゅさんも「チケット無しの成果物のコミットは不可」というルールで呼んでいます。

チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

【Q10】RedmineではSVNコミットログにタグ(「refs」「fixes」)を付けると、チケットとソースが連携できると聞きました。「refs」と「fixes」の違いは何ですか？

【回答】Redmineでは「refs」を付けると、チケットとソースのリビジョンが単純に相互リンクされるだけです。
「fixes」を付けると、チケットとソースが相互リンクさせるだけでなく、リンク先のチケットのステータスを「解決」、進捗率を「100%」へ自動更新します。
つまり、「fixes」を使えば、SVNコミット後にチケットを更新する手間が省けます。

また、SVNコミットのタイミングで、バグを確実に修正できた場合は「fixes」、全機能は実装できていないが一部機能は実装できた場合は「refs」のように使い分けると、SVNコミットログからコミット履歴を検索しやすくなるでしょう。

【レポート】
【Q11】MSProjectの進捗管理とチケット駆動開発のタスク管理が連携しにくいです。何故でしょうか？

【回答】MSProjectとチケット駆動開発で進捗管理の視点が異なるからです。

つまり、MSProjectは顧客向けの進捗報告であり、管理者の視点で機能別、工程別に進捗を管理しますが、チケット駆動開発は開発チーム内部の進捗管理であり、開発者の視点で作業別、成果物ベースで管理しているからです。

すなわち、MSProjectはXPのストーリーカード、チケット駆動開発はXPのタスクカードの観点で進捗管理していると考えれば分かりやすいでしょう。

チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索

【Q12】毎月の工数を集計した顧客向けの月次報告をチケット駆動開発のツールから生成できますか？

【回答】Redmineは運用＋カスタマイズするしかありませんが、Tracならクエリを上手に使えば生成できるでしょう。

TracからRedmineへ移行しない、たった一つの理由 - almost nearly dead

基本的アイデアは、一つのストリーカードを複数のタスクカードに分割し、そのステータスと工数、開始・終了日をストーリーカードの単位で集計すればいいでしょう。

つまり、顧客価値に相当する要件(ストーリーカード)と成果物ベースの作業(タスクカード)を相互リンクさせる構造をチケット管理に取り込むのがポイントです。

チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索

アジャイル開発はツールに依存している～SW構成管理を再考しよう

アジャイル開発とSW構成管理に関する記事を見つけたのでメモ。

【元ネタ1】
Kent Beck VSTSのホワイトペーパーの日本語訳

(前略)
アジャイル開発はツールに依存します。特にツールが異なる開発サイクルに合わせて最適化されている場合は依存度が高くなります。
(中略)
アジャイル ソフトウェア開発は、ツールを抜きにして語ることはできません。俊敏なプロジェクトでは毎日の作業量が非常に多く、以前は手動で行われていた非常に多くの手順が短い期間で繰り返されるようになるため、適切なツールが不可欠です。
(中略)
アジャイル開発は既に開発ツールに影響を与えています。
(中略)
今後もソフトウェア ツールに影響を与える傾向は、絶えず短くなっているリリース サイクルです。
以前はリリースに数年かかっていましたが、ますます多くのソフトウェア製品の新機能が、月単位、週単位、日単位、またはさらに頻繁に運用環境にリリースされるようになっています。
各フェーズが順番に実行されることを暗に想定したツールは、並行した (非常にすばやく切り替わる) 作業をサポートするツールに取って代わられるでしょう。
作業間のより頻繁な移行をサポートしようとする傾向は、今後も続くことが予想されます。状況は大きく変化せず、サポートされる作業の数が増加します。
(後略)

短いイテレーションによる繰り返し型開発では、高度な管理ツールを必要とする。
従来の手作業によるプロジェクト管理、チマチマとしたExcelによるタスク管理では、アジャイル開発をいくらやりたくても実現できない。

頻繁なリリースに耐えうるプロジェクト管理手法こそ、チケット駆動開発が目指す開発スタイル。

アジャイル開発をサポートするツールは最終的に、作業の透明化を目指す。
つまり、誰がどんな機能を実装してコミットしたか、誰がどんな仕様変更や障害対応でパッチを当てたのか、という作業を、他人にも自分にも説明できるように明確化すること。

デスマーチ・プロジェクトや風通しの悪い大規模プロジェクトでは、誰が何の作業をしているのか、メンバーだけでなくリーダーも、トップの管理職も把握できていない。
特に大規模プロジェクトになるほど、進捗管理という名のマネジメント工数が大きくなる理由がそこにある。

その工数は本質的に無駄だ。
その作業を自動化できるなら、マネジメント工数も、そして進捗管理だけしか脳のないリーダーも不要になる。

この考えを推し進めると、優秀なプログラマと優秀なテスターがいれば、マネージャ無しで開発できるようになるはず。

【元ネタ2】
大規模組織のためのアジャイルな構成管理 : 1～9
大規模組織のためのアジャイルな構成管理 : 10～14

次に、「構成管理」について説明します。これは「品質」と同様に定義の難しい概念で、以前から複数の異なる定義が存在します*1。
構成管理とはシステム内の項目を識別し、特定の項目とシステム全体の両方に対して変更管理を行うことであるというのは、誰もが同意するところでしょう。
構成管理を極めて狭義に定義すれば、「一般的な任意のソース管理システムを実装し、適切に使用すること」を指します。
逆に、極めて緩やかに定義すれば、「プロジェクト・チーム全体とそのすべての成果物」を指します。
成果物には、システムのあらゆる部分の正常動作を保証するためのすべてのコードやアクティビティー、すべての変更管理アクティビティー、さらにはチームの日々の手順における変更追跡などが含まれます。
この記事では、中間的なアプローチを採用し、構成管理の定義として、システムの各部品を整理し、システムの状態を常に把握し、その変化を管理し、開発プロセス全体を通してシステムの継続的かつ正常な機能を保証するためにプログラマーが行う作業を含めることにします。

変化を制御するためにツールが必要。
構成管理は、変更管理のインフラを提供する。

XPが優れているのは、ソース共同所有・テスト駆動開発・継続的インテグレーション・小規模リリースなどのように、ソフトウェア開発のインフラの自動化に着目した点にある。
チケット駆動開発もその流れにあると言っていい。

アジャイル開発の構成管理において、今の僕が思っている課題は、ビルドの並行化。
テスト駆動開発を実践すると、全てのJUnitを走らせるだけで何時間もかかり、結局デイリービルドできない。

下記のように、JUnitでテストクラスを並列に実行できるならば、見かけ上のビルド時間は半減できるはずだ。

JUnit4でテストクラスの並列実行 - cactusman日誌

おそらく、Hudsonによる並行ビルドとVMWareによるテスト環境の仮想化をうまく兼ね合わせないと、最終的にこの課題は解決できないと思っている。

GitやMercurialのような分散バージョン管理、Hudsonによる並行ビルド、VMWareによる本番環境の仮想化などのように、構成管理の技術はまだ進化の途中。

昨今のアジャイラーは、プロジェクトファシリテーションのように、人間系・マネジメント系の方面に目が行きがちだが、構成管理という基本的な技術をもっと洗練させないといけないのではないか？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

色々試してみたい。

ソフトウェア開発はオーバーヘッドが大きい

ソフトウェア開発に従事して思うことは、色んな意味のオーバーヘッドが多いこと。

顧客の要望を聞いてから、設計してプログラムへ実装するのに結構時間がかかる。
顧客の要望を聞いた日から、実際に顧客がシステムを確認するまでに、かなり時間がかかる。

設計者と開発者、開発者とテスト担当者の間では、システムの理解度、業務の理解度に距離感があり、その差を埋めるためのコミュニケーションはかなりのオーバーヘッドが生じている。
実際、朝会やふりかえりはそのための時間なのだが、それ以外でもレビューなど、色んなコストがかかっている。

そして、「人月の神話―狼人間を撃つ銀の弾はない」の話のように、人を注ぎ込むほど、実は開発速度は上がらないという矛盾がある。
また、昨今のような短納期の開発では、開発者の出入りが激しく、チームビルディングが非常に難しくなっている。
ソフトウェア開発は、技術力のある人にすごく依存している。

ソフトウェア開発は製造業のように、リソースを注入すれば、生産性が劇的にアップするわけではない。
むしろ、破壊的イノベーションを奨励して、そのイノベーションから生じる技術革新の方がはるかに生産性が高くなる。

ソフトウェアはすごく繊細だ。
他の産業よりも、コミュニケーションコストがはるかに高いのではないか？

レビューやソースインスペクションだけでなく、ペア設計、ペアプログラミング、本番リリースをペア作業など、一緒に作業することは実は重要だ。
理由は、欠陥の防止だけでなく、システムの設計思想を共有しやすくするためにあるからだ。

二人による共同作業でコストがかかることを恐れてはいけない。

1回のリリースは100回のレビューに勝る

聞き伝手で、とある人の名文言をメモ。

１・「１回のリリースは、１００回のレビューに勝る」

SW開発は、要件がリリース直前まで確定されず、コロコロ変わる。
完璧なWBSそのものを作るのが難しい。

要件定義書や設計書を完璧に仕上げるよりも、早めにリリースして、顧客からフィードバックを受ける方がはるかに有意義な時が多い。

大規模プロジェクトほど、顧客と開発者の間の距離は遠くなり、伝言ゲームになりがち。
レビューで品質を上げるのも大事だが、早くリリースしてシステムを稼動させた方が、開発者自身も仕様の意味を理解しやすくなる。

但し、適当に仕上げてリリースしてしまえばいい、というわけではない。
小規模リリースのプラクティスに従って、スコープの範囲を絞り、イテレーション単位で小刻みにVerUpしていく戦略を採るのが重要だ。

２・「要求は数えられたら品質が上がる」

要件定義書は散文風に絵入りで渡される時が多いが、すごく使いづらい。
要件管理IDが振られた要件定義書があれば、そこから受入テストのテスト仕様書を作ることができる。

更には要件カバレッジが測定できるから、テストケースが全ての要件を網羅しているか、どの要件でバグが頻発しているか、を探ることができる。

そもそも、品質には機能、つまり要求の実現も含まれているのだ。

TortoiseHgでExcelの差分を見る方法

TortoiseHgでExcelの差分を見る方法を見つけたのでメモ。

【元ネタ】
スィンプロ (sinproject) Windows Vista 環境で TortoiseHG（Mercurial）を利用してバージョン管理とバックアップを行う (3)

WinMerge 日本語版

xdocdiff WinMerge Plugin -Word、Excel、PowerPoint、pdfの比較・差分を見る-

TortoiseHgで差分表示ツールにWinMergeを指定し、xdocdiff WinMerge Pluginを入れると、Word、Excel、PowerPoint、pdfをテキスト化した後に比較・差分表示してくれる。

このおかげで、TortoiseSVNと同様に、分散バージョン管理ツールTortoiseHgでも、ExcelやWordの仕様書の差分比較ができる。
実に素晴らしい。

最近思うのは、パソコンを使う人は全員、バージョン管理に慣れて欲しいことだ。
プログラムを扱うPGだけでなく、ExcelやWordの仕様書を扱うSEも同様だ。
更には、毎週・毎月の売上報告や請求書、納品書を扱う事務員、そして営業マンも、社長も全員、ドキュメントは全てバージョン管理して欲しい。

特に、複数人が更新する売上報告やプロジェクト別進捗報告は、更新履歴がないと、マージ漏れが発生しやすく、どのファイルが最新なのかすごく不安になる。

「契約書_yyyyMMdd_最新(コピー).xls」というファイルを見るたびに、バージョン管理があれば、こんなファイルを作る必要もないのに、と思ってしまう。

バージョン管理は最終的には構成管理という概念につながる。
特に、分散バージョン管理は、個人のファイル管理にも有用だ。

皆、早く慣れて欲しい。

チケット駆動開発に依頼や感謝の機能を表現させたい

面白いタスク管理サービスを見つけたのでメモ。

【元ネタ】
echo とは... | echo

echoもSaaS型のタスク管理サービスのようだ。
チケットをタスクセルと呼び、ワークフロー管理ができるようだ。

面白いと思った機能がある。

一つは、メンバーをキャストと呼び、何が依頼され、何を期待されているのかを意識させること。
チケット駆動開発を運用して馴染んでくると、チケットというタスクを他メンバーへ依頼する時が出てくる。
その時に、何を依頼して、どんな成果物を期待しているか、を伝えることが重要だ。

僕は、朝会で各自のタスクを確認し、チームのゴールに向けて、各メンバーの役割を伝えるようにしている。
ベテランでも新人でも、開発を終わらせるため、あるいは、結合テストを終わらせるために、タスクがアサインされ、彼ら自身の役割がプロジェクト内部で統一されている。

誰もがプロジェクトにとって必要な役割だ、と伝えるのは、モチベーションをアップさせる。

もう一つは、期待に応えてくれた仲間に感謝する機能があること。
echoでは、感謝のポイントを伝える機能があるらしい。
この機能は非常に面白いと思った。

誰かに依頼したチケットがとても良かった場合、そのメンバーを褒めたい気持ちが起きる時がある。
それは純粋に感謝の気持ち。

チケット駆動開発を僕が運用している時、自発的にチケット登録を奨励している。
開発者しか分からない、リファクタリングすべき怪しいソースはよくあるから、それらを優先度の低いチケットとして登録しておいて欲しいのだ。
そのチケットは、後に運用保守で工数見積もりする時に、非常に役立つ。
そのチケットを作った人を褒めておきたい気持ちがある。

但し、感謝の気持ちは、デスマーチのような余裕のないプロジェクトでは出てこないだろう。
デスマーチプロジェクトは、一部のヒーローとたくさんのIT土方しかいないから。

ニコニコカレンダーは、開発者自身の気持ちを表すカレンダーみたいなものだが、同様に、苦しい時に助けてくれた仲間に感謝したい気持ちを表現できる機能を、チケット駆動開発に導入できないだろうか？

IronRubyの行方

JRubyがJVM上のRuby環境のように、IronRubyは.NET上でのRuby環境だ。
それに関するメモ。

【元ネタ】
InfoQ: IronRuby -- 1.0までの道のり

荒井省三のBlog : IronRuby で Ruby on Rails を動かしてみました

IronRuby と RSpec の概要

[Ruby] IronRuby 動かしてみた (第一種臨界不測日記)

.NETでRuby開発を体験してみよう － ＠IT

(中略)
開発環境がそろってくれば、作業を効率化するためのスクリプト系のプログラムはRubyで素早く書き、業務アプリケーションのような堅固なプログラムはC#で慎重に書くというような使い分けが行えるのではないかと想像している。

IronRubyの利点は、Win32OLEとの相性の良さだろう。
.NET上でRubyプログラムが動くということは、ひいてはIIS上でRailsが動作するようになるだろう。

IronRubyもJRubyと同じく要注意だ。

TortoiseHgで日本語が使えるようになった

TortoiseHg0.8.1になって、ようやく日本語がほぼ使える状況になったのでメモ。

【元ネタ】
TortoiseHg / wiki / install ― bitbucket.org

Windowsにてwin32mbcsを有効にしてMercurial 1.3 を使うとエラーになります - mercurial-ja | Google グループ

gitやめてmercurialとtortoiseHGをインストール

TortoiseHg0.8.1に同梱されているMercurial 1.3.1で、win32mbcsが効くようになったらしい。
実際、パスやファイル名が日本語でも、コミットエラーが出なくなった。
メニューも日本語化されて使いやすくなった。
但し、日本語のダメ文字は使えないので注意。

また、Mercurialのオライリー本の日本語訳がPDFで公開されているのでメモ。
分散バージョン管理の特徴とその利点が書かれており、無料で読めるのはとても素晴らしい。

"Mercurial: The Definitive Guide" 日本語訳の公開CommentsAdd Star - 彷徨えるフジワラ

Linuxならば分散バージョン管理はGitで十分だろうが、WindowsではMercuiralの方が使いやすい。
その理由は、MercurialのWindowsクライアントTortoiseHgがあるからだ。

TortoiseHgはまだ開発途中なので品質や使い勝手に難点はあるが、Googleのサポートもあるから今後も発展していくだろう。

TortoiseSVNのように、WordやExcelの差分機能やBTSチケットとの連携機能が追加されれば、ソース管理だけでなく、設計書のバージョン管理もできるし、変更履歴をBTSから追跡することもできる。

今後の機能拡張を待ちたい。

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

チームビルディング～現場リーダーの必須技術

本屋で偶然見かけた本「チーム・ビルディング―人と人を「つなぐ」技法 (ファシリテーション・スキルズ)」をメモ。

昨年夏の北京五輪で、野球の日本代表チームがプロ野球から選りすぐられたメンバーを集めても、チームとして機能せず、メダルすら取れなかった。
いくら有能な人達がメンバーであっても、チームとして機能するには、それなりの技術を必要とする。

その技術がチームビルディング。
朝会、KPT、ふりかえりもチームビルディングの一環と捕らえる事もできる。

個人だけでなく組織が有機的に機能するには、人と人の間にある関係に注目し、その関係を活性化させなければならない。

チームであるからには、それぞれのメンバーに役割がある。
でも、メンバーは人間であるから、承認されたいという承認欲求、成長したいという野心がある。
メンバーだけでなく、チームも成長できるようにしたい。

重要な技術は、フィードバックとイノベーションだと直感的に思う。
些細であろうとも問題点は朝会やふりかえりで共有し、すぐに解決ないし対策を実行していく。
新しい技術をどんどん取り入れて試すという雰囲気作り。

チームビルディングは、今のIT業界の現場リーダーが意外に見落としている技術ではなかろうか？