ソフト開発監査チェックリスト（１６）テスト技術
テストのチェックリストの最後はテスト内容です
この記事では、ソフト開発監査に使う監査チェックリストの個々の項目についての紹介をしていきます。監査チェックリストは①開発プロセス ②要件管理 ③テスト ④設計と実装 に分かれていて、この記事では ③テスト の中のテスト内容を確認する個々のチェック項目について紹介します。（チェックリストそのものは ソフト監査実務・チェックリスト１４：開発技術・テスト（テスト管理・前半）の記事に載っていますので、そちらをご覧下さい）
テスト内容に関するチェックではテストの設計力を確認します
テスト内容についてのチェックリストを使う時には注意が必要です。それは、このチェックリストを使って確認したいのは、テスト内容が十分かどうかというテストの質ではなくて、テストを設計する設計力がどの程度あるかというテスト設計力の良し悪しだという点です。
ソフト開発監査の目的はソフト開発能力の良し悪しを判断する事で、その一環としてテストについてもチェックリストを使って確認しています。ですので、このチェックリストで確認したいのは、相手の組織のテスト設計力です。しかし、テスト設計力を測る良い方法がなかなか無いので、具体的なテスト項目を持ち出して、そのようなテスト項目に対して相手先の組織がどのように扱っているか、既に実施しているかこれから実施するか実施の必要性を感じていないか、等を元にしてテスト設計力を判断していきます。
個々のチェックリストの内容は他のチェックリストの項目に比べて具体的な内容になっているので、意識していないとチェックリストに書かれているテスト内容を実施しているかどうかの確認になってしまう場合があります。そうではなくて、ここに書かれているようなテスト項目について相手の組織がどう考えているのか、に注目してチェックを進めるように注意してください。それではチェックリストの項目を順番に紹介していきましょう。
【項目番号：TC-01】
単体テストはコード作成者が行う一番最初のテストなのですが、テストの目的やテストの方法等の単体テストの定義が、開発組織やソフトエンジニアによってかなりバラつきがでます。そのような単体テストの定義のバラつきの問題に気づいているかどうかは、単体テストの定義を明確にしてあるか、とかその定義を全てのエンジニアが正しく理解する仕組みがあるか、などについて実際の単体テストの様子を確認する事で見えてきます。その様な視点に注意して、単体テストの内容を聞いていきます。
【項目番号：TC-02】
単体テストのさらに具体的な方法まで立ち入ると、テストデータを洗い出すための方法やパステストの網羅性を評価する時の方法など、テストの一般的な技術として要否を選択する必要性が出てきます。どれを選ぶのが正解というのではありませんが、そのような具体的なテスト技術を知っていて、それを実際のテストに取り込んでいるかどうかは、テストの設計力を判断する時の１つの目安にもなります。 そのような観点に注意して確認していきます。
【項目番号：TC-03】
メモリリークは、本来の機能や性能の確認を目的としたテスト設計ではテスト項目として洗い出されません。安定性の確認を目的としたテスト設計を行った時に初めて、長時間の安定稼働を妨げる可能性のある原因としてメモリリークが洗い出されてきて、メモリリークの有無を確認するためのテスト項目が設計されます。ですので、メモリリークのテスト項目が存在して、そこにリークのテスト方法が具体的に書かれているならば、機能や性能だけではなく、安定性についてもテストの設計技量があると判断する事ができます。 そのような観点に注意して、確認をしていきます。
【項目番号：TC-04】
メモリのリークは割合有名なのでこのテスト項目がテストに含まれている場合も割合としては多いです。しかし、リークを起こすのはメモリだけではなく一般に動的資源と呼ばれるものです。一定の量がシステムで用意されていて、必要な時に必要なだけ使って使い終えたら返却する。この返却の処理がソフトのバグで実行されないと、その資源がリークしていきます。
そのような動的資源には、ＯＳが提供する資源としてソケットやメッセセージバッファがります。また、アプリケーションが内部にテーブルを持って、そのテーブルに対するデータの登録や削除を動的に実行するような仕組みを持っていると、これらのテーブルも動的資源なのでリークのリスクがあります。このように、メモリ以外の動的資源にまでリークが起きる事を推定して、それらのリークの有無を確認するテスト項目を設計できているかどかという点に注意して、確認していきます。
【項目番号：TC-05】
リークと同様にタイマやカウンタのラウンドアップ問題もまたソフトのバグとして有名です。タイマやカウンタはソフトウエアのいろいろな箇所で使われるものですが、ラウンドアップ時の処理がちゃんと作られていないとランドアップのタイミングで動作がおかしくなってしまいます。このバグは、実際にタイマやカウンタがランドアップするまでは起きないので、タイマやカウンタのラウンドアップ処理の確認を目的としたテスト項目でないと、バグを見つけられません。そのようなテスト項目の必要性に気づいていて、実際にテスト項目を作れているか、という点に注意して確認してきます。
【項目番号：TC-06】
タイマー問題の中でも、49日問題とか497日問題という固有の名前で呼ばれる問題があります。OSが持っているシステム時計のラウンドアップ問題が、49日や497日で起きる事からこのような名前で呼ばれるようになった物です。ですので、TC-05の確認項目と重複するのですが、TC-05 の一般的なタイマーのラウンドアップ問題には対応していなくても、有名な 49日問題や497日問題は知っていて対応している組織もあります。タイマーやカウンタのラウンドアップ問題と同様に49日問題や 497日問題というキーワードを認識しているか、その対策を行っているか、という点に注意して確認していきます。
【項目番号：TC-07】
リークやタイマ/カウンタのランドアップ問題は、バグがあっても不具合として問題が起きるまで長い時間が掛かるためテストで見つけにくい潜在バグです。同じようにテストで見つけにくい問題としてメモリ破壊のバグがあります。こちらはソフトが動作している時間には関係なく、処理のタイミングや重複で非常に稀な条件が整った時に発生する事が多いのと、実際に発生する不具合が一定でない事から再現性が低く、テストによる再現や原因の調査が難しいバグです。
実機のテストでは見難い問題は、ソースコードのレビューなどの机上検討の手段でバグを発見して修正するほうが、作業効率が良い場合が多いです。そのような実機でのテストでは見つけにくい潜在バグについて、コードレビューなどの机上検討の方法で見つけるような事を検討してあるか、という点に注意して確認していきます。
【項目番号：TC-08】
メモリでソケット等の他の資源でも、動的資源のリークと２重解放はコインの裏表の関係にあります。解放を忘れればリークが起き、１度解放したのをもう一度解放すると２重解放が起きます。資源を解放する処理が忘れられるとリーク、ダブルと２重解放です。という事は、リークのバグ＝資源の解放処理忘れを見つけて、資源の解放処理を追加すると、ある条件の元では２重解放が発生する別のバグを作りこんでしまう可能性があります。
これを避けるために、リークや２重解放のバグの修正を行った時には、その反対の症状である２重解放やリークの潜在バグを埋め込んでいないか、慎重に確認する事が大切です。そのような事が、レビューの注意点としてエンジニアで共有されているかという観点に注意して確認をしていきます。
次は開発技術の設計・実装について紹介します
テストのチェックリストではここまでです。ここまでで、ソフト開発の入り口の要求仕様と出口のテストに関するチェックリストについてチェックする内容や注意点につて簡単に紹介してきました。入口と出口の次は両者を繋ぐ設計と実装です、次の記事では開発技術の中で実際にソフトを作成するフェーズに相当する設計と実装に焦点を当てたチェックリストについて紹介していきます。