ソフトウェアテストを学ぶ　その１０．静的テスト技法① レビュー編

こんちは。コンニャク打法でお馴染みのふっくら太郎です。

今回は静的テスト技法についてのお勉強です。

「レビュー」と「静的解析」の2回に分けて説明します。

静的テスト技法とは？
静的テスト技法の特徴
レビュー
有意義なレビューを行うために心がけること
まとめ

静的テスト技法とは？

静的テスト技法とは、ソフトウェアを実行せず行うテストの総称。

開発ドキュメントのレビュー
ソースコードの静的解析

などの方法を駆使して、決められたルールに従い開発ドキュメントやソースコードが作られていることを確認するテスト技法。

静的テスト技法の特徴

静的テスト技法は、開発ドキュメントやソースコード精査して、ソフトウェアの内部構造上の欠陥を検出する。

動的テストと比較して簡単に実施できるため、工数やコストが少なくなくて済む。

一方、以下のようなソフトウェアを動作させないと見つからない不具合の検出は苦手。

メモリーリーク
故障
性能などの非機能要件の考慮漏れ

そのため、動作テストと組み合わせて使われる。

レビュー

レビューとは？

レビューは、開発工程、開発ドキュメントの課題、問題点を検討して、ソフトウェアの構造上の欠陥を検出するテスト技法。
あらゆるソフトウェア成果物がレビュー対象になる。(各種開発仕様書、ドキュメント、ソースコード、テスト書など…)
レビューは開発工程、テスト工程のソフトウェア成果物作成のタイミングで行う。
レビューは複数名が参加して行う。

レビューで検出できる欠陥

規格からの逸脱
要件の欠陥、不足、考慮漏れ
設計の欠陥、不足、考慮漏れ
実装の欠陥、不足、考慮漏れ、保守性の不十分さ、インタフェイス仕様の不整合
テストの欠陥、不足、考慮漏れ、仕様の誤解

などなど・・・

レビューの効用

ソフトウェア構造上の問題を実装前・実装中に検出できるため、開発工数、コストを削減できる。
後工程への欠陥の流出を防げる。
プロジェクト内でコミュニケーションを取りながら作業を進められる。
レビュー指摘事項を分析、定量的に記録する事で、ナレッジベースが作れる。

レビュープロセスの種類 (公式レビュー)

計画、準備からレビュー終了までの作業の種類・流れ。

ISTQBでは次の6つの活動を定義している。

レビュープロセス	作業内容
計画	レビュー開催日、スケジュール、参加者の選定、レビューの終了基準を決める。
キックオフ	レビューの目的、内容の説明、レビュー対象資料の配布、説明を行う。
個々の準備	各レビュー参加者が、資料の事前確認、ミーティングの議題の洗い出しなどの準備を行う。
レビューミーティング	レビューを行う。議論した内容の議事録を作成する。
再作業	レビューで上がった課題、問題の解決、資料の修正を行う。課題リストや、バグ管理ツールを利用して課題の対応状況を管理する。
フォローアップ	課題の解決内容や、資料の修正内容を検証する。終了基準を満たしている場合は、レビューを終了する。満たしてない場合は、再度、レビューを開催し、問題を議論する。

f:id:hukkura_tarou:20170815122017p:plain

レビュー参加者

レビューは複数の人がチームを組んで行う。

参加者の種類と各々の役割は以下の通り。

レビューの参加者	役割
マネージャー	レビューの方針の決定、スケジュールの管理、モデレーターを選任する。主にプロジェクトマネージャが担当する。
モデレーター	レビューのまとめ役。レビューの計画管理、運営、参加者の選定を行う。プロジェクトリーダーなど、チームのとりまとめをしている人が担当する。
作成者	レビュー対象資料(成果物)の作成者。レビュー対象資料の作成、レビュー指摘事項の対応、資料の修正を行う。
レビューア	レビュー対象の精査、指摘、コメントを行う人。チーム内の有識者が基本的に選ばれる。チームに有識者がいない場合は、外部から参加者を招集する。
書記	レビューの内容を記録して、議事録を作成する。

レビューの種類

レビューは、目的、規模、実施タイミングにより、以下の種類に分けられる。

公式レビューのプロセスに従い実施するものもあれば、特にやり方を決めず実施するものもある。

レビューの種類	内容
非公式レビュー	非公式なレビュー。特に決まったやり方は無い。チーム内のメンバーにソースコードレビューやテスト書のチェックを行ってもらう場合に、この方法を採用する。(この場合、レビュー担当者と対象者が１対１なのでペアレビューとも言う)
ウォークスルー	成果物作成者が説明し、レビュー担当者にコメントを求める形式で進行する。顧客に仕様の合意を取ったり、社内でソフトウェアや仕様理解度を確認するため、教育目的で実施したりする。基本的に決まったやり方は無いが、仕様の検討レビュー等の場合は、公式レビューのプロセスに従い実施することもある。
テクニカルレビュー	専門知識を持つメンバーが集まり、技術的な問題の解決や、仕様についての検討を行う。基本的に公式レビューのプロセスに従い実施する。進行はモデレーターが行う。
インスペクション	公式性の高いレビュー。公式レビューのプロセスに従い進める。ソフトウェア開発の各作業工程で作成した成果物を厳密な基準に基づき検査し、欠陥が無いか判定する。また、判定結果を記録する。
机上デバック	ソースコードを目視確認して、欠陥の検出、修正を行う作業。ソースコードの作成者が一人で行う。

有意義なレビューを行うために心がけること

レビューを行う前に目的を明確にしておく。
レビューの目的に沿った人選を行う。
テスト担当者は開発レビューに積極的に参加すべし。
レビューでできるだけ多くの欠陥を検出すること。
レビューでレビュー対象の検査を効率的に漏れなく行えるように、確認事項をまとめたチェックリストがを用意する。
レビュー開催後、振り返りを行い、レビュー方法やプロセスの改善を常に意識する。

まとめ

静的テスト技法は、開発ドキュメントやソースコードを精査し、ソフトウェアの構造上の欠陥を検出するテスト技法。今回は、レビューという方法にフォーカスを当てて勉強した。
レビューは、チーム内のメンバーと一緒に開発上の問題について議論したり、成果物をチェックしたりする技法。目的や内容によって、レビュー方法が変わる。公式なレビューについては、役割を決め、規定の手続きに従い実施する。
公式レビューは、レビュープロセスが形骸化しないように、振り返りを行い、常に改善していくことが大事。非公式レビューについては、目的を明確にした上で実施することが大事。(取りあえず問題があるから有識者を集めて話をしよう！では何も解決しない)

[参考]