はじめに
今日は午前中に区役所に行き、税金関連の手続きをしてきました。
今日のやり取り:「独身ですか?」「はい、独身です」(2回目
午後からはスタンディングをしながら、JSTQBの学習をしていました。
学習内容
今日は久々にバルカレを再受講しました。2倍速で1章から6章まで聞いて、その後、シラバスを確認したり、青本の演習問題を解きました。
青本の演習問題ですが、2回目のためスコアが上がっていました。
正解率87.5%
本試験でも同じ問題が出てほしいところです。
今日のポイント
見積もり
シーケンシャル開発プロジェクト
- 欠陥除去モデル:メトリクスを基にしたアプローチ
- ワイドバンドデルファイ:専門家によるアプローチ
テストマネージャーのタスク
- 組織のテストポリシーやテスト戦略を開発もしくはレビューする。
- プロジェクトの背景を考慮した上で、テスト目的とリスクを理解してテスト活動を計画する。これにはテストアプローチの選択、テストにかかる時間/工数/コストの見積り、リソースの獲得、テストレベルやテストサイクルの定義、欠陥マネジメントの計画を含む。
- テスト計画書を作成し更新する。
- プロジェクトマネージャー、プロダクトオーナーなどの間でテスト計画書の内容を調整する。
- テスト側の考え方を、統合計画などの他のプロジェクト活動と共有する。
- テストの分析、設計、実装、実行の開始を宣言し、テスト進捗とテスト結果をモニタリングし、終了基準(または完了(done)の定義)のステータスを確認し、そしてテスト完了活動をファシリテートする。
- テスト進捗レポートとテストサマリーレポートを、収集した情報に基づいて準備し配布する。
- (テスト進捗レポートおよび/またはプロジェクトで既に完了しているテストのテストサマリーレポートで報告済みの)テスト結果やテスト進捗に基づいて計画を修正し、テストコントロールのために必要なあらゆる対策を講じる。
- 欠陥マネジメントシステムのセットアップと、テストウェアの適切な構成管理を支援する。
- テスト進捗の計測、およびテストや対象プロダクトの品質の評価のために、適切なメトリクスを導入する。
- テストプロセスで使うツールの選択と実装を支援する。これには、ツール選択(および、購入および/またはサポート)のための予算の提案、パイロットプロジェクトのための時間と工数の割り当て、継続的なツール使用支援の提供を含む。
- 構築するテスト環境を決定する。
- 組織内のテスト担当者、テストチーム、テスト専門職を昇格および支持する。
- テスト担当者のスキルアップとキャリアアップを促す(トレーニング計画、業績評価、コーチングなどを使用)。
テスト戦略
- モデルベースド:プロダクトで必要な特性を表すモデル、例えば、機能、ビジネスプロセス、内部構、非機能特性(信頼性など)などに基づいて、テストを設計する。そのようなモデルの例としては、ビジネスプロセスモデル、状態モデル、信頼度成長モデルなどがある。
- プロセス準拠(または標準準拠):外部のルールや標準を使用してテストの分析、設計、実装を行う。使用する外部のルールや標準には、業界固有の標準、プロセスドキュメント、テストベースの厳密な識別や使用、組織によって課せられるプロセスや標準などがある。
- 分析的
- 系統的
- 指導ベース
- リグレッション回避
- 対処的
レビュータイプ
インスペクション
- 主な目的:潜在的な欠陥の検出、作業成果物の品質の評価と信頼の積み上げ、作成者の学習と根本原因分析による将来の類似欠陥の防止。
- その他の目的:作成者のモチベーション向上と、将来の作業成果物およびソフトウェア開発プロセスの改善、合意の形成。
- ルールやチェックリストに基づいたプロセスで進行し、形式に沿ったドキュメントを作成する。
- 役割が明確に決まっている。レビューミーティングで作業成果物を読みあげる人を専任で加えたりすることもある。レビューミーティングで作業成果物を読みあげる人を専任で加えたりすることもある。 (作業成果物を読みあげる担当者は、レビューミーティング中に言い換えを使用することがよくある。これは、レビューミーティング中に、自分の言葉で説明するということである。)
- レビューミーティング前に個々のレビューアが準備する。
- レビューアは作成者の同僚か、作業成果物に関連する別の分野の専門家である。
- 開始基準と終了基準が指定されている。
- 書記は必須である。
- レビューミーティングは、経験を積んだ進行役(作成者ではなく)が主導する。
- 作成者は、レビューリーダー、ドキュメントを読みあげる担当、書記のどの役割も担わない。
- 潜在的な欠陥の記録やレビューレポートを作成する。
- メトリクスを収集し、ソフトウェア開発プロセス全体(インスペクションプロセスを含む)の改善に使用する。
テストオラクル
テスト対象のシステムの実行結果と比較する期待結果のソース
テスト結果が「期待通り」かどうかを判定するための「答え合わせ」をする存在。
具体的な内容のこと。抽象的だとテストオラクルにはならない。
テスト条件 (Test Condition)
特定のテスト目的を達成するためにテストベースを調べた結果として識別できたテストベースの一部
定義:テストを行う対象や範囲、システムやアプリケーションのどの部分を確認すべきかを示す「テストの観点」や「前提条件」のこと。
役割:何をテストするかを明確にし、どの機能や仕様、要件が満たされているかを確認する際のベース。
例:「ログイン機能で正しいIDとパスワードが入力された場合、正常にログインできること」
テストケース (Test Case)
実行事前条件、入力値、アクション、期待結果、および実行事後条件のセットであり、テスト条件に基づいて開発されたもの
定義:テスト条件を具体的に検証するための「実際の手順」や「期待される結果」を含んだ詳細なテスト項目。
役割:テスト条件に基づき、システムが期待通りに動作するかどうかを実行・評価するための実行指示書。
例:「IDに ‘user123’ 、パスワードに ‘password123’ を入力してログインボタンを押す。期待結果:ホームページに遷移する」
テスト完了
成果物:テストサマリーレポート
欠陥レポートは実行の方で。
さいごに
覚えられないかもしれない。