皆さん、こんにちは。
引き続き、JSTQB Foundationのシラバスの解説を行っていきたいと思います。
今回は、以下の項目について、私の見解も含めて、述べていきたいと思います。
3.静的テスト
静的テストは、対象のソフトウェアの実行は必要とせず、レビューや作業による成果物を静的解析などで評価するテストです。
テスト担当者がテストを実施後、その結果をテスト管理者やユーザーがレビューを行うといったことも該当します。
■3.1静的テスト
静的テストは、テスト結果の内容に限らず、以下のような内容も対象となります。
□3.1.1 静的テストで検査可能な作業成果物
・仕様書
・ユーザーストーリー、受け入れテスト等の基準
・アーキテクチャー、設計仕様書
・プログラムコード
・テスト計画書、テストケース、テスト手順、自動化スクリプトなどのテストウェア
・ユーザーガイド、マニュアル
・Webページ
・契約書、プロジェクト計画書、スケジュール、予算
・アクティビティ図など
上記のような読んで理解できる作業成果物に適用が可能です。
書物の推敲のような役割で、誤字脱字、文法、読みやすさなどを評価します。
□3.1.2 静的テストの利点
静的テストの利点は次のような事が挙げられます。
・ソフトウェア開発ライフサイクルの初期に実行することで、早期に欠陥を検出が可能
・早期に欠陥を検出することで、コストがかからず除去、訂正が可能
・動的テストでは容易に検出できない欠陥を識別することが可能
・開発上流工程の要件、要求の不整合、あいまい性、矛盾など明らかにし、設計やコーディング時の欠陥の混入を防止することが可能
・開発にかかるコスト、時間の削減が可能
・レビューの参加過程で、チームメンバー間のコミュニケーションの改善が可能
以上のような利点があり、主に開発フェーズのコスト削減、品質向上、コミュニケーション向上が大きな強みであると考えます。
□3.1.3 静的テストと動的テストの違い
静的テスト、動的テストの大きな違いは以下となります。
静的テスト
・ソフトウェア実行時ではなく、作業成果物に対して欠陥の検出ができます。
・作業成果物の整合性、及び内部品質の向上をねらえます。
動的テスト
・ソフトウェア実行時に、欠陥の検出が行えます。
・外部から見える振る舞い焦点をおく傾向があります。
■3.2レビュープロセス
レビューには、非形式的なものから、公式的なものが様々あります。
レビューの焦点は、レビュー目的として合意したこと（例：欠陥、内容、メンバー間の教育、判断基準など）により異なります。
□3.2.1 作業成果物のレビュープロセス
レビューのプロセスは、以下内容となります。
・計画：レビューの範囲、工数見積もり、レビュー参加者、開始基準、終了基準等を定めます。
・レビュー実施：作業成果物、資料を共有し、計画内容に沿ってレビューを実施します。
・懸念事項の共有と分析：潜在的な欠陥など、レビューの場で意見交換、その担当者などを割り当て、レビューで見つけた欠陥を評価し、レビュー判定を行います。
・修正と報告：レビューで見つけた欠陥に対して、インシデントレポートを作成し、その担当者が修正を行います。修正後は、インシデントレポートのステータスを更新し、メトリクスを収集します。
□3.2.2 形式的レビューでの役割と責務
形式的なレビューで一般的な役割は、以下となっています。
・作成者：レビュー対象の作成者
・マネージャー：レビューの計画、実行決定、マネジメントを行う
・ファシリテーター（モデレーター）：レビューミーティングの運営、進行役
・レビューリーダー：レビューの責任者、参加者、レビューの期間、場所など決定
・レビューア：特定分野の専門家、テスト担当者、プログラマー、ユーザー、オペレーターなど
・書記：レビューミーティングでの欠陥、未解決事項、決定事項を記録
上記太字の部分は、過去verのシラバスでは、明記されておらず、最新版のシラバスから追記された内容となります。
□3.2.3 レビュータイプ
レビュータイプは以下があります。
こちらの各レビュータイプは、JSTQB Foundation Levelの試験でよく出題される内容となっていますので、しっかり把握しておきましょう。
下のレビュータイプに行くほど、公式的なものとなっています。
非公式レビュー
主な目的は欠陥の検出で、ペアプログラミングなど設計やコードをレビューするなど
ウォークスルー
主な目的は欠陥の発見、プロダクトの改善、検討、仕様等の準拠評価など
テクニカルレビュー
主な目的は、合意の獲得、潜在的な欠陥の検出など
インスペクション
主な目的は、潜在的な欠陥の検出、作業成果物の品質向上、信頼の積み上げ、欠陥防止など
□3.2.4 レビュー技法の適用
レビュー技法、そのあとのレビューの成功要因は、過去のシラバスでは掲載されていませんでした。
こちらは、実際の業務内でも有効な内容となりますので、押さえておきたい内容となります。
アドホック
・レビューアは作業成果物を順番に読んで懸念事項を識別するごとに記録に残す。
チェックリストベース
・レビュー開始前に配布されるチェックリストを使用して懸念事項を検出する。
・レビュー対象の作業成果物ごとにチェックリストを用意し、チェックリストは定期的にメンテナンスを行う。
・レビュー時は、チェックリストに沿って従うだけでなく、レビュー時にチェックリスト以外に気づいた内容も検出することが重要。
シナリオとドライラン
・作業成果物を読むための構造化されたガイドラインをレビューアに提供。
・レビューアはシナリオを使用して、作業成果物に対して「ドライラン（予行練習）」を行う。
ロールベース（ロールベースドレビュー技法）
・レビューアは個々のステークホルダーの役割の観点から作業成果物を評価。
・典型的な役割として、熟練者、初心者、年配者、子供などや、ビューア、エディター、管理者などがある。
パースペクティブベース（パースペクティブベースドリーディング）
・レビューアはそれぞれに異なるステークホルダーの観点でレビュー活動を行う。
・典型的なステークホルダーとしては、エンドユーザー、マーケティング担当者、設計者、テスト担当者、運用担当者などがある。
□3.2.5 レビューの成功要因
レビューを成功させるためには、適切な種類及び適切な技法の適用を検討することが必要です。
そもそも、プロジェクトによっては、レビューの実施すら、ままならないケースもあります。
そういったときにこそ、レビューにあてる時間を確保して、レビューを実施することが重要です。
それにより、課題の洗い出し、問題点など見える化していくと考えます。
レビューは、プロジェクト、同じチーム内の人とのコミュニケーションを活性化する場であると、私は考えます。
コミュニケーションが不十分であるがゆえに、ソフトウェア、成果物の欠陥などの問題点が発生します。
コミュニケーションを活性化するためにも、レビューミーティングという機会を定期的設けることは重要だと考えます。
■最後に
いかがでしたでしょうか。
今回は静的テストについて、述べてみました。
レビュー自体、あまり実施されないプロジェクトも中にはあると思います。
テスト担当者、開発者に限らず、プロジェクトに関わる関係者にもレビューの大切さを知ってもらえれば幸いです。
最後まで読んで頂き、ありがとうございました。
サイトトップへ
https://susakiworks.com/
ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応
