みなさん、こんにちは！ ゆーすけです。JSTQB CBT試験みなさん受けてますかっ！？CBT形式に切り変わって一か月以上たち、社内での非常に受けやすくなった、という声がちらほらとあります。※特に今まで開催のなかった/少なかった函館、仙台拠点のメンバーにとっては一気に距離が近くなったのではないかと思っています！ということで、JSTQBの学習のススメ連載の5回目となります！
▼1～4回のおさらいです！
1回目 JSTQBってなんだろう？→Foundation Levelから始めよう
2回目 Foundation Levelの構成ってどうなっているんだろう？
3回目 テスト基礎について
4回目 テストのライフサイクルについて
5回目となる今回は予告通り、静的テストに関するまとめを行っていきたいと思います。
繰り返しになりますが、JSTQB Foundation Levelの構成は以下のようになっています。
１：テストの基礎
２：ソフトウェア開発ライフサイクル全体を通してのテスト
３：静的テスト ←今回はココ
４：テスト技法
５：テストマネジメント
６：テスト支援ツール
静的テストって？
JSTQB FLの静的テストの項目では、「静的テストとは」「レビュープロセスとは」という内容で占められているので、まずはFLでは
「動的テストと静的テストの違い」
「静的テストではどういったものを対象とできるのか」
「静的テストのメリットとは」
「レビューにはどういったものがあるのか」
といった部分をしっかりと覚えて、次のステップに進めるようにしましょう！
静的テストと動的テストの違い、および静的テストの対象とは
「静的テストとは何か」という話をする前に、テストを大きく2つ分けるとすると「動的テスト」と「静的テスト」というカテゴリになります。この二つのテストはJSTQBのソフトウェアテスト標準用語集Version 2.3.J01によると
・動的テスト：コンポーネントやシステムのソフトウェアを実行させて確認するテスト。
・静的テスト：ソフトウェア開発の成果物(要件、設計、又は、コードなど)の実行をせずに実施する成果物のテスト。たとえば、レビュー、静的解析など。となっています。
では、この「コンポーネントやシステムを実行しない静的テスト」でどうやって品質活動を行うか、というと、FLシラバスには静的テストの対象例としては、下記のものがリストアップされています。
• 仕様（ビジネス要件、機能要件、セキュリティ要件など）
• エピック、ユーザーストーリー、受け入れ基準
• アーキテクチャーおよび設計仕様
• コード
• テストウェア（テスト計画書、テストケース、テスト手順、自動化テストスクリプトなど）
• ユーザーガイド
• Web ページ
• 契約、プロジェクト計画、スケジュール、予算計画
• 構成のセットアップとインフラストラクチャーのセットアップ
• モデルベースドテストで使用するアクティビティ図などのモデル
そして、これらのものに対して、
・人ベースで行うことを「レビュー」
・ツールベースで行うことを「静的解析」
とさらに分類しています。
JSTQBでは様々な視点でテストを分類しているので、一旦簡単にまとめると以下のようになります。
静的テストのメリットとは
動的テストと静的テストの違いは、対象のコンポーネント/システムを実行するかしないか、というところにあります。つまり静的テストの最大のメリットは「システムがまだ実行できる状態ではなくてもテストができる」というところにあります。テストの正解には「テストの7原則」というものがあります（3回目で軽く触れています）その中の原則の一つに「早期テストで時間とコストを削減」という内容も記載されており、初期テストの重要性を強く訴えかけています。静的テストは、「システムがまだ実行できる状態ではなくてもテストができる」という観点から、動的テストよりも早期テストが可能になるため、コストメリットが非常に高くなるケースがあります。また、静的テストの場合は不具合が発生しないよう根治、予防という意味合いも強く、初期品質向上という貢献を果たすことができるといえます。また別記事にも記載していますが、
・結合テストやシステムテストで確認することができる不具合は55%程度と言われている。
・テストをより上流から行うことで本番障害にいたす潜在不具合件数は軽減できる。
といった所謂シフトレフトの考え方にも繋がっていきます。
レビューにはどういったものがあるのか
レビューには様々なタイプがあり、そのタイプによってレビュープロセスが異なっていきます。先ほどの図解にFLシラバス記載のレビュータイプを追加すると、以下のようになります。
一般的には上に記載のレビュータイプほど公式度合いが高いと言われていて、公式度が高いほどレビュー開催に至るまでに準備や、レビュー時の手順、参加者の役割定義が厳密に決められることがあります。逆に公式度が低い（非公式である）という場合は、組織、プロジェクトレベルで行うのではなく、個人レベルで行うことを指します。レビュータイプに関しては、どのレビューが優れている、というわけではなく、状況（レビュー対象、レビューレベル、レビューに対する準備工数、公式的に行う必要があるか）によって使い分けが大事になってきます。
使い分けの考え方としては、
| リスク | 新技術使用、契約関連など |
| ミッションクリティカル | ビジネスクリティカル、セーフティクリティカル、ライフクリティカル |
| QCD関連 | 品質、コスト（予算）、デリバリー（納期） |
| 各種リソース | 人、スキル |
テストアプローチの一つとして、ハイリスク、ミッションクリティカルなシステムには公式度が高いレビューを使用し、ローリスクや予算、リソースに限りがあるシステムでは公式度の低いレビューを活用する、といった判断をプロジェクト毎に戦略的に行っていきます。上記レビューも含め、様々なレビュータイプの詳細は、別途こちらの記事にも詳しく記載されていますので、さらなる学習をしたい方はこちらの記事にも目を通していただければと思います。
次回
次回はいよいよ「テスト技法」のまとめ会になる予定です。テスト技法に関しては、座学よりも実地に重きを置く領域だと思いますので、テスト技法に関してはさらっとまとめて、残り「テストマネジメント」「テスト支援ツール」のまとめと、最後まで駆け抜けたいと思います！！
シリーズ一覧
JSTQB学習のススメ #1 〜JSTQBとは〜
JSTQB学習のススメ #2 〜Foundation〜
JSTQB学習のススメ #3 〜Foundation〜
帰ってきた JSTQB学習のススメ #4 〜Foundation〜
JSTQB学習のススメ #5 〜Foundation〜
JSTQB学習のススメ #6 〜Foundation〜
