[コラム] 品質確保のためにテストエビデンスの品質を向上させなさい

はじめに

みなさん、テストは好きですか？
システム開発では、避けて通れない「テスト」。

単体テストに始まり、結合テスト、システムテスト、運用テスト・・・
と、テストと呼ばれる工程は何回も発生します。もしかしたら、プロジェクトによって、システムテストや運用テストなどの呼び方は変わるかもしれませんが、根本的にやることは変わりません。

今回は、この避けては通れないテストについて、重要なことをお伝えしていきたいと思います。

そもそも、テストはなぜ行うのでしょうか？

「テストとは、プログラムを動かして、想定通り動いていることを確認する」

これに尽きます。はい、当たり前ですね。

ここで、１人でスマホアプリの開発をしている人を想定してみましょう。
１人で開発しているので、要件定義、設計、開発、リリース、品質管理、予算管理などすべて自分の責任範囲となります。

この場合、テストするとなったら、自分で必要そうなテストして、自分で確認して、リリースすればよいでしょう。

ただし、チームになってくると話が変わってきます。今日はその部分についてお伝えしていきます。

私のお話になりますが、前職で私は、コテコテのSIer企業のエンジニアでした。

よって、常にシステム開発を「する側」だったので、自分でテストしてそれをお客さんにレビューしてもらうという流れでした。

しかし、転職して一転、開発をベンダーに依頼する側となりました。
つまり、複数のベンダーに開発を依頼して、それぞれのベンダーのテストエビデンスをレビューする仕事をするようになったのです。

立場が180度変わったんですよね。

そして、ベンダーが作ってきたエビデンスをレビューしていく中で、わかってきたことがあります。それは、ベンダーによってエビデンスの質がまるで違うこと。

そして、テストエビデンスにおいて重要なことが、ほとんどのベンダーで実施できていません。

チーム開発しているときに、テストエビデンスで重要なことは何でしょう？

それは、「客観的に見て品質が担保できていることを確認する」です。そして誰がエビデンスを見ても問題ないことを確認できることです。

テストエビデンスを見ていると、以下のようなものが度々、散見されます。

これでは、テストエビデンスを読み解くのに時間がかかってしまいます。読み解けない場合には、テスト実施者に問い合わせが必要となり、その分のコミュニケーションに多くの時間が取られてしまいます。

そのような不毛なやりとりが何度も何度も続き、実施者・レビュー者ともに多くの時間が取られるし、ストレスも高くなるでしょう。

人がレビューしている限り、メンタルや体調によってレビューの質は変わってきます。安定した質を提供するためにも、なるべくストレスを低減したいものです。

もしかしたら、後半にレビューするものは、対して中身も確認せずに、レビューOKとしてしまい、バグを残してしまうリスクも上がります。

これでは本末転倒。品質を担保するためのレビューが実施できていませんね。

先に述べた通り、質の低いエビデンスは、実施者・レビュー者の双方で工数が膨大になってしまいます。

では、どのようなものが質の高いエビデンスとなるのでしょう？
答えは至ってシンプルです。それは、

“よそ者でもレビューできるエビデンスを作る”

です。
つまり、プロジェクトに参画していない人でも、レビューができるエビデンスを作ることです。

では、具体的にどのようなことをすればよいのでしょうか？
私なりに気を付けるべきポイントを次の通りにまとめました。

いかがでしょうか？それほど難しいことではありません。少し手間に思うところもあるかもしれませんが、この後発生するはずであった不毛なコミュニケーションがなくなると思えば、前向きに取り組めるのではないでしょうか。

また、質の高いエビデンスは、後々、見返してみたときも、容易に内容を理解でき、プログラムに問題がないことをすぐに確認できます。つまり、プログラムの品質が高いことの証明になりますね。

もし、原因究明が困難なバグが発生しても、質の高いエビデンスを作っていた人は、疑われることが少ないでしょう。そして、実際にバグも少ないはずです。

今回は、テストエビデンスに関するコラムでした。
「コーディングは楽しいけれど、テストはつまらない」といって、ついつい手を抜いたりしていないでしょうか？

誰もが見てわかるエビデンスは、質の高いエンジニアの証拠です。

ぜひ、質の高いエビデンスに取り組んでみてください！