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

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

【元ネタ】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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