JSTQB FLのシラバス第3章:静的テストでの学び

はじめに

最近ソフトウェアテストに興味を持っていて、8月にJSTQB FLに受験するために学習をしています。今回は3章静的テストを学習したのでそれををまとめます。それ以外の章はまた後日順不同で行う予定です。試験の合格だけでなく実務で活かせるようにします💪

シラバスの内容で「これ大事だな」と思うもの独断と偏見で記述しています。また、「特に大事だな」と思うものboldにしています。

シラバス内容解釈

静的テストの基本

静的テスト＝仕様/資料/コードに対するレビューや静的解析

静的テストの利点

動的テストを実行する前に欠陥を早期に検出できる。早期に検出した欠陥は、本番稼動後のようなライフサイクルの終盤に検出した欠陥よりも、はるかに安価に除去できる。↓イメージ図 *1

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

保守性欠陥のほとんどは、静的テストでのみ検出できる。静的テストは作業成果物の整合性と内部品質を向上する事ができる

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

計画→レビューの開始→個々のレビュー（すなわち、個々の準備）→懸念事項の共有と分析→修正と報告

レビュータイプ

非形式的レビュー＜ウォークスルー＜テクニカルレビュー＜インスペクションの順で高度に形式的になっていく。

非形式的レビュー

• 主な目的：潜在的な欠陥の検出。
• その他の目的：新しいアイデアや解決策の創出、影響度の小さい問題の迅速な解決。
• 形式的な（文書化した）プロセスに基づかない。
  • 結果を文書化することもある。
• レビューミーティングを行わないことがある。
• レビューアにより、効果はさまざまである。
• チェックリストの使用は任意である。
• アジャイル開発では一般的に行われる。

形式的レビュー

定義されたプロセスに従うレビュー。多分お硬いやつのレビュー。

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

• 作成者
• マネージャー
• ファシリテーター（モデレーターと一般的に呼ばれる）
• レビューリーダー
• レビューア
• 書記（記録係）

形式的レビューの違い

	ウォークスルー	テクニカルレビュー	インスペクション
主な目的	・欠陥の発見 ・ソフトウェアプロダクトの改善 ・異なる実装方法の検討 ・標準や仕様への準拠の評価	・合意の獲得 ・潜在的な欠陥の検出	・潜在的な欠陥の検出 ・作業成果物の品質の評価と信頼の積み上げ ・作成者の学習と根本原因分析による将来の類似欠陥の防止
その他の目的	・さまざまな技法やスタイルに関するアイデアの交換 ・参加者のトレーニング ・合意の形成	・作業成果物の品質の評価と信頼の積み上げ ・新しいアイデアの創出 ・作成者のモチベーション向上と将来の作業成果物の改善 ・異なる実装方法の検討	・作成者のモチベーション向上 ・将来の作業成果物およびソフトウェア開発プロセスの改善 ・合意の形成
レビューア	-	作成者の技術領域の同僚、および技術分野が同じ、または別の専門家	作成者の同僚か、作業成果物に関連する別の分野の専門家
書記	必須	必須（作成者ではないのが理想）	必須
レビューミーティング前の個々のレビューアによる準備	任意	必須	必須
ミーティングを主導する人	典型的には作業成果物の作成者	経験を積んだファシリテーター（作成者ではない）が主導するのが理想	経験を積んだ進行役（作成者ではない）
レポート	潜在的な欠陥のログ、およびレビューレポートを作成	潜在的な欠陥の記録やレビューレポートを作成	潜在的な欠陥の記録やレビューレポートを作成
チェックリストの使用	任意	状況による	ルールやチェックリストに基づいたプロセスで進行し、形式に沿ったドキュメントを作成
その他	・シナリオ、ドライラン、シミュレーションの形態を取る場合がある ・運営により、きわめて非形式的のものから、高度に形式的なものまである		・役割が明確に決まっているレビューミーティングで作業成果物を読みあげる人を専任で加えたりすることもある ・開始基準と終了基準が指定されている ・作成者は、レビューリーダー、ドキュメントを読みあげる担当、書記のどの役割も担わない ・メトリクスを収集し、ソフトウェア開発プロセス全体（インスペクションプロセスを含む）の改善に使用する

個人的な覚え方

• ウォークスルー：自分が歩いて来た道を他の人が通ってきてもらうイメージ
• テクニカルレビュー：（いいイメージが浮かびませんでした）
• インスペクション：インポスター。*2メトリクスを収集して作成者は何もしないので健康診断のイメージ。

レビュー技法

個々のレビュー（個々の準備）活動で欠陥を見つけるために適用できるもの

• アドホック
  型なしでおまかせのレビュー技法。果たしてこれは技法と呼べるのか？

  レビューアは、このレビューに関するタスクのガイダンスをほとんどまたはまったく提供されない。アドホックなレビューは、準備を必要としない場合によく行う。

• チェックリストベース
  チェックリストを使ってレビューする技法。

  レビューアはレビューの開始時に配布されるチェックリストを使用して懸念事項を検出する。主な利点は、典型的な懸念事項の種類を体系的にカバーできることである。レビューを行う際には、チェックリストに単純に従うだけでなく、チェックリスト外の欠陥も検出する努力をすることが重要である。

• シナリオとドライラン
  シナリオに沿ってお試し実行。

  作業成果物を読むための構造化されたガイドラインをレビューア に提供する。レビューアはシナリオベースドレビューを使用し作業成果物に対して「ドライラン」を行う。単純なチェックリスト項目よりも、特定の種類の欠陥を検出するためのよいガイドラインとなる。他の種類の欠陥を見逃さないようにするためには、文書化されたシナリオだけにとらわれないようにしなければならない。

• ロールベース
  役割を考えてレビューする。

  レビューアは個々のステークホルダーの役割の観点から作業成果物 を評価する。典型的な役割には、特定のエンドユーザーの種類（熟練者、初心者、年配者、子供など）や組織内の特定の役割（ユーザーアドミニストレーター、システムアドミニストレーター、性能テスト担当者など）がある

• パースペクティブベース
  役割を考える＋その役割に沿った成果物を作成してレビューする。

  レビューアはそれぞれに異なるステークホルダーの観点でレビュー活動を行う。レビュー対象の作業成果物から各レビューアの 役割で導出する成果物を作成してみる必要がある 要件や技術的な作業成果物のレビューの場合、パースペクティブベースドリーディングが最も効果的な技法

レビューの成功要因

※太字は個人的に重要と考えるもの

• 組織的な要因

  • レビュー計画時に、計測可能な終了基準として使用できる明確な目的を定義する。
  • 達成する目的、およびソフトウェア成果物と参加者の種類とレベルに応じてレビュータイプを選択する。
  • レビュー対象の作業成果物で欠陥を効果的に識別するために適切なレビュー技法（チェックリストベース技法やロールベース技法など）を 1 つ以上使用する。
  • チェックリストは、主要なリスクに言及できるよう最新の状態に保つ。
  • 欠陥に関するフィードバックを早期および頻繁に作成者に提供して品質をコントロールするために、大きなドキュメントは小さく分割して記述およびレビューする。
  • 参加者に十分な準備時間を与える。
  • レビューのスケジュールは適切に通知する。

• 人的な要因

  • レビューの目的に対して適切な人たちに関与させる（例えば、さまざまスキルセットまたはパースペクティブを持ち、対象のドキュメントを使うことがある人たち）。
  • 静的テスト担当者は、レビューに貢献するだけでなく、レビュー対象の作業成果物の内容を把握して、有効なテストを早期に準備できると、レビューアとして価値がでる。
  • 参加者には適切な時間を割り当て、細心の注意を払って詳細にレビューしてもらう。
  • レビューアが個人でのレビュー時、および/またはレビューミーティング時に集中力を維持できるよう、レビューは対象を小さく分割して実施する。
  • 見つかった欠陥は客観的な態度で確認、識別、対処をする。
  • ミーティングは参加者にとって有意義な時間となるよう適切にマネジメントする。
  • レビューは信頼できる雰囲気で行い、レビュー結果を参加者の評価に使用しない。
  • 参加者は、自分の言動が他の参加者に対する退屈感、憤り、敵意だと受け取られないように気を付ける。
  • 特にインスペクションなど高度に形式的なレビュータイプには、十分なトレーニングを提供する。
  • 学習とプロセス改善の文化を醸成する。

わからないこと

• 3.2.1 作業成果物のレビュープロセス→ 計画で以下の記載があり、このレビュー特性が何を指しているかはわかっていない。

  レビュー特性を識別する。これには、レビュータイプ、役割、活動、チェックリストなどを含む。

• 3.2.3 レビュータイプ → インスペクションの説明で以下の記載があり、この進行役が何を指すのだろうかわかっていない。ファシリテータとあえて書いていないのだろうからファシリテータではないことはわかるが...

  レビューミーティングは、経験を積んだ進行役（作成者ではなく）が主導する。

感想

今までテストは「動的テスト」のことで、レビューが「静的テスト」と知れたのは、既知の言葉を別の言い方で表現できるので面白かったです。 内容として一番印象に残ったことは、静的テストの利点です。イメージ図を探せたのもあって一番印象に残りました。

動的テストを実行する前に欠陥を早期に検出できる。早期に検出した欠陥は、本番稼動後のようなライフサイクルの終盤に検出した欠陥よりも、はるかに安価に除去できる。

静的テストの利点を自身が効果的にするために何を意識できそうかを考えました。（抽象的な項目が多いですが...）

• 参加者に十分な準備時間を与える。
  →予め情報（レビュー対象）を共有したり、シナリオとドライランにあるようなガイドラインを先に共有する。
• レビューは信頼できる雰囲気で行い、レビュー結果を参加者の評価に使用しない。
• 参加者は、自分の言動が他の参加者に対する退屈感、憤り、敵意だと受け取られないように気を付ける。
  →欠陥を指摘してくれたことに感謝を示す。リスペクトした態度で接する。欠陥を出すときは強く否定しない（特に人格を否定しない）。レビュー結果で人を判断しない。

学習だけでなく自分ができることを考えてみましたが、なかなか簡単ではないですね...！ですが、できることを増やしていきたいので、少しずつでも意識できるようにしてみます！

参考にさせていただいた情報

80号：レビュー技法の適用｜Kouichi Akiyama｜note

http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf

*1:http://www.jaspic.org/event/2009/SPIJapan/keynote/SJ9keynote.pdf及び、「ソフトウェア開発 201の鉄則(日経BP社)」より引用

*2:Among usの印象が強すぎる