テストのキャプチャは必要なんですか

そう言えば、過去に言われたことありましたねぇ…。何度か。

初めてそういった問いかけがあった時には「必要です」と。あまり良い答えじゃないなと思ってはいました。

必要かどうか、で言えば、契約に書いてあるので必要だったんですが、形態的に聞かれたものが必要だったかどうかと言えば再考の余地はあったかもしれません。そこがそのときの引っかかり=学習ポイントだったのでした。

ときは過ぎて別のプロジェクトのときに、やっぱりテストのエビデンスが必要かどうかを問われました。

そのときのメンバの問いかけに対する回答は、

「テストの正当性を確認できれば変えても良いよ」

という言い方に変えました。成果物としての文書名称は決まっていましたが、テストのエビデンスの形態までは言及していなかったので、それはこちらからエビデンスはこれですと説明すればいいわけです。

#経緯的には一旦決めたものを変えますね、くらいの仕切りはしないとな、とは思っていました。

もちろん、テストの目的をかくにんできなければエビデンスにはなりませんけど。

結果的には、メンバ同士で代替策を考えたようですが、変えずに当初予定のエビデンスで行くことに。

変えてもいいんだということはメンバにとっては一つの驚きだったようです。

どうしてエビデンスが必要なの

ところで、テストのエビデンス、何に使っているんですか。みなさんのプロジェクトで。

そういった問い掛けってしたり、されたりすることないんじゃないですかね。なので訊きますよ。

 

何にテスト結果のエビデンスを使っているんですか。

どうしてエビデンスが必要なんですか。

ねぇ、ねぇ。

契約書に書いてあるから

 多分、ほとんど、契約書に記載されて成果物として出さないといけないから、くらいじゃないでしょうか。

それとも慣習で、でしょうか。

実際、何に使っているの

 じゃあ、テストのエビデンスを何に使っているんですか。

成果物として納めるとするなら、作業プロセスに入っていないとおかしいですが、テスト工程での作業プロセスにきちんとエビデンスの仕様について決めていますかね。

成果物として捉えていて、それが納める義務が契約上あって、とするなら作業の対象になるので工数も割り当てられるし、進捗も管理されるし、エビデンスの品質も検証されないとおかしいですけど。

してるんですかね。

エビデンスの使い道

 エビデンスの使い方、でも良いかも。パッと出てくるのがこの2つですね。

  1. 成果物
  2. 要件を満たしていることの確証

成果物はお金を払ってでも欲しいと顧客が要求するので業務ですね。エビデンスを作ること自体が。

でも、実際は、成果物の意味合いが作ることが慣習化し過ぎて、テストの進捗管理の1つのアイテムになっているきらいがあるのでありませんか。

実際の現場でエビデンスを作って集めるのは進捗の実績に成り代わっている、というわけです。

もちろん、品質管理に活かされることも皆無です。

そんなことをしていれば、テスト結果であるエビデンスは作りっぱなしになるのは当然の成り行きですね。だから、年度末納入などがあるようなプロジェクトでは、集めたときになんじゃこりゃとなるわけです。

 

2つ目はテスト目的を証明するための確証という位置付けです。要件がシステムに、コードに実装されていることをそのエビデンスで証明するために使われる。

第三者が来て監査されようが、確証としてのロジックを作ってあるのでこれ見てねと言えるものになっていないとマズイので。テストのエビデンスとしての要件を満たしていればいいので、何も画面キャプチャである必要もないわけです。

テストプロセスの観点

でどうエビデンスを扱うか。

それを考えましょう。

作業のプロセスはプロジェクトマネジメントの観点では、アウトプットを作る作業を定義すればいいのです。

ただ、テストでは直接的なものづくりはないです。作ったものに要件が充足されているかを検証するプロセスです。

その観点から言えば、テストでは、

  1. テスト仕様やテストコードを作るところ
  2. それをレビューするところ
  3. テストを実施するところ
  4. テスト結果を評価するところ

が主な作業です。エビデンスは3の副産物なのですよね。なのでキャプチャである必要は全くありません。

それよりは、テスト仕様の出来の方が重要です。作業プロセス的には1つ目をきっちり押さえておかないとやりなおしになってしまうので。

 

それで、あなたのプロジェクトのエビデンスはなんのために使っているんですかね。

 

テスト駆動開発

テスト駆動開発