リリース判定基準・テストの種類５つ目は過去不具合の確認
テストの種類の５つ目は過去不具合の確認状況
この一連の記事ではテストの品質を判定する時にどんな種類のテストをしているかという視点でテストの種類紹介しています。前の記事で紹介したバージョンアップ機能までは、そのソフトの機能や安定性を確認できているか、という視点でしたが、５つ目はこれまでの他のソフト開発での経験を活かしていますかという視点での、過去不具合の確認状況です。
これは、読んで字のとおりで判り易いですね。 過去に自社の製品が市場で起きソフトウエアに起因する問題が、今回の製品で起きないかをテストで確認しているますか？ という確認です。会社によっては過去問題を略して過去問とか、過去トラブルを略して過去トラとか呼ぶ事もありますが、言ってる事は同じで、過去に一度起こした事のある問題の再現テストです。
他の製品でのは過去不具合の確認は役に立つのか？
ところでそんな事をやって効果はあるのでしょうか？ 本当に同じ潜在問題が別の製品に潜んでいる事なんて、あるのでしょうか？ そもそもソフトはどれも一品物です。 ソフトウエアの構造も、使っているOSも、使っているミドルウエアも、動作するハードウエアも、使っている開発言語さえも製品毎に違っています。製品に大きな違いがあるのに、過去の製品で発生した不具合の再現テストを、今から出荷する製品でテストしているか確認する事に効果はあるのでしょうか？ 誰でも疑問に思いますよね。
確かに、ソフトは一品物でひとつとして同じ物はありません。派生開発や改造開発では基本となっている共通部分はありますが、それらに対して改造を加えた箇所は別物です。 同じ原因によるバグが潜んでいる可能性は少ないように思えます。
でも、全てのソフトには非常に重要な共通点があります。それはソフトを人が作っているという点です。ソフトの設計・実装・テストには、人の持つ思考能力を最大限に発揮して、高い集中力を維持して初めて可能な頭脳作業です。 そして残念ならが人は必ず間違いを犯します。
あなたのミスは私が既にやっている・・・
そして奇妙な事に、誰も同じような間違いを犯します。 ソフトの開発の世界に長く暮らしていると、あなたの犯した間違いは過去に私が犯した間違いと同じですね、という場面に多数出くわします。 もちろん、今回の問題を起こした技術者にとっては初めての間違いなのですが、じつは同じような間違いを他の人が以前に起こしていた、というのが殆どです。
まあもっと単純に言うと、組み込み系のソフトでは設計や実装で注意しないといけない箇所があって、初めてそのような箇所を設計・実装する事になったソフトエンジニアの大抵がミスをする落とし穴のような箇所があるのです。排他制御のデッドロックだったり、フラッシュメモリアクセスのタイムアウトだったり、状態遷移設計の遷移不可な状態だったり、動的資源のリークや２重解放だったり、優先順位の逆転だったり、予期しない時に起動するガベレージコレクションだったり、いつの間にか消えてしまうフラッシュメモリのデータだったり、、、長年組み込み系のソフトの世界で生きていると、同じようなバグに何度も出くわします。このあたりの設計・実装についての注意点については、バグの巣の記事で少しずつ紹介していく予定です。
そして、同じような設計・実装のミスで引き起こされるバグは、同じようなテストで見つけられる事が良くあります。その結果、新たに見つかったバグだけど過去に見たことのあるバグに似てるな～という場面がよくでてきます。という事は、過去に他の製品で発生したバグは、同じようなバグが今回の製品にも潜在しているリスクが比較的高いという事になります。
まあ、風が吹けば桶屋が儲かるの理論なので今ひとつ説得力は無い状態なのですが。 過去の不具合と類似の不具合を確認するというテストは、経験上潜在バグを見つける効率が良いので、グータラ親父過去問題の確認テストをしているか、という点をテスト品質の確認項目の１つとしていました。
テストの種類、次は過去不具合の確認状況です
テスト品質の良し悪しを判定する時に、実施したテストの種類をみるのですが、バージョンアップ機能のテストの次はテストの中での過去不具合の確認の状況です。 次の記事に紹介していますので興味のある方はご覧ください。