#paper [http://jstqb.jp/syllabus.html](http://jstqb.jp/syllabus.html) [ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03](http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf) JSTQB (Japan Software Testing Qualifications Board) は、 ISTQB (International Software Testing Qualifications Board) の日本運営組織である。 このシラバスは、ISTQB が出してるものを日本語訳しているもので JSTQB Foundation レベルの認定試験に出題される内容が書いてある。 ## テストの7原則 - テストは欠陥があることは示せるが、欠陥がないことは示せない - 欠陥がないことは証明できない - テストにより、ソフトウェアに残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、正しさの証明とはならない - 全数テストは不可能 - 全ての入力ケースでテストするのは非現実的 - 代わりにリスク分析、テスト技法、および優先度によりテストにかける労力を集中すべきである - 早期テストで時間とコストを節約 - 早い段階で欠陥を見つけるために、静的テスト、動的テスト活動の両方をソフトウェア開発ライフサイクルのなるべく早い時期に開始すべきである。(シフトレフトとも呼ばれる) - 静的テスト : テストを実行することなく、要件定義のレビューやユースケースの分析などの成果物をレビュー、関与することでそもそもの要件のレベルでの (考慮漏れなども含む) 欠陥を見つける - > ソフトウェア開発ライフサイクルの初期に適用すると動的テストを実行する前に欠陥を早期に検出できる。早期に検出した欠陥は、本番稼働後のようなライフサイクル終盤に検出した欠陥よりも、はるかに安価に除去できる。 - 動的テスト : テストを実行することにより欠陥を見つける - > テスト担当者が要件レビューやユーザーストーリーに洗練作業に関与することにより、これらの作業成果物の欠陥が検出できる。要件に対する欠陥の検出と除去を行うことにより正しくない、またはテストできないフィーチャーが開発されるリスクを低減できる - 欠陥の偏在 - 血管や運用時の故障の大部分は、特定の少数のモジュールに集中する - 欠陥の偏在を予測し、テスト運用での実際の観察結果に基づいてリスク分析を行う - 殺虫剤のパラドックスにご用心 - 同じテストを何度も繰り返すと最終的には新しい欠陥が見つけれなくなる。テストとテストデータの見直しを定期的に行う。ただし自動化されたリグレッションテストの場合は、同じテストを繰り返すことでリグレッションが低減しているという有益な結果を示すことができる - テストは状況次第 - アプリケーションの特性によっても開発のスタイル (アジャイル or シーケンシャル) によってもテストの実行方法は変わってくる - 「バグゼロ」の落とし穴 - 可能性のある欠陥を全て検出できると期待する組織があるが、これは不可能である。大量の欠陥を検出して修正するだけでシステムを正しく構築できると期待することも誤った思い込み。(使いにくいシステムやユーザーの期待を満たさないシステムなどが構築されてしまう恐れがある) ## テスト活動とタスク - テスト計画 - テストのモニタリングとコントロール - テスト分析 - 何をテストするか - テスト設計 - どうテストするか - テスト実装 - テスト実行 - テストスイートの実行 - テスト完了 ## テストレベル - コンポーネントテスト - ユニットテストやモジュールテストとも呼ばれる - コンポーネントの機能的/非機能的振る舞いが設計および仕様通りであることの検証 - 作ったものが正しいかの検証 - コードを開発した開発担当者が行うことが一般的である - 統合テスト - コンポーネント統合テストとシステム統合テストにレベルが分かれる - コンポーネント統合テスト - 1つのシステム内で統合するコンポーネント間の相互処理とインターフェースに焦点をあててテストする - コンポーネントテストの後に実施して自動化するのが一般的である - システム統合テスト - システム、パッケージ、マイクロサービス間の相互処理とインターフェースに焦点をあててテストする - アプリケーションでは、実際のAPIや実際のWebViewのコンテンツなどでテストを行うイメージ - マイクロサービスなどでは実際に他のサービスとの連携など一覧のシナリオをウォークスルーする - ここでのテストは統合だけに集中すべきである、コンポーネントテストでカバー済みの個々のモジュール機能ではなくモジュール間のコミュニケーションに焦点をあてる - システムテスト - システムが実行するエンドツーエンドのタスクとタスク実行時にシステムが示す非機能的振る舞いといったシステムのプロダクト全体の振る舞いや能力に焦点をあてる - 受け入れテスト - システムが導入に向けて準備できているかどうか、および顧客 (エンドユーザー) が使用できるかを評価できる - 受け入れテストでは、欠陥を見つけることは目的ではない ## テストタイプ - 機能テスト - システムが「何を」すべきかをテストする - 機能カバレッジを用いて十分かを計測できる - 非機能テスト - システムが「どのように上手く」振舞うかのテスト - e.g. パフォーマンスが落ちない、エラーメッセージが適切など、カオスエンジニアリングでの Steady State からどれだけ外れないかなど ## テスト技法 - ブラックボックステスト : テスト対象の入力と出力に着目し、その内部構造は参照しないテスト - 同値分割法 - 同等に処理されると想定したデータを全てを同じパーティションに振り分ける - それぞれのパーティションの特徴的に、有効同値パーティションと無効同値パーティションと呼び分ける - それぞれのパーティション内から少なくとも1つの値をテストケースでカバーする必要がある - 境界値分析 - 同値分割法 の拡張で同値に分割したパーティションの中でも境界に着目する - e.g. -  - ディシジョンテーブルテスト - 条件とアクションを1つのテーブルで表現して条件を全て列挙するパターン ディシジョンテーブル | 条件A | Y | Y | N | N | | -- | -- | -- | -- | -- | | 条件B | Y | N | Y | N | | アクションX | X | - | - | - | | アクションY | - | - | - | X | | アクションZ | - | - | X | - | - 状態遷移テスト - 状態遷移図を書いて状態の遷移をそれぞれのパターンでテストすること - ユースケーステスト - ユースケース図を書いて、それぞれのユースケースのテストをアクターごとに実施する - ホワイトボックステスト : テスト対象内の構造と処理に重点を置くテスト - ステートメントテストとカバレッジ - あるコードの命令が全て実施されるようにテストすること - いわゆる C0 カバレッジに着目する - ディシジョンテストとカバレッジ - if や switch などの条件文の全てのパターンを網羅するテスト - いわゆる C1 カバレッジの着目する - 経験ベーステスト : 開発担当者、テスト担当者、ユーザーの経験を活用する - エラー推測 - 探索的テスト - チェックリストベースドテスト ## テスト組織 独立したテスト組織は開発者とテスト担当者の間の認知的バイアスの違いによってテスト担当者はより効果的に欠陥を発見できる。以下独立性の低い順番に状態を列挙。 - 独立したテスト担当者不在 (開発担当者が自分のコードをテストするのみである) - 開発チーム、またはプロジェクトチーム内に所属する、独立した開発担当者、またはテスト担当者 (開発担当者が同僚の成果物をテストすることもある) - 組織内にある独立したテストチームまたはグループで、プロジェクトマネージャーや上位管理者の直属組織 - 顧客またはユーザーコミュニティから派遣された独立したテスト担当者、または、使用性、セキュリティ、性能、規制/標準適合性、移植性など、ある特定のテストタイプを専門に行う独立したテスト担当者 - 組織外の独立したテスト担当者。オンサイト (インハウス) またはオフサイト (アウトソーシング)で作業する 独立したテスト組織には欠点もあるのでどのレベルの独立性を求めるかはそれぞれ考える必要がある - 開発チームから隔絶されると、協力者関係の欠落、開発チームへのフィードバック提供の遅延、開発チームとの対立を招くことがある。 - 開発担当者の品質に対する責任感が薄れることがある。 - 独立したテスト担当者は、ボトルネックとして見られることがある。 - 独立したテスト担当者にテスト対象の情報などの重要な情報が伝わらないことがある。 -> こういったデメリットは、静的テストを行うことで解消が可能になる ## 感想 - テスト技法とか知ってたけど、改めてこういう資格制度に沿った説明がなされていてよかった。 - 近年の [[Agile Testing : A Pratical Guide for Testers and Agile Teams]] や [[More Agile Testing - Learning Journeys for the Whole Team]] なども引用にしていて、シフトレフトはこのレベルで公式的な活動として書かれてるのは驚きであった