言語の歴史は人類の歴史。そして人類はコンピュータを言語で動かすようになった。

インフラエンジニアから見たテストの価値

»

HOLLYさんの書かれたコラムの内容を受けて、インフラエンジニアから見たテストについて書いてみます。開発の人のテストとインフラの人のテストでは、ちょっと視点が変わってきます。インフラの場合、テストエンジニアというテスト専門のエンジニアではなく、インフラエンジニアがテストを行う事が多いです。なので、検出したバグの数が価値を持つというより、最初からエラー0件が求められます。バグの検出というより、完璧さの証明としてテストが行われます。

テスト内容の傾向としては、一定数以上のテストケースをExcelの表に書き出して、全部通ればOKという感覚です。まず、このやり方に対しての私の意見は、「やりかたが雑すぎる」です。大事なのテストケースの数ではなく、バックボーンのロジックです。テストケースと要件との結び付けだとか、テストの意図などです。バックボーンのロジックを固めておけば、テストケースを障害時のチェックや障害対応の手順に転用できます。テスト結果をどう活用するかがテストの価値です。

テスト工程の事しか考えていないようなテストに価値は無いです。テスト結果にしても、出力されたデータやスクリーンショットを手順書に転用したりできます。それができないのは、テスト工程をクリアすることしか考えていないからです。バックボーンのロジックを固めて、他の工程に取得したデータを転用できてこそ、テストに価値があります。単に作業としてテストをしているのか、エンジニアとしてテストをしているかの分かれ目です。

どちらにせよ、想定するエラーは全部潰さないと先に進めません。その間の何が何件には大した意味は無いです。重要なのは、テストで何が起きたかです。正常に動いたにしても、エラーが起きたにしても、なぜそう動いたかを証明できるか否かが価値です。件数云々は、「こうあるべき」という理想です。そんな、誰かの理想通りに動くために本筋を見失っていては、テスト以前にエンジニアとしてそこにいる価値が疑われます。

そもそも、テストの価値というエンジニア視点で考える問題に、客の視点は必要無いと考えています。お客さんがテストケースの件数、エラー検出数云々というなら、話だけ合わせておけば十分です。何にどう価値があるかは、手を動かしているエンジニア主導で考えればいいことです。客の言う事に振り回されているようでは、どうやってもソフトウェアの品質なんて上がりません。何が価値かは、エンジニアなら自分の頭で考えて判断するべきです。

Comment(2)

コメント

てんるう

 本来は「要件定義」→「基本設計」→「詳細設計」→「テスト」の各項目が関連線で結びつくようになっていないとダメなんですよね。ここが「バックボーンのロジックを固める」を実現する仕組みになると思います。
 ただ、インフラだと「要件定義」「基本設計」が無いケースが多く、そのせいでまともなテストを作成する仕組みが崩れているのでは無いかと思います。

HOLLY

コラム読ませて頂いていましたが名前が出たので驚きました。
インフラエンジニアは経験がないので興味深く読ませて頂きました。
インフラならでは要求レベルの高さ、不具合1件の重さと向き合う現場の苦労が滲んで見えます‥

コメントを投稿する