ソフト開発監査では開発技術の中でも重要なテスト技術の良否を最初に判定する
ソフト開発監査では開発技術の中でも重要なテスト技術の良否をまず判定します
ソフト開発監査では開発プロセスの品質とソフト開発技術力の良し悪しを評価します。ソフト開発技術はさらにテスト技術と要件把握と設計・実装３つの分野に分けて評価するので、全体では以下の４つの項目に分かれます。ソフト開発技術にはこれ以外にも様々な観点があるのですが、限られた時間で開発委託先の技術力を評価するために、ソフト開発監査ではこの３点に絞ってソフト開発技術の良し悪しを判断していました。この記事ではソフト開発監査で２番目に確認する開発技術のうちのテスト技術について良し悪しを評価する方法を紹介します。
- 開発プロセス （ソフト開発に使っている開発プロセスは良好か？）
- 開発技術：テスト技術 （リリースまでに実施しているテストの技術力は十分か？）
- 開発技術：要件把握 （開発要件を具体化し委託元と共有する技術力は十分か？）
- 開発技術：設計・実装 （ソフトの設計と実装の組織としての能力は十分か？）
それでは、テスト技術についてどんな観点で何を確認しているのか順に紹介していきましょう。
２．開発技術・テスト技術が十分かどうかは技術と体制の両面から確認する
ソフト開発監査では、開発プロセスとテスト技術力と要件把握力と設計・実装力の４つの観点で技量の良し悪しを確認していきます。この記事では、２つ目のテスト技術力について、どんな観点で確認していくのかを紹介していきます。
ソフトの開発には、企画、設計、実装、テスト、保守など様々なプロセスが必要で、それぞれのプロセスを実施するためにはそのプロセス領域に関する技術力が必要です。どの領域の技術力も同じように大切でどこが欠けていても良いソフトウエアはできません。しかし、ソフト開発監査で委託先のソフト開発技量を確認する時に、特に品質の面からグータラ親父が一番重要視しているのがテスト技術力です。
ソフトが大規模化した結果、製品に搭載されるソフトのうち社内で開発した部分の比率はどんどん低下し、購入品やチップベンダ提供の無償ソフトやＯＳＳ（オープンソースソフトウエア）の割合が拡大してきました。そのような状態でソフトの品質を保証するには、テストを充実させる事が必須です。ですので、ソフト開発の委託先の開発技量を推定する場合にも、委託先がテストに関して充分な技術力を持っているかどうかを判定する事がとても大事になってきます。
では、テスト技術の善し悪しはどんな事を確認すれば判るのでしょうか？ テスト技術と一言で表現していますが実はテスト技術にもいろいろな側面があり、複数の視点で良否を判定しないと技術の善し悪しを正しく判定できません。かといって、汎用的なテスト技術の評価の方法というものなかなか見当たらないので、グータラ親父はソフト開発監査では以下のようなテスト技術力とテストの体制や管理の領域を監査の対象として、委託先のテスト技術力の善し悪しを判定していました。
- テストチームの体制とテスト計画
- 採用しているテストカテゴリと担当部署
- 採用しているテストプロセス
- テストの進捗管理と計画の見直し
- 検出したバグの管理
それでは、各々の監査の対象についてどんな観点で何を確認しているのか順に紹介していきましょう。
テストチームの体制とテスト計画書は明確になっているか
まず最初に確認するのが、どんなチームでテストを行なうのかというテストチームの体制です。 会社の規模や組織の構成によって色々ですが、テストを行うチームとしては以下のような物があります。
- 設計や実装を行うチームの中で、設計や実装を行ったソフトウエアエンジニアがテストも担当する
- 設計や実装を行うチームの中で、テストを専門に行うテストエンジニアがテストを担当する
- 設計や実装を行うチームとは別のテストチームが開発部門にあって、そこのテストエンジニアがテストを担当する
- 設計部門とは別の品質保障部門の中にテストチームがあって、そこのテストエンジニアがテストを担当する
１から４のどれかに当てはまる場合もあれば、複数のチームが役割分担をしてテスト体制ができている場合もあります。いずれにしても、監査対象の会社や組織でのテストチームの体制と、誰がチームリーダで何人程度のチーム員が居て、どこでテスト作業を行っているのか、できるだけ具体的にテストチームの状況を確認します。
同時に、テストチーム単位でもソフト開発の全体としてでも構わないのですが、テスト計画書の有無を確認します。ソフト開発の作業の中でテスト技術がしっかりと確率している組織では、設計・実装に関する開発計画書とは独立したテスト計画書が作成されている事が多いです。もちろん、開発・実装に関する開発計画書の中にテスト計画が入っていても構わないのですが、大規模化したソフトでは、設計・実装よりもテストのほうが必要な工数が大きくなっている事が多く、そのような観点からも独立したテスト計画書があったほうが、テスト技術としてはより安心できます。
採用しているテストカテゴリは過不足なく担当部署は明確か
次にどんなテストカテゴリを採用しているのかを確認します。テストカテゴリとは日本語にするとテスト分類というところですが、テストの目的によってテストを分類したものと考えると判り易いです。例えば、正常系テストと異常系テストというのも１つのテストカテゴリです。ソフト開発監査では、監査対象の会社が採用しているソフトのテストカテゴリがどんな物なのか、カテゴリの名前とその具体的な内容を教えてもらい、各々のカテゴリのテストをどのテストチームで実施しているのかを確認していました。
というとなかなか恰好いいのですが、実際にソフトの開発監査の現場でテストカテゴリを見せて下さいと依頼しても、これが当社のテストカテゴリですと提示してくれる所は少ないです。特に海外の若い会社の場合には、テストカテゴリって何ですか？ と聞かれる場合も多よくありました。その様な時にはこちらからテストカテゴリの例を示して、このようなカテゴリのテストをどのテストチームで実施していますか？ と確認するという方法を採っていました。
テストカテゴリにも色々な分け方がありますが、グータラ親父は Glenford J. Myers 氏による The Art of Software Testing , Second Edition という本に書かれている 以下の15項目のテストカテゴリが判り易かったので、これを参考にしていました。
- Facility Testing
- Volume Testing
- Stress Testing
- Usability Testing
- Security Testing
- Performance Testing
- Storage Testing
- Configuration Testing
- Compatibility/conversion Testing
- Installability Testing
- Reliability Testing
- Recovery Testing
- Serviceability Testing
- Documentation Testing
- Procedure Testing
ソフトのテストと一言で言っても、機能確認や性能確認など、色々な目的のテストがあります。テストでは、できるだけ多くの目的のテストをバランス良く実施するのが良いですので、採用しているテストカテゴリとそのカテゴリ毎の実施状況を確認するのは、テスト技術の善し悪しを判定する良い手段です。
採用しているテストプロセスは明確化
テストカテゴリでテストの目的を確認したらその次はテストプロセスとしてどの様な物を採用しているかを確認します。ソフトのテストも、設計や実装と同じ様に複数のプロセスで構成されています。テスト計画の立案、テスト環境の構築、テストの概要設計、テストの詳細設計、テスト設計のレビュー、テストの実施、テスト結果の記録、テスト成果（検出したバグ）のトレース、テスト結果のレビュー、テスト結果に基づくテストの再計画 など様々なテストプロセスがあります。ソフトのテストについて、どこまで具体的なプロセスが決まっているのか、各々のテストプロセスは明文化されていて誰でも同じように実施できるようになっているのか、などを確認する事でも、テスト技術の善し悪しを判定する事ができます。
テストの進捗管理と計画の見直しはどうなっているか
テストカテゴリとテストプロセスとで具体的なテストの内容を確認したら、次はテスト管理の確認です。ソフトの開発と同様にテストについてもテスト進捗の管理やテスト品質の管理が必要ですので、その管理の状況もソフト開発監査の対象です。
テスト進捗の管理はわりと判り易いです、１日に平均 50項目のテストを実施するというテスト計画であれば、毎日の実際のテスト実施項目数を調べて50項目ずつ進んでいれば進捗の実績は計画どおりという事です。このテストの進捗状況を知るには、テストの実施項目を定期的に集計して計画と比較するという作業が必要なのですが、このような集計と比較の作業がちゃんと計画されて実行さているかといのがソフト開発監査で確認する領域です。
また、テストを進めていく中で、このテスト条件は作りだせない！、とか、このテスト項目はさっきやった別のテストとダブっているのでは？ というようなテスト設計自体の間違いが見えてくる事もあります。 この様な事が余り多いと、テスト設計自体の品質が悪くてテストの実施効率が低下してくるので問題です。 これはテスト品質の監視と管理の活動なのですが、そのような監視と管理の活動があるかどうかも、テスト技術を判定するための確認領域です。
また、実際にテスト進捗の監視をしていると、じわじわと計画から遅れていく事があります。テスト計画の遅れが大きい時の原因には色々とあるのですが、もしテスト対象のソフトの品質が悪くてテストがなかなか進まない、というような状況が発生しているのなら、どこかの段階で今やっているテストを中断して、ソフトの品質が良くなってから再度テストを実施するように、テスト計画の見直しを行う必要が出てくる場合もあります。誰がどんな情報を元にテスト計画の見直しの要否を判定するのかが明確になっているか、という点も監査を進める上での注意点です。
検出したバグの管理はどうしているか
テストの目的は大きくは、①ソフトに潜在しているバグを洗い出す。②ソフトにバグが無い事を保証する、 の２つに分かれます。この内で、①の潜在バグの検出を目的に行うテストでは、その成果物としてソフトのバグが検出されます。検収されたバグは、設計・実装部門で調査を行いソースコードを修正するデバッグサイクルが実施され、修正されたソフトで再度テストが実施されます。
この時に、検出したバグをどのように記録しているのか、記録内容にはバグを再現するために必要な情報が全て入っているのか、検出したバグは修正が完了するまでトレースする仕組みがあるのか、など検出したバグが最後まで対処されている事を確実にするバグ管理の仕組みについても、ソフト開発監査で確認します。
小規模な開発の場合には EXCEL のような一覧表でバグ管理をしている事もありますし、開発部門が複数拠点に分散していたり、設計・実装チームとテストチームとが別々の拠点や国で作業をしてる場合には、バグ管理もネットワーク上のシステムで稼働している場合もあります。どのようなツールでも構わないのですが、ソフトの最終リリースの時まで、見つけたバグを確実にトレースする仕組みができていて、安定して稼働している事は、ソフトの品質を保証する上で重要な項目です。
開発委託先のテスト技術の善し悪しを判定するには、色々な考え方があると思います。ここで紹介したのはあくまでもグータラ親父はこんな視点でこんな箇所を見ていたという一例ですが、皆さんの参考になれば幸いです。それではテスト技術の次に大切な要件把握についての技術力の確認について、紹介しましょう。