第118回：　構成管理

≡ はじめに

「ASTERセミナー標準テキスト」の173ページについてです。

前回は、「テストサマリーレポート」について書きました。今回は、「構成管理」についてです。

「構成管理」は大切です。開発部門でしたら、Gitなどでソースコードを管理していると思いますが、テスト活動でも同様に大切です。ですので、キャッチイメージでも、箇条書きの1つ目が開発の成果物（テスト対象）の話で、2つ目がテストの成果物（テストウェア）の話が書いてあります。（2つ目の方では、プロセスの前後関係から、テスト対象とテストウェアの関連づけを行い、トレーサビリティを取ることが増えています）

■ 構成管理とは

管理すべき対象を決めて、管理対象についてバージョン違いを含めて識別できるようにしておき、更に、変更した箇所は変更履歴に記録し、管理対象間のトレーサビリティをとることを「構成管理」と言います。

「構成管理」は、このように【めちゃくちゃ大変な作業】です。まずは、この認識（片手間に行うようなタスクではないことの認識）を全員が持つことが必要と思っています。

最近になって、ようやく、「テストの自動化って、自動化した後のメンテナンスが大変で重要なんだよねえ」という事実が浸透してきましたが、「構成管理」にも似たところがあります。そして、この認識が甘いと、サービス残業やたまたまあいた時間でなんとかするようなことになりがちです。また、必要な構成管理が行われずに構成管理のメリットが受けられないばかりか、構成管理に関係する問題が頻出し、「なんで構成管理（という当たり前のこと）すら、できていないんだ」と上司に叱られます。
（当たり前のことではないからできていないのですけどね）

ということで、このnoteでは構成管理の考え方を中心に書きます。

Gitなどの構成管理ツールについては、環境によって様々な使いやすいツールが用意されています。逆にいうと、「自分の環境で便利なツールとその使い方は何？」という質問に答えられるのは、【その構成管理環境を構築した人】です。その人に「何のツール（群）を使ったら良いか」、「使い方を習得するためには何を勉強したら良いか」を聞くか、1時間程度の勉強会（ハンズオン）の開催をお願いすると良いと思います。
質疑を受けるのと勉強会を開くのと、どちらが良いかは構築した人の性格や仕事のスタイルによりますので、直接本人に聞いてみるほうが良いです。
（なお、教わったことは、もっと分かりやすくして情報展開するなど、自分ができることはしてくださいね。そうすれば、次回以降もスムーズに進みます）

≡ 構成管理の目的

構成管理の目的には2つあります。一つは「構成管理自体が目的」の場合です。もう一つは「構成管理を行うことで仕事を楽にすることが目的」の場合です。

以降で、それぞれについて書きます。

■ 構成管理自体が目的

一番わかりやすいのは、納品物として指定されている場合です。納品物ですので、応分の対価をいただきます。テスト関係のドキュメントであれば、ISO 標準(ISO/IEC/IEEE 29119-3　下図)の中から提供側はそれぞれについて値付けをしておき、お客様に決めていただきます。仕事ですから納品物であるところのドキュメントを粛々と作るとともに、きちんとバージョン管理や変更管理をするのは当然のことです。

こうすることで、例えば「テストケース仕様」を欲しい理由が「リリース後の運用保守を行う別会社の人が参照するため」といったことがわかります。これによって、「テストケース仕様」というドキュメントの用途が理解できるとともに、ドキュメントに対する【要求】がより明確になりますので、お客様側にとっても無駄な買い物となる可能性が低くなるメリットがあります。


※ お客様から、「作っているのが当たり前でしょう？」とか「わざわざ納品用に作り直すのではなく、あるものをそのまま納品してもらえれば良いから」といわれる場合がありますが、要警戒です。

お客様への納品物の他には、ISOやCMMiやAutomotive SPICEなどの認証を取る目的でドキュメントの構成管理をすることがあります。こちらも、仕事ですからドキュメントを粛々と作りましょう。内容はともかくとして、一通り、規格が要求する全てのドキュメントを用意して承認フローを回しましょう。

「認証取得が目的ではなく質の高いプロセスになっていることを確認した結果として認証が与えられる」というのは、その通りで、反論しにくいあるべき姿です。
確かに認証取得が目的だった1990年代と比較したら、現在は変わってきています。
それでも、認証取得のためにアセッサーに対して仕事の仕方や成果物を分かりやすく説明するタスクは必要です。また、認証の先にある、組織が達成すべき目標に対する活動の話は別にあります。
ですから、もちろん両者（実務と、認証に必要なドキュメント類）の重なりはできるだけ増やしますし、不正や虚偽報告を行わないのは当然ですが、認証を取得し更新し続けるのならそのために必要な仕事があることは忘れないでください。

■ 構成管理を行うことで仕事を楽にすることが目的

上の「全てのドキュメントを用意して承認フローを回す」を読んで、「ゲッ」っと思った人が多いと思います。「これだからQAは……」と思った人もいらっしゃるかもしれません。

「構成管理を行うことで仕事を楽にすることが目的」の場合は、「全てのドキュメントを用意して承認フローを回す」必要はありません。それは悪影響のほうが大きいです。
それはなぜか？　構成管理の定義を再掲します。

まず、管理すべき対象を決めて、対象はバージョン違いを含めて識別できるようにしておき、更に、変更した箇所は変更履歴に記録し、管理対象間のトレーサビリティをとることを「構成管理」と言っています。

このように【めちゃくちゃ大変な作業】だからです。こちらを完璧に守ろうとしたら、何か良いアイデアが浮かんだときに、テスト設計をし直すでしょうか？　「し直すよ。そんなこと当たり前でしょ」と言って、普通に厳密な構成管理を行っている組織も見てきました。しかし、普通は「大変な作業が待っていること」は、心理障壁となるものです。

「テストの7原則」の6つ目に「テストは状況次第」があります。どんなに大変であろうと構成管理をキッチリと行うことが必要な【状況】もあります。

でも、状況次第では、テスト観点ツリーをみんなで作ってテストのイメージを共有し、テストの実行は、テスト観点ツリーのノードを探索的テストのチャーターの代わりに使って進めるほうが良いことだってあります。

この場合は、テストウェアはテスト観点ツリーだけですので、構成管理の対象はテスト観点ツリーだけになります。手を抜いてサボっているのではなく、管理対象を減らすことで、先に述べた「何か良いアイデアが浮かんだら、すぐにテスト設計をし直す」や「テスト実行中の気づきをテスト観点ツリーに反映する」ことを促進するほうが大切なことだってあるのですから。

≡ 終わりに

今回は、「構成管理」について書きました。

分かりやすくするために、割と極端な話を書きました。しかし、現実には、多くのステークホルダーの要求が絡み合っていますのでベストの姿を見つけるのは大変なことです。コンサルティングをする中でも、この組織はベストに近い方法をされているなと思っても、本人たちは「まだまだ」と思っている人ばかりでした。

状況に合わせるばかりでなく、自分がしたいことを実現するために必要な前提を周り（開発など）に実現してもらうように働きかけるのもありだと思います。

テストの人たちは、控えめで受容力が高すぎると思うことのほうが多いですし。

さて、次回は「テスト仕様書」についてです。コンサルティングのときに「テスト仕様書を見せてください」と言うことが多いのですが、テスト計画書の添付にテストケース一覧が付属しているものが多いです。色々で面白いのですが、、、。