エンジニアと障害対応の心得

自分のキャリアではWEB系とオープン系（クライアント・サーバのようなシステム）のエンジニアの経験しかないので、他のエンジニア職種の人がどうかはわかりませんが、おそらく障害対応は切っても切り離せない仕事と言えます。多分汎用機系もハードウェアの人も一緒じゃないかなと思っています。

ソフトウェア・テストの技法 | 近代科学社

何を持って不具合・バグとするのかという話から始まりますが、有名な「ソフトウェア・テストの技法」という書籍によると、大きく分けて設計バグと製造バグが有るということになります。すなわち設計する時点で考慮漏れしていたりというのが設計バグ、きちんと仕様書や設計も行ったのにプログラムが想定通りに動かないというのが製造バグとなります。基本的にはなにか入力、もしくは実行したら想定される出力になることを確認するのがテストです。この書籍は1980年のものなので今のWEBアプリ主流の世の中と照らし合わせて少し違和感がありますが、それでもいくつか参考になる考え方があるので紹介します。

テストはエラー（バグ）を発見するためのもの

これは普通の考え方と逆行するようですが、正しく動作することを確認するのかと思いきや、エラーになるパターンを見つけ出すという考え方になります。なので、例えば何度もブラウザをリロードしたらあるテーブルがどんどん更新されてしまったとか、そういったことを検知するのが正しいテストなんだそうです。ややこしいですね。

テストケースの必須条件は予想される出力または結果を定義しておくこと

何を持って正しく動いているのか判断材料がないとテストと言えないのは当然ですね。しかし、「何となく正しく動く」を仕様にしている現場が多いのが現状です。バイアスとも言えますが、システムに関わったことのないビジネス側の人にありがちなので気をつけたいところです。ブラウザにhttps://example.com とか入れて表示したら、AとBとCが表示されることみたいな一見当たり前に感じることも言語化しておくクセをつけるということですね。

プログラマーは自分自身のプログラムをテストしてはならない

これは誤解されそうですが、開発したら自ら動作確認は行うのですが、ここでいうテストはエラーが起きるパターンを見出すことなのでそこに関しては他の人の目で確認してもらおうという考えとなります。
そうなるとプログラマーとしては至極当然です。自分の思い込み、実装の手抜きや抜け漏れで発生するトラブルをあぶり出してもらうのは、他人のほうがやりやすいです。
昔、仕事していた職場で、上長に開発したもののテストをお願いしたところ、そんなの自分でやれよと言われたことがあります。上長はシステム的なことをやるのが苦手だったのだと思うのですが、正直ありえなかったです。とはいえ相手を慮って、ソフトウェアの質を上げるために第三者の目は必要と説得するのがいいと思います。

テストケースは正しい結果が得られるものだけでなく、不正な入力条件も考慮する

これは開発者にとっては普通なことなのですが、正常に動くパターンだけテストして終了ではなく、例えば存在しないページを表示しようとしたら404に飛ぶことを確認するのもテストケースで考えるということになります。

正直不具合をすべて洗い出して潰しこむのは不可能に近く、そこまでテストに工数や人員を充てる費用と時間に対するリターンが無いので適切な分量まで対応するという考え方が一般的には浸透していると思います。最近はどこの現場でも詳細なテスト項目書にテスト結果のエビデンスの提出まで求められるケースはありません。しかし、自分なりに制作物の品質に自信を持つためにある程度考えられる範囲のものはやっておいたほうがいいでしょう。

以前はすべて手操作で動作確認を行うことが主流でしたが、WEBアプリだとテストも自動化という考え方がかなり普及しています。弊社ではRailsアプリを作っているのでテストはRSpecというテストの仕組みを利用しています。こちらは個別のプログラムの部品の動作を確認するためのものです。またCapibaraという仕組みも利用してアプリケーションとしての振る舞いをテスト（E2E）するということも行っています。これをプログラムを公開（デプロイ）するたびに自動実行して全部通らなければリリースしないという形にしているので、手操作でテストするという面倒がありません。

基本的にシステム的な制作物はすべて自動でテストしたり、監視したり、極力人力を介さずに行うようにしようと考えています。作業内容の頻度とコストの見合いで考えていくのが筋で、ビジネス側の人にもこの考え方は理解してもらいたいと思っています。そうしないと何でも人力で行うのが、コストが掛からず正義のような思い込みをする方もいるためです。手運用のような作業をずっとやり続けるのは非効率ですが、システム的な考え方のできない管理職に取っては「頑張っている」と勘違いしてしまうことも多々あります。そうならないように日頃からエンジニアサイドは発信していくことが大事だと思っています。

とはいえ案件のプライオリティは不具合対応が最優先

別の話になりますが、開発タスクの優先度を決めるスクリーニングという作業があります。よく誤解があるのですが、ビジネス側の人がエンジニアに遠慮してしまうケースがあります。「これ不具合だと思うのだけど、話聞いてもらえるのかな？何か言い返されたりしないかな？」のようなケースです。
更には明らかに不具合なのに、今実行中の開発案件があるからと言って不具合対応を後回しにしてしまうことがあります。

これらはすべて間違いと言えます。与件はあらゆるところから発生しますが、不具合対応は現在実行中の開発案件があっても途中で止めて対応すべきです。そこに顧客がいる限りお客様最優先なのはどこも一緒なのです。エンジニアにもサービス精神は必要。なぜならお金をもらっているからです。

自戒の念のこめて・・・。