リリース判定基準・開発管理プロセスは設計と実装とテスト計画を見る
開発計画の次は開発実務の中心の設計と実装とテスト計画
前の記事ではリリース判定で開発管理プロセスの品質の善し悪しを判定するための重要な６つの開発管理プロセスのうち、開発計画の良し悪しの判定の仕方について紹介しましたので、この記事では続いて設計と実装とテスト計画について紹介します。
２．ソフトウエアの設計と実装はレビューの管理を見る
開発計画を立案するプロセスに問題なければ、次は設計と実装の管理プロセスの確認です。設計と実装のプロセスは、ソフトを開発する業務の根幹部分なのですが、実はプロセス品質の確認という観点からはそれほど確認できる項目はありません。ただひとつレビューの計画と実績という管理面を確認するのみです。
ソフトの開発は、設計でも実装でも全て担当者（つまり人間）が頭の中で考えた内容を自然言語や計算機言語で書き出す作業です。人間が考える事なので間違える事もあれば書きかたが悪くて意味が間違って伝わる事もあり得ます。そのような間違いを見つけて修正するのが、設計レビューやコードレビューです。このレビューの重要性は改めて説明する必要も無いと思いますが、設計と実装のプロセス品質においては、このレビューの品質がとても重要です。
計画したレビューが実施できたかどうかが重要
設計レビューやコードレビューは、開発を始める段階でレビュー対象（どの設計書やソースコードに対してレビューするのか）と、レビュー密度（何回レビューするのか）の計画が立てられます。このレビュー対象とレビュー密度の計画は、何等かのルールに従って決める事もあれば開発リーダの経験と勘で決める事もあると思います。
どの様な決め方でも構いません、決めた結果が、そのソフトウエア開発組織が今回の開発プロジェクトに捻出できる技術的な力量です。 ソフトウエア開発プロセスの視点で重要な事は、当初計画されていた設計レビューやコードレビューが、開発プロジェクトが進行する中で、ちゃんと実施されてその結果が有効に使われていたか？ という点です。
もう少し具体的に言うと、設計レビューやコードレビューについて以下のような点で問題が無いかという事です。
- レビューは、当初計画されていた設計書やソースコードに対して実施されたか？
- レビューには、当初計画されていて開発リーダや開発経験者が参加していたか？
- レビューでの指摘事項は、何等かの方法で記録が残っているか？
- レビューでの指摘事項は、全て対応が終了しているか？
１つ目と２つ目は、計画していたレビューがちゃんと実施されたかどうかの確認です。開発が終盤になって、納期が近くなるのに工程が遅れていると、工程挽回のためにレビューが先送りになったり省略されたりする場合があります。
当初計画で必要だと考えていたレビューというのは、本当に必要なレビュー、つまり設計や実装で間違い易い箇所のレビューである事が多いです。 開発の終盤で、納期に追われてこれらのレビューが無くなると、結果として潜在的なバグが見落とされて品質が低下するリスクが高まります。 当初の計画が未実施だと、ソフトウエア品質上のリスクが高まります。
レビューの指摘は最後まで対応されているかがその次に重要
３つ目と４つ目は、レビューで指摘された項目が漏れなく/忘れなく対応が済んでいるかの確認です。レビューは実施する事が目的ではなく、気付いた指摘事項を対処して潜在バグを取り除く事が目的です。レビューで折角指摘したのにその後の対応を忘れてしまっては、レビューに掛けた時間も工数も無駄になってしまいます。
そうならないように、レビューの指摘事項はしっかりと記録を採り、その一つ一つの指摘事項に対してレビューの後で対応を行い全ての対応が終わっている事を確認する事、がとても大切です。対応の中には、レビューで指摘があったけれどももう一度検討すると問題が無かったと結論づけるような対応方法が含まれて居ても問題ありません。要するに、全ての指摘事項に対して何等かの結論がでていればそれで良いのです。
３．設計と実装の次はテスト計画
設計と実装の次にはテスト計画の内容を確認します。ここでは、開発計画書と同じようにテスト計画書に必要な事がちゃんと書かれているか、という視点で確認します。
テスト計画書がある事が前提なのですが、もしテスト計画書が作成されていないプロジェクトであっても、テストを実施している限りは何等かのテスト項目の一覧とかテストの手順書を見て、同様の判定を行う事は可能です。でも、やはりテスト計画書があった方が良いので、ぜひテスト計画祖そ作成するようにして下さい。
さて、テスト計画書にも色々な書き方があるのですが、以下のような項目はだいたいのテスト計画で必須の項目ですので、これらが漏れなく具体的に書かれているか、とう視点で確認します。
- テストの対象と環境
- テストカテゴリや目的
- テスト結果の記録とトレース方法
まずは何をテストするのかが明確か
まずはテストの対象と環境ですが、これが明確に設定されていないと折角テストを実施してもその結果を使えません。例えば、Ver.2.5 をリリースするのに Ver2.3 を使ってテストしたのでは、Ver.2.5 の品質が良いか悪いかの判定に使えません。 テストの対象となるソフトウエアの名称とバージョン番号が明記されている事が、まず第一に必要です。 また、例えば Windows10 で使うソフトウエアを Windows7 の上で動作させてテストしても、その結果をどこまで信用して良いか、判断は難しいです。 テストの結果を有効な物にするには、稼働するハードウエアやOSに加えて、利用するテスト機器等のテストの環境が明確になっている事も大切です。
ごく当たり前の事ですし、テストを実施する時に、対象とするソフトウエアのバージョンを間違えたり、テスト環境を間違えたりする事は、さすがに無いと思います。わざわざ確認する必要もなさそうにも思えますね。
しかし、テスト計画の段階では第一に決定しておく必要のある項目です。 メジャーバージョンアップのリリースなのかマイナーバージョンアップのリリースなのか、によってテストの方針が変わります。 使えるテスト環境によっても、テストの内容や期間が変わります。 これが明確にテスト計画書に書かれていないと、テスト計画自体の信頼性が薄れてしまいます。
次にテストの目的は適切で漏れはないか
次にテストカテゴリやテストの目的です。 テストカテゴリという言葉は、耳慣れない方もおられるかも知れませんね、日本語にするとテストの種別というところでしょうか。具体的には、機能テスト、高負荷テスト、大規模テスト、というようにテストを目的別に分類して名前をつけた、テストの種類というかテストの分類というかそのような物を指す言葉です。
言い方を変えると、テストカテゴリとはテストの目的に沿って作成した、テストの分類名称という事もできます。例えば高負荷テストというテストカテゴリは、高負荷が掛かった時にでも製品が正常に動作する事を確認する事を目的としたテストの分類名称です。ですので、テストカテゴリを確認する事とテスト目的を確認する事とは、ほぼ同じ事を指します。
そして、テスト計画の確認では、どんなテストカテゴリ（つまりはテストの目的）のテストが計画されているか？ という視点でテスト内容の確認をします。 テストカテゴリにもいろいろな分類がありますが、以下のようなテストカテゴリのうちで、その製品に必要なカテゴリのテストが、計画されているかどうかを確認する必要があります。
テストカテゴリにこのような種類が含まれているか
- 機能テスト：仕様書に書かれて居いる機能が実現されている事を確認する
- 性能テスト：仕様書に書かれている性能が出る事を確認する
- 大規模テスト：仕様書に書かれている最大構成で機能が働く事を確認する
- 高負荷テスト：製品に最大負荷が掛かった状態でも機能が提供される事を確認する
- 回復性テスト：異常状態が起きても、異常な原因がなくなれば元に戻る事を確認する
- 安定性テスト：長時間使い続けても正常に動作し続ける事を確認する
- 保守性テスト：不具合の調査や回復の機能がについて確認する
- 大容量テスト：大規模データを入力しても正常に処理される事を確認する
- ドキュメントテスト：取説に書いてあるとおりに動作する事を確認する
- 互換性テスト：旧バージョンとの互換性について確認する（互換性が必要な時のみ）
- セキュリティテスト：脆弱性確認やサイバー攻撃に対する耐性について確認する
テストの結果はちゃんと記録されて管理されているか
最後が、テスト結果の記録とトレース方法です。テストの結果は合否も含めて何等かの記録が採られて、最終的にはテスト報告書として纏められます。ここで確認する必要があると言っているのは、このテスト報告書ではなく、テストで見つかったバグの記録と管理です。
テストの目的はテスト報告書を作る事ではありません。潜在バグを見つけてデバッグサイクルを回すか、バグが無い事で品質を保証するか、このどちらかです。 ソフト開発プロジェクトにとって特に重要なのが、潜在バグを見つけてデバッグサイクルを起動するという目的です。この目的を効率よく実行するには、バグを見つけた時の手順についてテスト計画書で明確にしておく事が必要です。
バグを何に記録するのか、どんな情報を記録するのか、記録した事を誰に・どんなタイミングで連絡するのか、バグの再現性確認は誰が担当するのか、などのデバッグサイクルの回し方が、具体的に決まっている必要があります。
それとともに、発見されたバグについてのその後の作業のトレース方法も決まっている必要があります。見つかったバグは、原因が調査され、修正の要否が判定され、修正が必要なバグはソースコードの修正が実施され、バグが修正された事を再テストで確認され、修正内容が正しい事が確認されたらソースコードのマスターツリーに登録され、次回のリリースに反映されて、やっとデバッグサイクルを終了します。
この、デバッグサイクルの終了までたどり着いて初めて、テストで潜在バグを発見する目的が達成されます。 そこにたどり着くまで、作業の進捗がトレースできないと、折角見つけたバグが修正されずに見落とされる事も起こり得ます。 そのような事にならないように、発見されたバグのその後のトレース方法も、テスト計画書に書かれている事が大切です。