はじめに
続編です。
- テストを学びたくてJSTQBのFLシラバスを読んでみた〜その1 テストの基礎〜
- テストを学びたくてJSTQBのFLシラバスを読んでみた〜その2 ソフトウェア開発ライフサイクル全体を通してのテスト〜
- テストを学びたくてJSTQBのFLシラバスを読んでみた〜その3 静的テスト〜 ← ここ
注意事項
あくまで、JSTQBのFLシラバス理解に向けた個人的メモです。
「これを読んだら FLシラバスが習得できます！」とかじゃないです。全然違います。
当然ですけど、こんな記事より「JSTQBのHP - JSTQB公認研修コース」に参加するのが正しい道です。（もしくは自力でシラバスを読むか。）
※本記事は「Foundation Level シラバス 日本語版 Version 2018.J03」を対象にしています。
3 静的テスト
135min
キーワード
ひとまずぱっと見、分からなかったものだけ調べるようにしてみる。
Qbookに載ってた用語
| 用語 | 意味 | Qbookの用語説明(JSTQB準拠) |
|---|---|---|
| インスペクション | ピアレビューの一種。ドキュメントの目視検査により、欠陥を検出する方法。 | link |
| ピアレビュー | 欠陥を識別して修正するため、プロダクト開発を担当している同僚がソフトウェア成果物をレビューすること。 | link |
Qbookに載ってない用語
| 用語 | 意味 | 参照先 |
|---|---|---|
| パースペクティブベースドリーディング | 異なるステークホルダーの視点でレビュー対象を読む | ・ITmedia - “読み方”を知って、レビューをもっと効果的に (4/4) ・slideshare - ISO/IEC DIS 20246 についての(ごく簡単な)説明 |
| ロールベースドレビュー | 異なるステークホルダーの視点でレビュー対象を評価する | slideshare - ISO/IEC DIS 20246 についての(ごく簡単な)説明 |
| シナリオベースドレビュー | ガイドライン（シナリオ）有りきでのレビュー。リスク情報を付加することでより深く見れる。 | slideshare - ISO/IEC DIS 20246 についての(ごく簡単な)説明 |
「パースペクティブベースドリーディング」と「ロールベースドレビュー」の違いがピンと来ないな・・・
「ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応」によると、「ロールベースドレビュー」の技法の一つとして、「パースペクティブベースドリーディング」がある、という表現だった。
「パースペクティブベースドリーディング」では、作業成果物を概要レベルで作るとも書かれていたけど、それはきっと、想像の精度を高めるためだろうか？う～ん、文章で説明されるより、実際にどうやるかを見てみたいところ・・・
一盛り上がりしていたっぽい用語
形式的レビュー/非形式的レビュー
そうなのでしょうか？
— あきやま🎃 (@akiyama924) 2019年8月29日
私は「公式」の方が、「レビュー対象について正式に確定する」という意味が伝わるので良かったのになと思っています。
「形式的」と言われると、「本当は無くて良いのだけど決まっているからやらなくっちゃね」って印象なのでミスリードしそう。
ではなんて訳すのがいいのでしょうか？JSTQBの訳が完璧ではないことは理解してますので、参考までにアイデアください。ただし、公式は、officalの訳語として使ってます。offcialとformalは別の言葉にすべきだという判断がJSTQBではありました。
— Tsuyoshi Yumoto (@yumotsuyo) 2019年8月29日
困った時のカタカナが良いと思います。
— あきやま🎃 (@akiyama924) 2019年8月29日
つまりは「形式的」を「フォーマル」に全文置換するのが良さそう。
ありがとうございます。非形式的レビューをインフォーマルレビューとするのもセットで検討します。
— Tsuyoshi Yumoto (@yumotsuyo) 2019年8月29日
3.1 静的テストの基本
静的テスト技法では、動的テスト技法（テスト対象のソフトウェアの実行が必要）と異なり、作業成果物を人手で調査（すなわち、レビュー）したり、コードや他の作業成果物をツール主導で評価（すなわち、静的解析）したりする。
静的テストでは、どちらの種類でもテスト対象のコードやその他の作業成果物を実際に実行することなくアセスメントする。
レビューとかも含むのか。勝手に後者だけ（checkstyleとかfindbugsとか）をイメージしてた。
K1 さまざまな静的テスト技法を使用して検査できるソフトウェア成果物の種類を認識する。
ほとんどの作業成果物は静的テスト（レビュー、静的解析、または両方）を使用して調査できる。
ほーん。できないのは・・・？
レビューは、読んで理解できるあらゆる作業成果物に適用できる。
「読んで理解できるあらゆる作業成果物」が対象なのか。
バイナリファイルは無理だよねってことかな。バイナリが読めるなら別か。労力に見合うかは分からんけど。
K2 例を用いて、静的テストの価値を説明する。
静的テストはさまざまな利点をもたらす。
静的テストは、ソフトウェア開発ライフサイクルの初期に適用すると動的テストを実行する前に欠陥を早期に検出できる（例えば、要件/設計仕様レビュー、プロダクトバックログを洗練させる作業など）。
早期に検出した欠陥は、本番稼動後のようなライフサイクルの終盤に検出した欠陥よりも、はるかに安価に除去できる。
「早く見つけたほうが安上がりだよね」ってのは分かる。基本的にそうだと思う。
他の作業成果物の更新や確認/リグレッションテストを実行するコストを考慮した場合、動的テスト技法を使用してテスト対象の欠陥を見つけて修正するよりも、静的テスト技法を使用して欠陥を検出し、即座に修正する方がはるかに安価である。
動的テストよりも安くなるか？については、ケースバイケースな気もするけど、どうなんだろう。。。
簡単なリファクタリングとかなら、コードレビューするよりも、jUnit回したほうが早く安く検出できると思う。
まぁいずれにせよ、テスト手法の選択には「安価かどうか」ってのは重要な判断軸なのは理解。
静的テストのその他の利点には、以下のものがある。
- 欠陥の検出と修正をより効率的に、しかも動的テストを実行する前に行うことができる。
- 動的テストでは容易に検出できない欠陥を識別できる。
- 要件の不整合、曖昧性、矛盾、欠落、不正確性、冗長性を明らかにして、設計時またはコーディング時に欠陥が混入するのを防止できる。
- 開発の生産性を向上できる（設計の改善、保守性の高いコードなど） 。
- 開発にかかるコストと時間を削減できる。
- テストにかかるコストと時間を削減できる。
- ライフサイクルの終盤または本番リリース後に検出される欠陥数が減少し、ソフトウェアの存続期間にわたる全体的な品質コストを削減できる。
- レビューへの参加過程でチームメンバー間のコミュニケーションを改善できる。
全般的に、品質・コストの改善だけど、最後だけ「コミュニケーション」を指してるな。
K2 静的技法と動的技法について、目的、識別対象の欠陥の種類、ソフトウェアライフサイクル内でのこれらの技法の役割を考慮して、違いを説明する。
静的テストと動的テストは、作業成果物の品質を評価すること、および可能な限り早期に欠陥を識別することなど、同じ目的に使える（1.1.1 節を参照）。
静的テストと動的テストは、それぞれに異なる種類の欠陥を検出するため、相互に補完する関係にある。
静的テストは「動的テストでは容易に検出できない欠陥を識別できる。」ってのもあるので、補完関係なのは「そうだな」って感じ。
静的テストの主な特徴の 1 つは、ソフトウェア実行時に欠陥により引き起こされた故障を識別するのではなく、作業成果物の欠陥を直接検出することである。
欠陥は、故障を引き起こすことなくきわめて長期間にわたって作業成果物に潜んでいることがある。
この欠陥が潜んでいるパスはほとんど実行されることがないか、到達することが難しいので、このような欠陥を偶然検出できる動的テストを構築および実行することは容易ではない。
静的テストでは、はるかに少ない工数で検出できる。
また、動的テストが外部から見える振る舞いに焦点を置くことが典型的であるのに対し、静的テストは作業成果物の整合性と内部品質を向上させることも特徴である。
動的テストの検証は、インプットと期待アウトプットを定義して検証するパターンがほとんどだからだろうな。
静的テストは、「文章として読めるか？」とか「テストしやすいか？」とか、そういう観点になることが多いからだろうな。
動的テストで検証した方が早そうなことを、静的テストで頑張ってやるのは無駄なんだろうな。
静的テストは動的テストに比べて、以下の欠陥を早期かつ安価に検出して修正できる。
- 要件の欠陥（例えば、不整合、曖昧性、矛盾、欠落、不正確性、冗長性）
- 設計の欠陥（例えば、非効率なアルゴリズムやデータベース構造、高い結合度、低い凝集度）
- コードの欠陥（例えば、値が定義されていない変数、宣言されているが使用されることのない変数、到達不能コード、重複したコード）
- 標準からの逸脱（例えば、コーディング標準を遵守していない）
- 正しくないインターフェース仕様（例えば、呼び出し側のシステムと呼び出される側のシステムで異なる単位の使用）
- セキュリティの脆弱性（例えば、バッファオーバーフローが発生する可能性）
- テストベースのトレーサビリティもしくはカバレッジが不十分もしくは不正確（例えば、受け入れ基準に対するテストケースが欠落している）
うぃっす。
さらに、保守性欠陥のほとんどは、静的テストでのみ検出できる（例えば、不適切なモジュール化、低いコンポーネント再利用性、分析が困難で新しい欠陥の混入なしに修正することが困難なコード）。
コードのスパゲッティ化とかは、SonarQubeなどの静的解析ツールで「サイクロマチック複雑度」を算出すれば、検出できるし、静的テストでのみ検出できるってのは実際そうだろうな。
jUnitなどの動的テストじゃ検出できないな。
保守性欠陥：標準化/規約違反、コードのスパゲッティ化、デッドコードの発生
SPCシンポジウム - 欠陥構造の可視化によるトラブルの早期発見と未然防止～欠陥を中心に置くことで可能となるＱＡのコト作り～より
3.2 レビュープロセス
レビューには、非形式的なものから、形式的なものまでさまざまな種類がある。
非形式的レビューは、定義したプロセスに従わず、レビュー結果を形式的に文書化しないことが特徴である。
形式的レビューは、チームで参加し、レビューの結果とレビューを行う際の手順を文書化することが特徴である。
レビュープロセスの形式は、ソフトウェア開発ライフサイクルモデル、開発プロセスの成熟度、レビュー対象の作業成果物の複雑さ、法律や規制から生じる必要性、そして／または監査証跡の必要性などの要素で決まる。
用語のとこで整理されている流れを受けた上で、以下だと解釈した。
- フォーマルレビュー（形式的レビュー）：ガイドラインが定められたレビュー
- インフォーマルレビュー（非形式的レビュー）：ガイドラインが定められていないレビュー
ISO 標準（ISO/IEC 20246）には、作業成果物のレビュープロセスの詳細が、役割やレビュー技法を含めて説明されている。
参考になるヤツ：「slideshare - ISO/IEC DIS 20246 についての(ごく簡単な)説明」
K2 作業成果物に対するレビュープロセスの活動を要約する。
細かい話は本文参照として、概略だけ。（割と普通にやっている範囲だったので、だいぶ省略。）
- 計画
- レビューの開始
- 個々のレビュー（すなわち、個々の準備）
- 懸念事項の共有と分析
- 修正と報告
K1 形式的レビューにおけるさまざまな役割と責務を認識する。
細かい話は本文参照として、概略だけ。（割と普通にやっている範囲だったので、だいぶ省略。）
- 作成者
- マネージャー
- ファシリテーター（モデレーターと一般的に呼ばれる）
- レビューリーダー
- レビューア
- 書記（記録係）
K2 さまざまなレビュータイプ（非形式的レビュー、ウォークスルー、テクニカルレビュー、およびインスペクション）の違いを説明する。
理解するための特徴的なポイントだけ抜粋。
- 非形式的レビュー：形式的なプロセスに基づかない。
- ウォークスルー：シナリオ、ドライラン、シミュレーションの形態を取る場合がある。
- テクニカルレビュー：レビューアは、作成者の技術領域の同僚、および技術分野が同じ、または別の専門家である。
- インスペクション：ルールやチェックリストに基づいたプロセスで進行し、形式に沿ったドキュメントを作成する。
K3 欠陥を検出するために、作業成果物にレビュー技法を適用する。
理解するための特徴的なポイントだけ抜粋。
- アドホック：一般的に、レビューアは作業成果物を順番に読んで懸念事項を識別するごとに記録に残す。
- チェックリストベース：チェックリストを使用して懸念事項を検出する。
- シナリオとドライラン：レビューアはシナリオを使用して、作業成果物の期待する使い方に基づいて、作業成果物に対して「ドライラン」を行う。
- ロールベース：レビューアは個々のステークホルダーの役割の観点から作業成果物を評価する。
- パースペクティブ：ロールベースのレビュー技法と同じく、レビューアはそれぞれに異なるステークホルダーの観点でレビュー活動を行う。
K2 レビューの成功に貢献する要因を説明する。
組織的な要因
- レビュー計画時に、計測可能な終了基準として使用できる明確な目的を定義する。
- 達成する目的、およびソフトウェア成果物と参加者の種類とレベルに応じてレビュータイプを選択する。
- レビュー対象の作業成果物で欠陥を効果的に識別するために適切なレビュー技法（チェックリストベース技法やロールベース技法など）を 1 つ以上使用する。
- チェックリストは、主要なリスクに言及できるよう最新の状態に保つ。
- 欠陥に関するフィードバックを早期および頻繁に作成者に提供して品質をコントロールするために、大きなドキュメントは小さく分割して記述およびレビューする。
- 参加者に十分な準備時間を与える。
- レビューのスケジュールは適切に通知する。
- マネージャーがレビュープロセスを支援する（例えば、プロジェクトスケジュールでレビューに十分な時間が割り当てられるようにする）。
人的な要因
- レビューの目的に対して適切な人たちに関与させる（例えば、さまざまスキルセットまたはパースペクティブを持ち、対象のドキュメントを使うことがある人たち）。
- テスト担当者は、レビューに貢献するだけでなく、レビュー対象の作業成果物の内容を把握して、有効なテストを早期に準備できると、レビューアとして価値がでる。
- 参加者には適切な時間を割り当て、細心の注意を払って詳細にレビューしてもらう。
- レビューアが個人でのレビュー時、および／またはレビューミーティング時に集中力を維持できるよう、レビューは対象を小さく分割して実施する。
- 見つかった欠陥は客観的な態度で確認、識別、対処をする。
- ミーティングは参加者にとって有意義な時間となるよう適切にマネジメントする。
- レビューは信頼できる雰囲気で行い、レビュー結果を参加者の評価に使用しない。
- 参加者は、自分の言動が他の参加者に対する退屈感、憤り、敵意だと受け取られないように気を付ける。
- 特にインスペクションなど高度に形式的なレビュータイプには、十分なトレーニングを提供する。
- 学習とプロセス改善の文化を醸成する。
わかる。
さいごに
今回も135minどころじゃないけど、今までよりは短め。
まだまだ先は長い・・・
継続して考え続けたい
（ゴールイメージがそこまで沸いてないもの）
- アドホックレビューが当たり前になるような文化の醸成
- 静的テストと動的テストのバランス
以上です。