要件、ユーザーストーリー、ソースコードなどの作業成果物のレビュー、ソースコードの静的解析をすることもテストに含まれます。
ソフトウェアを実行して結果を確認することを「動的テスト」、レビューや静的解析を「静的テスト」と呼びます。
静的テストは、実際には動作や実行ができない場合にとても有効な手段です。
この静的テストもテストと呼ばずに行っていることですが、品証の人が開発から理解を得ずにただ真っ向から行って指摘すると、お前らが言うなと揉めるのが実際の現場。
特にソースコードの静的解析は品質を高める上で価値はあるのですが、そこまで出来るスキルがあったら、開発やってよとなりがちな部分です。
静的テストで検査可能な作業成果物
- 仕様（ビジネス要件、機能要件、セキュリティ要件など）
- エピック、ユーザーストーリー、受け入れ基準
- アーキテクチャーおよび設計仕様
- コード
- ソフトウェア（テスト計画書、テストケース、テスト手順、自動化テストスクリプトなど）
- ユーザーガイド
- Webページ
- 契約、プロジェクト計画、スケジュール予算
- モデルベースドテストで使用するアクティビティ図などのモデル
人が読んで理解できる作業成果物であればすべてを対象にできます。
とありますが、実際問題、それなりの開発やプロダクトの知識がないと理解ができないでしょう。
品証の人からすると、そこまでの知識がついていけず、なかなか難しい部分があり、結果、文言の指摘に留まることになりがちです。
品証の人がそういった指摘してきて、開発が、だったら、そのまま直してよ、って揉めたことを思い出しました。
静的テストの利点
早い段階で欠陥を識別でき、動的テストより安価に修正できます。
- 欠陥の検出と修正をより効率的に、しかも動的テストを実行する前に行うことができる
- 動的テストでは容易に検出できない欠陥を識別できる
- 要件の不整合、曖昧性、矛盾、欠落、不正確性、冗長性を明らかにして、設計時またはコーディング時に欠陥が混入するのを防止できる
- 開発の生産性を向上できる（設計の改善、保守性の高いコードなど）
- 開発にかかるコストと時間を削減できる
- テストにかかるコストと時間を削減できる
- ライフサイクルの終盤または本番リリース後に検出される欠陥数が減少し、ソフトウェアの存続期間にわたる全体的な品質コストを削減できる
- レビューへの参加過程でチームメンバー間のコミュニケーションを改善できる
静的テストと動的テストの違い
静的テストと動的テストは、「作業成果物の品質を評価すること」と「なるべく早期に欠陥を識別すること」と目的は同じですが、それぞれが異なる種類の欠陥を見つけることができるため、相互に補完すると効果的になります。
プルリクエストのレビューでは、きちんとソースコードをトレースして、不具合を洗い出すことができる人がいました。
そういう人は、静的テストと動的テストを同時に自然と行えているのです。
特にコードの静的テストで見つけたいのは例外でしょう。ほとんどケースだったら正常動作で問題なく動作するのですが、想定外の時に問題なく動作するかになってきます。
それを動的テストだけで見つけ出すことは困難です。が、それでもコードも見ずに、動的テストで見つける天才的なテスターもいます。
静的テストは直接欠陥を識別することが特徴です。一方、動的テストは欠陥によって起こる事象である故障を発見します。
もう一つの特徴は、欠陥を識別するのに動的テストよりはるかに少ないコストで検出できます。
静的テストの方が、動的テストより簡単かつ安価に見つけることができる欠陥としては以下のものがあります。
- 要件の欠陥（例えば、不整合、曖昧性、矛盾、欠落、不正確性、冗長性）
- 設計の欠陥（例えば、非効率なアルゴリズムやデータベース構造、高い結合度、低い凝集度）
- コードの欠陥（例えば、値が定義されていない変数、宣言されているが使用されることのない変数、到達不能コード、重複したコード）
- 標準からの逸脱（例えば、コーディング標準を遵守していない）
- 正しくないインターフェース仕様（例えば、呼び出し側のシステムと呼び出される側のシステムの異なる単位の使用）
- セキュリティの脆弱性（例えば、バッファオーバーフローが発生する可能性）
- テストベースのトレーサビリティもしくはカバレッジが不十分もしくは不正確（例えば、受け入れ基準に対するテストケースが欠落している）
レビュープロセス
テスト担当者は積極的に開発に関与し、開発で作成された作業成果物のレビューをすることで、テスト、そしてプロジェクトの成功に貢献できるのです。
一方的、テスト担当者自身が作成する作業成果物についてもレビューが必要です。
と、レビューが大事なのは、そうですが、それで作業が止まるのでスピードが落ちるんですよね。
で、大体、レビューする人は限定されるので、その人がボトルネックになることがしばしばです。
と思っていると、本書では、レビューの必要性は理解していていつつも、レビューは時間がかかる割にあまり効果が得られないと感じている技術者は多いのではないでしょうか。（中略）正しいプロセスや技法でレビューを行えば、必ず効果は出ます。人は思い込みをするものであり、一度思い込んでしまうと、明らかな間違いでも気づかないことが多々あるからです。
作業成果物のレビュープロセス
決められたプロセスに従わない、非形式的なレビューと、標準プロセスに従ってレビューを行い、レビュー結果を文書化する形式的なレビューに分類できます。
計画
計画で行うのは、
- レビューの範囲を定義する。これには、レビューの目的、レビュー対象のドキュメント、評価すべき品質特性を含む。
- 目的の例は以下
- 欠陥の発見
- 作業成果物の内容の理解
- テスト担当や新しいチームメンバーなどの参加者に対する教育
- 判断の合意
- 以下のような確認事項の中から今回のレビューでは何を確認して作業成果物の出来栄えを評価するのかを決めるといった方法でも良い
- 日本語としての読みやすさを確認する
- 記載内容が他の開発担当者が作成した作業成果物と整合性が取れている
- 記載内容が上位文書に当たる作業成果物の要求を満たしている
- 目的の例は以下
- 工数と時間を見積る
- レビュー特性を識別する。これには、レビュータイプ、役割、活動、チェックリストなどを含む
- レビューの参加者を選び、役割を割り当てる
- 開始基準と終了基準を定義する
- 開始基準が満たされていることをチェックする
レビューの開始
- 作業成果物もしくは他の資料を配布する
- レビューの範囲、目的、プロセス、役割、作業成果物を参加者に説明する
- レビューについての参加者からの質問に答える
個々のレビュー
- 作業成果物のすべて又は一部をレビューする
- 潜在的な欠陥、提案、質問を書き出す
懸念事項の共有と分析
- 識別した潜在的な欠陥について、レビューミーティングなどで議論する
- 潜在的な欠陥を分析し、それらをオーナーとステータスを割り当てる
- 品質特性を評価し、文書化する
- レビューで見つけた欠陥を終了基準に対して評価し、レビュー判定を行う
修正と報告
- レビューで見つけた欠陥で変更が必要なものについて欠陥レポートを作成する
- レビュー対象の作業成果物で見つかった欠陥を修正する
- 適切な人またはチームと、欠陥について議論する
- 欠陥のステータスを更新する。コメント作成者の合意を含むこともある
- メトリクスを収集する
- 終了基準が満たされていることをチェックする
- 終了基準に到達した時に作業成果物を受け入れる
形式的レビューでの役割と責務
典型的な形式的レビューでの役割を説明します。
- 作成者
- レビュー対象の作業成果物を作成する
- 必要な場合、レビュー対象の作業成果物の欠陥を修正する
- マネージャー
- 責任を持ってレビューの計画を行う
- レビューの実行を決定する
- 担当者、予算、時間を割り当てる
- 費用対効果を継続的にモニタリングする
- 不適切な結果が発生した状況に対してコントロールする
- ファシリテーター
- 効果的なレビューミーティングを運営する
- 様々な意見の調整を行う
- レビューの成功を左右する重要な役割を果たす
- レビューリーダー
- レビューに関して全体的な責任を持つ
- 参加者を人選し、レビューを実施する期間と場所を決定する
- レビューア
- 書記（記録係）
参加者の役割と責任の定義を曖昧にするとレビューが円滑に進まないので、役割を明確にするようにしましょう。
とありますが、ここまで役割を決めて、実施している現場は経験がないですね。
正直、こんな役割を決めてミーティングしてたら、会議ばっかりで仕事にならなそうですね。。。
レビュータイプ
レビュータイプとは、レビューを形式の持つ属性で分類したものです。
非形式的レビュー
以下のような方法で行われます。
- バディチェック ... 作成者が同僚に作業成果物を渡して、一人で確認する
- ペアリング ... ペアプログラミングのように同僚が隣で確認しながら作業成果物を作る
- ペアレビュー ... スキルのある同僚2人が作業成果物を確認する
- ピアデスクチェック ... 作成者と同僚が一緒に作業成果物のウォークスルーをする
ペアリングって言葉あるんですね。
エンジニアの人って、自分の作業に集中したいものだと思うので、いいんですかね。少なくとも僕は嫌ですね。
非形式的であるため、文書化されたプロセスに従わなくても構いません。
次の通りです。
- 主な目的は潜在的な欠陥を検出すること
- 形式的な（文書化した）プロセスに基づかない
- レビューミーティングを行わないことがある
- 作成者の同僚（バディチェック）やその他の人により実施
- 結果を文書化することがある
- レビューアにより効果が様々である
- チェックリストの使用は任意である
- アジャイル開発では一般的に行われる
個人的には、この非形式的レビューで済ませたいと思いながら書いています。
企業が大きいと、仕組みに従え、ミーティングの設定ばっかりで、本当に意味があることをしているように思えないんですよね。
ウォークスルー
レビューミーティングにて、作成者自身が中心となって作業成果物の内容を説明し、参加者の質疑に答えていきます。
ウォークスルーが持つ属性は次の通りです
- 主な目的は、欠陥の発見、ソフトウェアプロダクトの改善、異なる実装方法の検討、標準や仕様への準拠の評価
- レビューミーティング前の個々のレビューアによる準備は任意である
- 典型的には作業成果物の作成者が進行を主導する
- 書記は必須である
- チェックリストの使用は任意である
- シナリオ、ドライラン、シミュレーションの形態を取る場合がある
- 潜在的な欠陥の記録やレビューレポートを作成する場合がある
- 運営により、極めて非形式的のものから高度に形式的なものまである
このウォークスルーをうまく活用しているマネージャーがいました。
毎回ウォークスルーするのではなく、ここは重点的に見た方がいいなという時にウォークスルーする活用方法です。
とはいえ、書記はいませんでしたが。
テクニカルレビュー
同僚やレビュー対象に関するエキスパートがレビューアとして参加し、作業成果物の要件との適合性や他の文書との一貫性を確認して、懸念事項を発見します。
バディチェックと何が違うのかと思いきや、ミーティング前に個々のレビューで懸念事項の発見を済ませておき、ミーティングでは懸念事項の検討に十分時間をかけられるようにする、というものです。
複数のタスクを流動的にこなしている現代の開発で、いちいち、いついつにテクニカルレビューをやりますとか設けないとは思います。
まず、バディチェックして、そこで大きな懸念点が見つかったら懸念事項の検討をしましょうというの形だと思います。
今の所、これをリーダーとの週一の打ち合わせで、今のタスクはこんな状況と共有し、それを打ち合わせの前なり、打ち合わせの時に確認してリーダーから懸念事項をもらうと、いう形でやっていることが多いです。
何気なくやっているわけですが、いちいちテクニカルレビューしましょうなんて言葉を使ったことはないです。
そもそもテスト関係なく、会社の打ち合わせ全般ですが、こんな細かく考えてやっていないですからね。
それはさておき、テクニカルレビューの持つ属性は、
- 主な目的は、合意の獲得と潜在的な欠陥の検出
- レビューアは、作成者の技術領域の同僚、および技術分野が同じ、または別の専門家である
- レビューミーティング前に個々のレビューアが準備する
- レビューミーティングの開催は任意である。開催する場合、経験を積んだファシリテーター（作成者ではない）が主導するのが理想である
- 書記は必須である（作成者でないのが理想）
- チェックリストの使用は状況による
- 典型的に、潜在的な欠陥の記録やレビューレポートを作成する
インスペクション
標準プロセスの遵守やレビュー結果の文書化を確実に行うことが求められます。
インスペクションが持つ属性は次の通りです。
- 主な目的は、潜在的な欠陥の検出、作業成果物の品質と評価と信頼の積み上げ、作成者の学習と根本原因分析による将来の類似欠陥の防止
- ルールやチェックリストに基づいたプロセスで進行し、形式に沿ったドキュメントを作成する
- 役割が明確に決まっている。レビューミーティングで作業成果物を読み上げる「読み手」を専任で加えたりすることがある
- レビューミーティング前に個々のレビューアが準備する
- レビューアは作成者の同僚か、作業成果物に関連する別の分野の専門家である
- 開始基準と終了基準が指定されている
- 書記は必須である
- レビューミーティングでは、経験を積んだファシリテーター（作成者ではなく）が主導する
- 作成者は、レビューリーダー、ドキュメントを読み上げる担当、書記のどの役割も担わない
- 潜在的な欠陥の記録やレビューレポートを作成する
- メトリクスを収集し、ソフトウェア開発プロセス全体（インスペクションプロセスを含む）の改善に使用する
レビューミーティングで作業成果物を読み上げる「読み手」を専任で加えたりすることがある
書いていて正直笑ってしまいました。声がいい人でも選出するんでしょうか。会議が好きな会社にいた時でさえ、必要な人だけを呼ぶようにしなさいと言われていたのですが。
ここまでのレビューを経験することは、僕はないでしょう。
レビュー技法の適用
レビュー技法は試験でもK3問題として出題される大事なパートだそうです。
K3は知識レベルのことです。
- K1 記憶レベル ... 用語または概念を認識し、記憶して、想起できる
- K2 理解レベル ... 課題に関連する記述について理由または説明を選択できる
- K3 適用レベル ... 概念または技法を正しく選択し、特定の事例に適用できる
アドホックレビュー
レビューアは作業成果物を順番に読んで懸念事項を識別するごとに記録に残します。
チェックリストベース
チェックリストを使用して懸念事項を検出します。
標準レビュープロセスで説明した「計画」の段階でチェックリストをどのように準備するかを決めます。
典型的に、レビューチェックリストは、過去の事例に基づいた質問形式になっています。
これ経験あるんですが、チェックリストが肥大化しがちで多すぎて、そんな全部見切れるかってなるのが現実です。
会社の全プロダクトの欠陥の過去事例を集めたようなチェックリストを渡されて、同僚が素直に批判的な様子で怒ってましたが、黙っていた僕もそうでした。
仕組み化したつもりだろうけど、限られた工数でやるしかないよ、と。
ただ、後述されていますが、チェックリストは主要なリスクに言及できるよう最新の状態に保つとあります。
まあ、経験したケースだと作りっぱなしでしたが。作りっぱなしで、古いまま運用する、これが最悪なパターンです。やめた方がいいです。
シナリオとドライラン
作業成果物を読むためのガイドラインをレビューアに提供します。
作業成果物がユースケースのような形式の場合、利用しやすい技法となります。シナリオを用いて、期待する使い方について、本番さながらに最初から実際にシステムを動かすイメージでレビュー対象を見ていきます。これをドライランといいます。
デザイナーが挙げてくれたデザインに対してドライランすることはしばしばですね。
ぼくのリーダーは、これがうまくて、出されたタイミングでパッと見て、考えうるシナリオに基づいて、その場でドライランできてしまうのです。
紙に書くこともなく、頭の中だけで1分足らずで。ぼくにはとてもできません。
ロールベース
レビューアは個々のステークホルダーの役割の観点から作業成果物をレビューします。
典型的な役割には以下があります。
- 特定のエンドユーザーの種類（熟練者、初心者、年配者、子供など）
- ビジネス担当の役割（マーケティング担当者、経営者、営業担当など）
- IT組織内の特定の役割（開発担当者、ユーザーアドミニストレーター、システムアドミニストレーター、性能テスト担当者など）
この手法は経験ないのですが、以前CEDECで複数人でシナリオを作成する方法で、メンバーの特徴を生かして、作成していくというのを思い出しました。
例えば、僕には子供がいませんし、子供が好きでもないので、子供のセリフのリアリティについて何もわかりません。
ただ、ソフトウェアエンジニアなので、ソフトウェアエンジニアについてのセリフについて用語の使い方が正しいとかは言えるでしょう。シナリオを考えられる自信はありませんが。
パースペクティブベース
ロールベースのレビュー技法の一種です。
レビュー対象の作業成果物から各レビューアの役割で導出する作業成果物を概要レベルで作成してみます。
例えば、要求仕様についてパースペクティブベースドリーディングを行っているテスト担当者は、暫定的な受け入れテストを作成していく中で何か懸念事項がないか確認します。
というわけで、これは、それがそのまま成果物に繋がったりするので、ぼくはいいなと思いました。
レビューの成功要因
組織的な要因
- レビュー計画時に、計測可能な終了基準として使用できる明確な目的を定義する
- 達成する目的、およびソフトウェア成果物と参加者の種類とレベルに応じてレビュータイプを選択する
- レビュー対象の成果物で欠陥を効果的に識別するために適切なレビュー技法を1つ使用する
- チェックリストは、主要なリスクに言及できるよう最新の状態に保つ
- 欠陥に関するフィードバックを早期および頻繁に作成者に提供して品質をコントロールするために、大きなドキュメントは小さく分割して記述およびレビューする
- 参加者に十分な準備時間を与える
- レビューのスケジュールは適切に通知する
- マネージャーがレビュープロセスを支援する
よくPull Requestを大きくしすぎないでくれとかありますが、そういうものですね。
レビューのスケジュールは適切に通知するっても、レビューに限らずビジネス全般に言えることですよね。
こうしたことを、できる人は何気なく行っているのでしょう。
人的な要因
- レビューの目的に対して適切な人たちに関与させる
- テスト担当者は、レビューに貢献するだけでなく、レビュー対象の作業成果物の内容を把握して、有効なテストを早期に準備できると、レビューアとして価値が出る
- 参加者には適切な時間を割り当て、最新の注意を払って詳細にレビューしてもらう
- レビューアが個人でのレビュー時、および/またはレビューミーティング時に集中力を維持できるよう、レビューは対象を小さく分割して実施する
- 見つかった欠陥は客観的な態度で確認、識別、対処をする
- ミーティングは参加者にとって有意義な時間となるよう適切にマネジメントする
- レビューは信頼できる雰囲気で行い、レビュー結果を参加者の評価に使用しない
- 参加者は、自分の言動が他の参加者に対する退屈感、憤り、敵意だと受け取られないように気を付ける
- 特にインスペクションなど高度に形式的なレビュータイプには、十分なトレーニングを提供する
- 学習とプロセス改善の文化を醸成する
以前の職場でプロジェクトを開始する前に、部長たちの前でプロジェクトの資料をレビューしてもらうことがありましたが、嫌でしたね。
信頼できる雰囲気はありませんでした。後で、「〜〜さん、いつも半ギレですよ」とかプロジェクトマネージャーが言ってました。
まあ、振り返って、そりゃあ、ダメだよねと。
以上、第３章でした。第２章と比べるとだいぶ楽でした。
