ソフト開発監査の目的その３：バグ修正版ソフトの品質を確認するための監査
重大な不具合対策版のリリース時には修正版ソフトの品質の確認に重点を置いてソフト開発監査を行う
ソフト開発の委託先に対して行うソフト開発監査の３つの目的、①開発の力量を判定する ②開発の力量を改善する ③不具合対策版ソフトの品質を確保する のうち、①と②について前の記事で概要を紹介しましたので、この記事では３つ目の不具合対策版ソフトの品質を確保するために行うソフト開発監査について紹介します。
不具合修正版ソフトの出来具合については、本来は設計・開発部門が開発委託先を指導して、十分な品質を確保しているはずです。しかし、重要な不具合対策版の場合には、設計・開発部門の活動と並行して、品質保証部門としても第三者の視点から開発委託先で作成された不具合修正版のソフトの出来具体について、ソフト開発監査で確認します。なお、実際のソフト開発監査についての具体的な紹介は、ソフト開発監査・実務 で始まるタイトルの記事にありますので、詳しい内容に興味のある方はそとらをご覧ください。
３．不具合対策版ソフトウエアの品質を確認したい
ソフト開発監査を実施する３つ目の目的は、不具合対策版のソフトの品質確認です。市場で不具合が発生した時に、不具合対策版のソフトをリリースして恒久対策を実施する場合が多いのですが、その不具合対策版のソフトが新たなバグを抱え込んでいては大変です。ですので、不具合対策版のソフトをリリースする前にソフト開発監査を行って充分な品質が確保されているかどうかを確認すます。
不具合対策版のソフトの品質を確認する事が目的ですので、監査で重視する点は他の２つの目的とは少し異なってきて、不具合の修正の内容とその影響範囲の確認やそれらに対するテストの状況確認が主体となります。具体的には、以下のような項目について確認をしていきます。
- 不具合が発生する仕組みは解明されていているか
- バグの修正方法は妥当か
- バグ修正の効果はテストで確認できているか
- バグ修正による影響範囲は適切に判定されているか
- バグ修正による二次不具合が無い事はテストで確認できているか
- 不具合が混入/流出した原因と再発防止策はできているか
これらの項目に関する確認は、開発委託先が作成した不具合についての報告書や、不具合箇所に関する設計書、不具合の修正に該当する箇所のソースコード、テスト結果等の資料を確認しながら進める事が多いです。ですので、このソフト開発監査では、ソフト開発監査のチェックリストを使わない場面も多いです。確認項目の最後にある原因と再発防止策の項目の確認の時に、開発プロセスに問題があった場合等には、開発プロセスに関するチェックリストの項目を使う事もありますが、チェックリストを使う比率はかなり低くなります。
それでは、各項目を順に見て行きましょう。
不具合が発生する仕組みは解明されているか
市場での不具合が発生した時にまず重要な事は、その不具合が発生する仕組みが明確に判っていて、対策のために正しいバグ修正が実施されているかどうか、という点です。
ソースコードに何等かのバグＡが潜在していて、ある条件Ｂが揃うとそのバグAを含むソースコードが実行されて、その結果状況Ｃが起きて、その結果処理Ｄに間違いＥが発生して、市場で不具合Ｆが発生する。というように不具合を引き起こすバグＡから、市場で発生した不具合Ｆまで、論理的に説明が付き、その発生の仕組みが間違っていない事を何等かの試験や調査で検証できているのか、注意深く確認します。
確認作業では、開発委託先の準備した不具合の発生原因に関する報告書や、該当箇所の設計書や、実際のソースコードを見ながら、その発生の仕組みに間違いや勘違いや論理の飛躍が無い事を確認します。
しかし、場合によっては発生の仕組みが判らない場合もあります。市場の不具合が開発部門で再現できず、調査が進まないとか、再現はするのだけど発生する場合と発生しない場合とがあって、発生する条件が絞り切れないなど、限られた時間と人員での調査ですので、限界も有り得ます。その様な場合には、この様な条件が揃った時に不具合が発生しているので、その条件が揃わない様な回避対策を対策として採用する場合もあります。発生の仕組みは、明確に判っているほうが良いのですが、現実問題としては回避策を取らざるを得ない事もあります。ただしその時でも、何が判って何が判っていないのか、事実に即して確認しておく事が必要です。
バグの修正方法は妥当か
不具合が発生する仕組みの確認の次は、修正方法の確認です。 ここは、バグとなったソースコードの間違いが、単なるコーディングミスなのか設計上の問題なのかに注意して、修正方法が問題ないかどうかを確認します。
単なるコーディングミスの場合は、そのミスを修正するだけなので割と安心です。しかし、設計上の問題が原因でソースコードの間違いが起こっていた場合には、設計まで遡っての修正が必要となります。この場合には、バグを修正するという行為は設計変更となるので、影響範囲の確認や修正による他への影響の有無等についても、良く確認しておく必要があります。
バグの発生の仕組みで判明したソースコードの間違いが、どんな原因で起きているのかに注意しながら、修正方法で確実に市場で起きている問題が対策できるのか、確認を行います。
バグ修正による効果はテストで確認できているか
バグ修正の方法が問題無い事の確認は机上検討と実機試験の２つの方法がありますが、まず最初に行うのに机上での検討になります。設計書やソースコードを見て、バグ修正方法に間違いが無いかを確認していく設計レビューに相当する作業です。机上検討で問題の無い事が確認できたら次には、そのバグ修正が実際に効果を出す事を検証するためのテストの結果を確認します。
ソフトエンジニアは、市場で発生した不具合を確実に再現できるテスト条件やテスト環境を揃えておき、そのテスト環境で不具合修正版のソフトウエアを実行して、確かに市場での不具合が起きなくなっている事をテストで確認しているはずです。テストで確認しているはずなのですが、ソフト開発監査ではそのテストの状況を再確認します。この時に注意する点は、不具合を再現できる環境を使って、不具合が起きなくなっている効果を確認できているかという点です。
なにか、禅問答のように聞こえますが結構重要な事です。 経験の浅いエンジニアの場合には、バグ修正を行ったソースコードが考えた通りに動作する事の確認だけで、修正の確認テストを終えたと誤解してしまう場合も有ります。 要するに、自分が修正した内容が、自分の考えた通りに動作している事を確認する、単体テストを実施してそれで良しとするという誤解です。
不具合の発生の仕組みが正しく解明されていれば、単体テストレベルの確認でも大丈夫なのですが、、、残念ながら不具合の調査も対策も、その内容を考えたのはソフトエンジニアという「人」です。 人は間違いも誤解も犯しますので、ここはやはり慎重を期して、市場不具合を再現する環境でテストを行い、バグ修正の結果が正しく効果を出す事が確認されているか、テスト結果を元に確認しておきましょう。
バグ修正による影響範囲は適切に判断されているか
バグの修正にはソースコードの一部の変更や追加が発生します。変更したソースコードは、既存の機能を実現するための処理や関数の一部分ですので、それらの処理や関数を使っているソースコード上の他の箇所が今回の修正による影響範囲です。
影響範囲を全て洗い出して、今回のバグの修正によるソースコードの変更が洗い出して置いた影響範囲の処理内容に何等かの影響を与えないか、もし影響を与えるならばその内容に問題が無いか、対策処理が必要なら対策処理が正しく実装されえいるか、等の視点で確認を行います。
バグ修正の時に一番注意する必要があるのがこの影響範囲の確認です。ここで見落としがあると、折角不具合修正版のソフトをリリースしたのに、そこに新たな不具合を入れてしまいまた別の問題を市場で引き起こしてしまった、、、というような事態に陥ります。
バグ修正による二次不具合が無い事はテストで確認できているか
ここまでくれば、もうゴールは近いです。最後に、影響範囲の机上検討の結果が問題無いかをテストで再確認しているかの確認です。今回の修正により影響を受ける可能性のある機能や処理が、修正前と同じように問題無く動作する事の確認テストは実施されているか。今回の修正の影響範囲の外にある機能や処理も、修正前と同じように問題無く動作するテストは実施されているか。の２つの点についてのテスト状況を確認します。
前者は、今回の修正の確認と合わせて実施される事が多いですが、後者の影響範囲外の動作確認は忘れられる場合もあります。机上検討では、影響範囲外なので問題は無いはずなのですが、少なくても基本的な機能が問題なく動く程度の軽いテストで良いので、テストをして確認しておきたいところです。組織によっては、そのようなテストをサニティテストと呼んでバグ修正の後に必ず実施する一連の基本機能テストと位置づけている事もあります。
不具合が混入/流出した原因と再発防止策はできているか
二次不具合の確認まで終われば、今回の不具合修正版ソフトの品質の確認は終了です。ソフト開発監査としてはここで終了しても構いません。
ただし、ソフト開発監査の別の面、開発委託先の開発力量を改善したいとう目的も少し織り込むのであれば、不具合がソースコードに混入してしまった根本原因や、不具合をリリース前に実施していた社内テストで事前に見つけられなかった流出の根本原因について、一歩踏み込んで解析してその再発防止策を開発委託先に検討してもらうのも、良いかもしれません。
不具合対策版のソフトの品質確認という目的からは少し外れるのですが、今後もそのソフト開発委託先に対して開発の委託が続くのであれば、もう少し手間暇をかけて、ソフト開発監査の２つ目の目的についても対策しておく事は、将来的にはメリットはあります。
次はソフト開発監査の対象という視点で紹介します
この記事では、ソフトの開発監査の目的を３つに分類して各々の目的毎に監査の概要について紹介してきましたが、いかがでしたでしょうか。 少しはグータラ親父のソフトウエア開発監査の概要が理解して頂けたでしょうか。 なにしろ、グータラ親父が勝手に作っている方法なので、まだまだ判り難い部分も多いとは思います。次の記事では、ソフト開発監査の概要に関して、監査の対象領域という視点でもう少し紹介を続けます。