見出し画像

テストの必要性と重要性

ソフトウェアテストの具体的なノウハウなどはJSTQB等、公式に拡散されているのでそれらを熟知すればおのずとわかっていくのだろうとは思いますが、そもそもソフトウェアテスト…いえ、モノづくりの世界において「作ったモノに対する検証・評価・保証」がどれほど大事かということを、実際にモノづくりにかかわる人たち(…その中には直接モノを作らない人も含めますが)はご存じでしょうか。

エンジニアであれば多くの人は「テスト」を

 つまんない

と思っていることでしょう。

実際、これまで1000…いえ2000人以上のエンジニアと一緒に仕事をしてきたり、教育してきたりを繰り返してきましたが、都度「やって一番楽しい工程は何?」「逆に一番つまらない工程は?」と聞いてきた中で確信したことです。

私自身も、社会人1~3年目くらいまではテストを楽しいとは思えませんでした。特に自分が作ったモノを確認するときは、むしろバグを検知してその修正をしているときのほうがよほど集中できていたと思います。

テスト工程といっても具体的な作業としてはいろいろありますが、チェックリストの作成やデータ作成、不良が発生した際の障害票などを起票することには嫌悪感すら持っている人もいるかもしれません。

クリエイティブな作業が好きな人ほど、こうした傾向は顕著に表れます。

しかし、テストは必要です。
必須と言っていいでしょう。

テストをしっかりできないエンジニアは、正確にはエンジニアとは呼びません。
なぜなら、自分が作り出すものに責任意識が持てないことを意味するからです。

個人的に楽しむ分には構いませんが、自らが作ったモノを社会に送り出し、あまつさえその作ったモノを提供することで対価を頂戴しようというのであれば当然そのモノの品質は提供された側の期待に応えられる程度でなければなりません。

でなければ対価をもらう資格がないからです。

たとえば、料理店のコックが食材のチェックも味見もしないで、きのみきのまま料理を作って高額な請求をしてくる上に「味が不味かった」「急な腹痛で倒れた」、最悪の場合「死に至った」…となってしまうとしたらみなさんならばどうしますか?

テストを「実施しない」「重要視しない」、期待されている質を「保証しない」というのはこれと同じことをソフトウェア開発で実現しようとしていることに他なりません。

さきほどチラっと挙がったJSTQB(Foundation Level)にあるシラバスでも「1.2 テストの必要性」のなかで挙げられているので気になる方は見てみるといいでしょう。

JSTQBとは、日本におけるソフトウェアテスト技術者資格認定の運営組織で、 各国のテスト技術者認定組織が参加しているISTQB(International Software Testing Qualifications Board)の加盟組織として2005年4月に認定されています。

日本国内のSIerをはじめとしたIT企業のなかではあまりテスト業務が重要視されていないのか、資格手当などの推進もほとんどされていませんし、資格取得に乗り気な経営層や管理職層というのは、私個人としては未だ見たことがありません。もちろん、導入している企業があることも一部知ってはいますが、直接お会いしたことはありません。少なくとも何千人と見てきたなかには一人もいませんでした。

海外でも有効なテストエンジニアのための資格であり、様々なテスト手法はもちろん品質のあるべき姿も一定の理解ができるようになっています。

品質保証を担う立場としても知っておいて損はない内容になってはいますが、どちらかと言うとテストエンジニアを含む開発に直接かかわる人たちが「どのようにテストを行えば品質が保証できるか?」に絞られた観点となっています。もしプロジェクト計画をプロジェクトマネージャー本人が担うのであれば、当然プロジェクトマネージャー自身も知っておいたほうがいいでしょう。そうでなければ、実現可能かつ効果的なテスト計画など立てられるはずもないからです。


そもそもテストがないと何が起こるのでしょう?

このことに理解が及ばなければモノづくりをする資格はまだないといっていいでしょうが、これは簡単ですよね。

問題(不良、欠陥)の見逃しが生じることで

 利用者やその周囲に不利益が生じる

からです。
具体的には

  • 時間の喪失

  • 金銭の喪失

  • 信頼/信用の低下

  • 傷害/死亡

などが発生することになります。

ITはすでに社会のいたるところに定着してしまいました。スマホ1つとってもITの塊です。家電製品も自動車もITなしには語れなくなってしまいました。ですから、それら製品が利用者の期待した通りの動作を行わなかった場合、どれだけの損失を生み出すことになるのか想像もつかなくなります。

もちろんガッカリされたり、残念がられたりします。
当然作った人も、使った人もうれしくない結果になることでしょう。

不満はいたるところで蔓延します。

そのうえ、今後開発してもらうことに対しても強い心配や不安を抱えられてしまうことになります。傷害や死亡事故などに発展すると、不信感どころではなくなってしまうことでしょう。

かといって正しくテストも行えないような組織では、ただただ人海戦術で何とかなると思い込んで無理に品質を向上させようとするIT企業がいまだに数多く存在しています。10年前、20年前にあったデスマーチ全盛時代と何も変わっていないのです。


個人的に、モノづくりを実施するにあたって本来「品質」とは

 向上させる(n→100%にする)ものではなく
 (100%を)維持するもの

と考えています。

仕様や設計が品質100%時の理想の姿だというのであれば、その状態となるように作り、その状態となるように作っていることを証明することがテストの本当の在り方だと考えるのは当然です。

仕様や設計がいかに100%の理想を示したものであっても、実装・製造の段階で70%までしか作ろうとせず、テストのなかで100%まで向上させていく…というものではないはずです。もしもそのような考え方を正というのであれば、テスト開始時点においては計画的に品質70%であることが正しいわけですから、テストの結果として

 「30%分の不良・欠陥が発見されました」
 「だから品質は低いんです」

という分析をすること自体がおかしいことになります。

そもそも不良や欠陥の混入を意図的に行うということ自体がおかしな話です。不完全な存在である人間の作るモノだから「このくらいは混入するかもしれない」という予測を立てることはあっても、それは「混入するべき」ものでもありませんし「混入してもいい」というものではありません。

品質上の下限値として、

その程度は混入しても仕方のないことだけど、混入率の結果とはまったく関係なく
テスト完了時にはすべての品質が100%であることを証明できるんだよね?

「テストがすべて完了したから」「不良・欠陥がすべて解消できたから」完了なのではなく、テストケースとしてすべての品質を保証できるだけの内容を論理的に網羅できているんだよね?

網羅できていないテストケースがいくら100%だとしても品質の保証にはならないことくらいわかってるよね?

が問われているということを理解できていなければどんなに"頑張って"も無意味です。

結局…品質の照明が行えるエンジニアがいなければ、いずれ市場からの撤退も余儀なくされるでしょう。

作る以上は

 良い(品質が100%であると証明できる)モノ以外作ってはならない!

のです。

 ・問題が起きない
 ・期待に合致している
 ・良いものを作る

といったこれらの要求事項を満たすことは必須です。

そのために、テストがあります。

テストは

 ・納品後リスクの低減
 ・システム品質の改善
 ・計測(&予測)による保証
 ・証拠の提示

等が行える非常に大事な仕事です。
欧米とりわけ訴訟の国アメリカでは日本とは異なり、品質の悪さから訴訟を起こされることも珍しくありません。簡単に何億、何十億という請求がまかり通ってしまいます。

そのため、日本のように「テスター」といって卑下されるようなこともなく、テストによって品質を担保できるエンジニア(テストエンジニア)は非常に重宝されています。ただのシステムエンジニアよりもはるかに良い待遇を与える企業も非常に多く存在しているといいます。

日本のSIerだけが、

 「新人に最初にやらせる仕事」

程度の解釈しか持たず、未だにテストエンジニアを軽視した文化を根強く持っているのです。だから43000社前後存在する日本国内のIT企業のなかでおそらく99%以上がテストエンジニアという肩書や役割も存在していないのではないでしょうか。


いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。