よくある会話

「障害が起きました。すぐに調査してください。」
「わかりました。調査します。」
〜調査後〜
「この不具合が原因で障害が発生していました。申し訳ありません。」
「この障害で損失は発生しました。損害賠償請求させていただきます。」
「申し訳ありません。。。。」

エンジニアの恐怖の権化、「不具合」
上記の会話は誇張してますが、似たような恐怖に震えているエンジニアも少なくないでしょう。（えっ？誇張じゃない？）
そんな恐怖を減らすためにソフトウェアの不具合を出来る限り減らさなければいけません。
今回はそんなソフトウェアの不具合を減らすためにできる3つのことを挙げてみます。

ソフトウェアの不具合を減らすためにできる3つのこと

細かい手法はたくさんあると思いますが、大きく分けると三つになります。

• レビュー
• スクリプトテスト
• テストコード

レビュー

レビューは基本中の基本ですね。様々な成果物をチェックし、問題点や妥当性の確認を行います。
よくあるレビューの対象は

• 仕様書、設計書
• ソースコード
• テストケース

などなど。プロジェクトによって形は変わると思いますが、概ねここに集約されると思います。
それぞれレビューをするには知識や経験が必要になってきます。仕様書や設計書は何が正しいものなのか自分で持ってないといけないですし、ソースコードは技術的な知識も必要になってきます。テストケースは仕様書や設計書の理解を元に、様々な場面の観点を考える想定力が必要です。最近だとソースコードのレビューも自動化することができます。

スクリプトテストをする

スクリプトテストとは実際にプロダクトを動かして、動作を確認する原始的な方法です。設計書や仕様書を元に準備したテストケース（もちろんレビューしたもの）を実施し、期待通りの動作するかを確認していきます。細かな動作を確認する機能テストや運用やユースケースを想定したシナリオテストといったように様々視点でスクリプトテストする必要があります。

テストコードをかく

スクリプトテストでは手を動かしてテストを行いますが、それだと時間もかかり、確実性が低く、何より面倒です。
そこでテストコードを書くことで一部のテストを自動化していくことでみんな幸せになります。継続的にソースコードを管理する場合、非常に効果的です。

• ユニットテスト
• E2Eテスト
• テスト駆動開発

できるようになるために

これら三つを全部やり切るのは大変ですが、様々の制約条件の中でうまく組み合わせながら実践していきましょう。それぞれに必要な要素はありますが、一番は何が正しいか自分の中で持つことだと思ってます。たとえ仕様書があったとしても、それが全てであること絶対にありません。自ら考え、何が正しいのかを考える。もっといえばソフトウェアが誰に使われどんな価値があるのかを考える。これを考えられるようになるのが大変なんですけどね。私も勉強中です。