3.1 静的テストの基本

レビューや静的解析もテスト活動に含まれる

動的テスト: ソフトウェアを実行して故障という形で欠陥を検出するもの
静的テスト: ソフトウェアを実行せずに成果物の欠陥を直接検出するもの

実行できない場合に有効

セキュリティテストでも重要

3.1.1 静的テストで検査可能な作業成果物

レビュー: 人が読んで理解できるもの
静的解析: ツールに読み込ませられるもの
- 構造的なもの(コード等)はもちろん自然言語もいける (textlint等)

3.1.2 静的テストの利点

早期テストによるコスト減など

レビューを効果的に進めるためにはソフトウェアの内部構造を理解すると効果的
参加者の知識やチェックリスト等のノウハウに依存するため、実施前の準備が肝要
- 経験豊富なレビューアをアサイン
- ナレッジベースを利用したチェックリストを準備

3.1.3 静的テストと動的テストの違い

目的は同じ

作業成果物の品質を評価すること
可能な限り早期に欠陥を識別すること

一方で、相補的でもある

	静的テスト	動的テスト
検出対象	欠陥	欠陥により生じる故障
コスト	低い	高い
整合性や内部構造に関する欠陥検出	得意	不得意
パフォーマンスや使用感に関する欠陥検出	不得意	得意

保守性欠陥のほとんどは静的テストでのみ検出できる

3.2 レビュープロセス

非形式的レビュー
- 定義したプロセスに従わない
- レビュー結果を形式的に文書化しない
形式的レビュー
- チームで参加
- レビューの結果とプロセスを文書化

レビュー焦点はレビューの目的ありき

V字モデルにおける主なレビューポイントの例

要求分析  → **受け入れテスト仕様書**
    ↓ **ユーザー要求分析書**
  要件定義  → **システムテスト仕様書**
      ↓ **システム要件定義書**
    基本設計  → **統合テスト仕様書**
        ↓ **基本設計書**
      詳細設計  → **コンポーネントテスト仕様書**
          ↓ **詳細設計書**
        実装

3.2.1 作業成果物のレビュープロセス

下記のような変数に応じて決める

ソフトウェア開発ライフサイクルモデル
開発プロセスの成熟度
レビュー対象の作業成果物の複雑さ
法律や規制から生じる必要性
監査証跡の必要性

ISO/IEC 20246では5つの主要活動を定義している

計画
レビューの開始
個々のレビュー
懸念事項の共有と分析
修正と報告

計画

範囲の定義

レビューの目的
- 欠陥の発見
- 作業成果物の内容の理解
- 教育
- 判断の合意
レビュー対象
評価すべき品質特性(ISO/IEC 25010等)

工数と時間を見積もる

レビュー特性を識別する

目的に応じて最適なレビュータイプを選ぶ

作業成果物の完成度合いが低い場合は非形式的レビューのほうが効果的
関係者への説明目的ならばウォークスルー

ほか、役割、チェックリストなどを含む

レビューの参加者を選び、役割を割り当てる

形式度合いに応じて有識者を呼ぶ
作業成果物のどの部分のレビューを依頼するか明確化する

開始基準と終了基準を定義する/開始基準が満たされていることをチェックする

形式的な度合いが高いレビューほど必要となる

例

作業成果物の完成
レビュー参加者と役割の決定

非形式的レビューの場合は基準を明文化せず、担当者判断で決める

レビューの開始

参加者にレビュー計画に対する合意をとることが肝要

さもないと脱線して時間を食う

個々のレビュー

「懸念事項」を一覧表形式で書き出す

ISO/IEC 20246で一覧表のフォーマットが提示されている

まだ「懸念事項」であり、「潜在的な欠陥」である。欠陥と断ずるのはこの後

懸念事項の共有と分析

適宜レビューミーティングを開催し、懸念事項の優先度付け、オーナーとステータスの割り当てを行う
- 対処する
- 注意すべきだが今は対処しない
- 却下など
品質特性を評価・文書化し、終了基準に対して評価してレビュー判定
- 却下
- 大規模な変更が必要
- 小規模な変更が必要
- 受け入れ可能など

修正と報告

欠陥レポート作成・関連部署に伝達

レビュー結果が「対処する」のステータスの懸念事項は「欠陥」と定義して欠陥レポート作成
- 「注意すべきだが今は対処しない」も起票しておくと将来の参考になる

欠陥修正

作成者だけで閉じる場合

欠陥について議論

作成者以外の作業成果物に跳ねる場合

欠陥のステータス更新・懸念事項起票者(コメントした人)の合意

メトリクスを収集

形式的なレビュータイプの場合

欠陥の傾向を分析し以降のフェーズに役立てる

終了基準が満たされていることをチェック・結果の文書化

形式的なレビュータイプの場合

3.2.2 形式的レビューでの役割と責務

特に形式的レビューの場合、参加者の役割と責務の定義が曖昧なままだと円滑に進まない

作成者

作業成果物を作成/欠陥を修正する人

マネージャー

工数等を勘案してレビューの計画や、実施・中止そのものを決定する人

PM等が行うことが多い

その他参加者が評価を気にすることで発言・行動に悪影響を与えないよう、レビューミーティングには参加しないほうがよい

ファシリテーター(モデレーター)

レビューミーティングに参加して取りまとめる人

開発チーム/テストプロジェクトのリーダー経験者等、実力者が適している

さまざまな調整役

レビューリーダー

レビューアを人選する人
レビュー期間・場所の決定をする人

レビューア

各領域の専門家
それぞれが異なる観点で作業成果物の欠陥を識別する人
- テスト担当者
- プログラマー
- ユーザー
- オペレーター
- ビジネスアナリスト
- 使用性専門家

書記(記録係)

形式的レビューで任命される

3.2.3 レビュータイプ

レビューの「進め方」

cf. 個々のレビューで懸念事項を発見するためのテクニックは「レビュー技法」

非形式的レビュー
ウォークスルー
テクニカルレビュー
インスペクション

すべてピアレビュー(同じ職位の同僚によるレビュー)が可能

同一の作業成果物に対して複数適用する場合もある

例: 非形式的レビューでテクニカルレビューの開始条件を満たしていることを確認して、テクニカルレビュー

状況や制約条件に応じて適切なものを選ぼう

1機能ぶんの基本設計書を作成途中なら、非形式的レビューで多くの懸念事項を発見・処理すると効率がよい
100機能ぶんすべて完成して詳細設計・実装前のベースラインとして承認する場合、非形式的レビューは不向き

各種レビューの属性の比較

	非形式的レビュー	ウォークスルー	テクニカルレビュー	インスペクション
潜在的な欠陥の検出以外の目的		プロダクト改善異なる実装方法の検討標準や仕様への準拠の評価	合意の獲得	作業成果物の品質の評価と信頼の積み上げ作成者の学習根本原因分析による将来の類似欠陥の防止
形式的	x	o	o	o
レビューミーティング		必須	任意	必須
レビューミーティング前の個々のレビューア前準備		任意	必須	必須
書記		必須	必須(作成者以外がよい)	必須
手動		作成者	ファシリテータ	ファシリテータ
ルール・チェックリスト		任意	状況次第	必須

3.2.4 レビュー技法の適用

「個々のレビュー」活動で欠陥を見つけるために適用できる技法

各レビュータイプに適用できるが有効性は異なる

アドホック

作業成果物を順に読んで懸念事項を識別するごとに記録に残す

【所感】GitHubのアレ
非形式的レビューでよく用いられる
レビューアのスキルに大きく依存
複数レビューアから重複した懸念事項が多く報告されてしまう

チェックリストベース

過去の事例に基づいた質問形式のチェックリストを定期的にメンテナンスして行う

【所感】phinderやphp-cs、自然言語ならtextlint等で機械的に取り締まるのはこれにあたるか
チェックリスト外の欠陥も検出する努力が必要 (チェックリストだけに従うと過去の事例しか拾えないので)

シナリオとドライラン

dry-run: 最初からシステムを動かすイメージでレビュー対象を見るの意

作業成果物がユースケース技術の場合などに適用しやすい

チェックリストベースドレビューと相補的

シナリオベースドレビューでは、全体の整合性や要求に対する妥当性の欠如といった欠陥を見つけやすい
機能の欠落等は見逃す可能性があり、チェックリストベースドレビューが適している

ロールベース

異なるステークホルダーの観点でレビューする

特定のエンドユーザーの種類(熟練/初心者、年配/子どもなど)
ビジネス担当の役割(マーケティング担当、経営者、営業担当など)
IT組織内の特定の役割(開発担当、ユーザーアドミニストレータ、システムアドミニストレータ、性能テスト担当者など)
ペルソナ

効能

深く掘り下げられる
レビューアごとの重複予防

パースペクティブベース