TestLinkを運用して気付いたことpart3～プロジェクト後半のプロジェクト管理はテスト戦略が大半

「ソフトウェアテスト293の鉄則」を読みながら、TestLinkを使って気付いたことを書き留めてみる。
＃ラフなメモ。論理的一貫性は後でまとめる。

【1】TestLinkを使う場面は、結合テストやシステムテストなど、シナリオベースのテスト工程。
このテスト工程は自動化できておらず、大量のテスターを動員してテストするのが普通だろう。

実は、プロジェクト後半のプロジェクト管理はテスト戦略が大半を占める。
理由は、二つあるだろう。

一つは、テスト工程はプロジェクト後半という時間とリソースの限られた状況があるため、バグが多発したら非常に制御しにくい。
もう一つは、結合テストやシステムテストのテストケース数は数千～数万の桁と膨大なので、どの機能を最優先でテストしてバグを潰すか、というテスト戦略無しでは、いつまで経ってもテストが終わらないだろう。

信頼度成長曲線の教える所によれば、ある程度のバグを出して修正して、初めて品質の歩溜りに達する。

しかし、SW開発の後半のテスト工程で、要件漏れや設計漏れが判明したり、突発的な仕様変更が来たりして、大きな修正工数が発生する時は多い。
テスト工程でバグを潰しているのに、大きな設計変更や仕様変更を盛り込んだら、バグの発生源が発散してしまい、品質を制御するのが非常に難しくなるだろう。

プロジェクト管理と言うと、進捗管理やコスト管理、要件定義、モデリング設計などをイメージするが、テスト戦略を作って実行し、そのプロセスを管理する重要性ははるかに高い。
現場リーダーは、テスト戦略の重要性を改めて認識すべきではないか。

【2】Redmine＋TestLinkを運用して、改めて、PLの采配は、いかに最小のテストケースで最大の品質を得るか、にある気がする。
限られたリソース、時間、人員でいかに最大の品質を確保するか。

でも、根本的に間違っているのではないか。

バグ０％を目指すならば、全てのテストケースを網羅してテストしなければならない。
でも、現実的には、テストケース数は爆発して、納期どころか有限の時間内でテストしきれない。

いかにテスト工程を手抜きして品質を確保するか、PLは躍起になっているのではなかろうか。
テストの自動化は解決の一つの手段にすぎない。
テストケース数が爆発したら結局、自動化しても全網羅は不可能。

ここで、アジャイル開発は、機能を分割して、小刻みにリリースしていくスタイル。
つまり、ユーザにとって重要な機能に重点を置いて、機能拡張し品質を確保する戦略を意識的に取る。

１００％網羅するテストは不可能だし、そもそも不要とアジャイル開発は割り切っていると思う。
特にXPは。

アジャイル開発の肝は、チケットの取捨選択、テスト戦略だと思う。
実現するチケットは、納期・スコープ(機能)・工数のバランスで優先順位が決まる。
優先順位の低いチケットは実装しなくていいし対応不要。

実装した機能のテストを優先して、まだ実装もされていない機能はテスト不要と割り切る。
優先順位の高いチケットを実装した機能のテストから始める。

Redmineを運用してみて、BTSの基本構造はチケット駆動開発(TiDD)だと確信する。
TestLinkは、Redmineと連携することで、テスト後のバグ修正で大きな威力を発揮する。

【3】「ソフトウェアテスト293の鉄則」を読みながら改めてテスト戦略やテスト手法について考えさせら得た。
僕が一番気になった鉄則は下記の通り。

2-1.バグの優先度と重要度を区別せよ。

テストで判明したバグは、まず、全て修正する必要はないことを改めて認識しておく。
バグが大量に発生したら、どのバグを最優先で修正していくか、優先順位付けするのが重要。
このバグは実は仕様通りです、という場面もあるから。

仕様はそもそも、お客様の要望の重要性と開発者の工数見積もりの間の認識で決まる。
バグも同様に、お客様の業務で重要な機能のバグを優先するだろうし、修正の工数見積が大きかったり影響が大きければ、慎重に修正するために工数を確保して実施する時もあるだろう。

バグの優先度をコントロールする役割を担う人がプロジェクトリーダー。

2-2.プロジェクト管理は機能、品質、時間、コストのトレードオフ。
　ウォーターフォール型開発は品質と時間が対立する。
　インクリメンタル型開発は機能と時間が対立する。

製造業では、QCDの三角形でマネジメントする。
SW開発では、機能・納期・コストの三角形でマネジメントするのが基本。

品質・納期・コストの三角形でSW開発を始めたら、品質を犠牲にせざるを得ない場面が必ず出てきて、その時にプロジェクトは崩壊へ一気に進むだろう。

ウォーターフォール型開発がSW開発に適用すると非常に危険なのは、そういう状況があるからだろう。
インクリメンタル型開発では、機能を小刻みにバージョンアップすることで、品質を確保しつつ、機能拡張していく。

メインラインモデルというバージョン管理のインフラがあれば、インクリメンタル型開発がやりやすくなると思う。

2-3.プロジェクトマネージャーは構成管理(と変更管理)の問題に気付け。

バグ修正で一番嫌なミスは、以前直したバグが再発するデグレードという現象だ。
コードが古く、パッチだらけのシステムなら、ソースを変更しにくいので、デグレの危険性が高いだろう。
コードがたとえ割と綺麗であっても、ドキュメントが揃っていても、デグレが発生する時もある。

デグレの共通の根本原因には、構成管理(訳注では変更管理も含むと書かれている)が貧弱だから、と指摘している。
この指摘は非常に鋭いと思う。

まずはソースコード管理とその運用について積極的に解決しない限り、直前のビルドで動いていた他の機能ももう一度確認する羽目になる。
XPの継続的インテグレーション、テストの自動化、のプラクティスを当てはめれば、大部分は解決できるだろう。

しかし、昨今のSW開発では、ITILの言う変更管理プロセスをどれだけコントロールできるか、という点が重要になってきたと思う。

バグを直すパッチを当てた時、他の機能が影響を受けないか、頭を巡らしているか？
開発者は、自分が作った機能しか詳しくないから、他の機能への影響まで考慮しない場合が多い。
だから、変更管理プロセスで、バグ修正の影響具合を設計の工程でコントロールできる能力をPLもSEもPGも必要とする。

この時に、チケット駆動開発のインフラがあれば、チケットに過去の変更理由が残っているため、影響調査が非常にやりやすくなる。
実際の追跡方法は、ソースのリビジョンからチケットを経由して変更理由を探すやり方だろう。

特に運用保守では、たとえバグがあろうとも稼動しているシステムの動作が正しいから、安易にパッチを当てると、バグ有りで運用していた顧客の業務まで変わる危険性がある。
だから、何故バグ有りになったのか、その理由を追跡する仕組みがあると非常にありがたい。

Redmine＋TestLinkはアジャイル開発のインフラを提供してくれる強力なツールだと強く思う。