テストの価値は
令和の時代に入り今ではソフトウェアテストという仕事、テストエンジニアという職業はそれなりに認知されてきていますが、
それこそ10年前は、
「テストエンジニアの価値がわからない(なぜテストに高いお金を出すのか)」
などと公然と(こちらがいる前で)発言する人もいたのです。
もしかしたら今でもいるかも知れませんが・・・
今回はそんな『テストの価値』について書いてみたいと思います。
テストの価値は不具合の数なのか
テストエンジニアの仕事は様々な目的があるにせよ一言で表すと、
『テスト対象の不具合を見つける』仕事になります。
ということは、不具合の検出数=テストの価値、という回答が出るのは自然かと思いますし、
実際にそれを指標にしているところもあるかも知れません。
しかし、それは一つの回答ではありますが全てではありません。
なぜなら、不具合の検出数はテストの技術だけで決まるものではないからです。
不具合数は、開発エンジニアのスキルや経験に依存します。
また、プロジェクトによっては不具合数が少ないものもあります。
例えば定期アップデートで更新箇所が少ない場合は、当然不具合も少なくなります。
「不具合数が少ないのであれば、テストエンジニアは不必要なのでは?」
の問いには明確にNo!と答えておきましょう。
なぜなら、テストをする目的には、
テストによって不具合を発見すること、だけでなく、
テストによって不具合がないことを証明する、こともあるからです。
但し、テストで不具合が未検出であることが、
ソフトウェアの欠陥がないことを示すわけではない点に注意が必要です。
これは『テストの7原則』の一つ、
『テストは欠陥があることは示せるが、欠陥がないことは示せない』
に当てはまります。
欠陥が完全にない、とは言えないまでも、少なくともテストによって確認した機能や条件では不具合がないため、リリースに問題ないと判断した、ということです。
また、不具合には数だけでなく質の問題もあります。
システムに大きな影響を与える不具合1件と、
システムの動作に全く影響を与えない、例えば表示に関する不具合が1件、
これは同列で語れませんよね。
話が少し散らかってしまいましたが、
要はテストを不具合だけで語るのは少し違う、ということです。
『真のテストの価値』とは
不具合の検出数だけで決めるとプロジェクトに依存してしまう、
また、数だけ上げればいいわけではない、となると何がテストの価値になるのでしょうか。
・・・実はこれは結構難しい問題で、一言これだ!という回答はないと思います。
中身のないテストの価値を決めることは簡単ですが、
真のテストの価値を決めるためのアクティビティがプロジェクトの最初に必要だと思います。
つまり、プロジェクトの目的が何なのか、誰に向けたものなのか、を知ることです。
例えばユーザーの満足度もテストの価値になり得ます。
開発プロジェクトとして、どのような機能を実装したいのか把握が必要です。
実装された機能が持つリスクを潰すこと、これもテストの価値になり得ます。
テストの価値は、テストエンジニアの成果ではなく、
テストによって誰かが得た利益から決めるべきだと私は思います。
ソフトウェアエンジニアリングで多くの著書を持つG・ワインバーグ氏は、
「品質は誰かにとっての価値である」と述べられています。
「テストも誰かにとっても価値でありたい」とは言えないでしょうか。
それでは今回はこのあたりで。
またお会いしましょう、HOLLYでした。
コメント
たーじん
元テストエンジニアですので、このコラムを読ませて頂いています。
テストの価値って難しいですね。残念ながら今でも「テストにコストをかけない」と言う考え方がほとんどだと思います。
また、稀に「バグが0になる方法は無いか」と質問や要望があり、説明に苦労するときがあります。
おたみ
そもそも私の職場には「テストエンジニア」に相当する役割すら存在しません。
開発者が自らテストケースを考えてテスト結果を報告する形ですね。
テストケースを上流側で承認するような考え方も根付いてないですし。
「実行時例外は握りつぶして、とにかくソフトが落ちないようにしろ」
という考え方が支配的です。
HOLLY
コメントありがとうございます。開発規模は大きくなる一方、市場リリースは早く、の中、テストは常にコストとの戦いになりますね。テスト=作業という考えだと効率化の話に終始しますが、テストが品質を作り出すという思考にプロジェクト全体が変わっていくとお客様との関係性も変わっていくかと思います。
HOLLY
コメントありがとうございます。テストチームがない職場というのはいまだに結構多いです。私が経験した現場でもテストチームがなく、それでも不具合はそこそこ少ないというのはありました。ただ、それは経験豊富な開発者がいたからでその方が定年などで去るに至って急に不具合が増えだした、何とかしてほしいというものです。こうした技術継承による品質劣化問題は今後も起きると思いますし、そもそも開発規模が大きくなればなるほど、一部の優秀な開発者がいたところで分担して開発している以上、システム単位での不具合を抑え込むのは難しいのではないかと思います。