テストマネージャーの責任は何ですか？
- プロジェクト開始からプロジェクト終了までの管理
- テスト計画
- 納品された製品について顧客の承認を得る
- 中間成果物を承認し、顧客にパッチをリリースする
- 業績評価やその他の請求のためにジョブの内容を記録する
- 問題管理
- チーム管理
- 毎週のステータスレポートをテストコーディネーターまたはSQAに送信する
- 毎週行われる回顧会議に出席する
- すべてのテスト項目の毎週のリリースkpi
- プロジェクトのリソースを動員する
明らかな欠陥が特定された後でも、組織内のテスターが引き続き成果物の製品テストを実行していることがわかった場合、どのようなアプローチをとりますか？
- 受け入れ基準はより厳しくする必要があります
- テストケースを再評価する必要があります
- 可能であれば、同等のクラスセグメンテーションのユースケースや境界値など、さらに多くのテストケースを追加する必要があります。
- 無効な条件をチェックするために、さらにテストケースを追加する必要があります
- テストを停止する基準を変更する必要があります
需要追跡可能性マトリックスとは何ですか？
要件追跡マトリックスは、要件ドキュメントとテストケースをリンクして、検証プロセス中にすべてのアプリケーション要件が確実にテストされるようにするマトリックスであり、テストカバレッジを確認します。
プロジェクトのテストツールを選択する方法
- プロジェクトのニーズに応じて、自動化ツールで必要な機能を特定します
- 要件を満たす商用および非商用ツールを評価する
- ツールのコストとメリットを見積もります。費用にはライセンスとトレーニングが含まれる場合があります
- チームメンバーと相談して最終的な決定を下す
プロジェクトの主な課題は何ですか？
- テスト段階では、通常、制限時間内です
- 要件を理解することが難しい場合があります
- アプリケーションは、テストするのに十分安定している必要があります
- テストの優先度を設定する
- 熟練したテスターの不足
- 回帰テスト
- 頻繁な需要の変化
- ツール、リソース、トレーニングの不足
テスト計画とは何ですか？
- テスト計画は、アクティビティとテスト範囲を説明するドキュメントです。これは、ソフトウェア製品をテストするための基本的な要件です。
テスト計画のタイプは何ですか？
- 全体的なテスト計画
- テストレベル固有
- テストの種類に固有のテスト計画
テストマネージャーにはどのような対人スキルが必要ですか？
- 効果的で明確なコミュニケーション
- チームメンバーとの良好な関係を確立する
- 優れたリスニングスキルと感情的知性
- チームメンバーのやる気を引き出す
- 対立と倫理的問題を解決する
構成管理とは何ですか？
- 構成管理には、テストアーティファクトを調整、制御、追跡するプロセスが含まれます。テスト成果物には、自動化コード、要件、ドキュメント、問題、設計、変更要求、設計などを含めることができます。
PDCAモデルとは何ですか？
テストプロセス改善方法。計画、実行、チェック、行動
非公式レビューとは何ですか？
非公式レビューは、コードを実行せずに欠陥をチェックする方法です。ドキュメントテストのライフサイクルの初期段階では、非公式のレビューが数回実施されました。非公式のコメントは記録されません。
リスクの種類は何ですか？
- 戦略的リスク：予算、コミュニケーション、管理のリスクを含む
- プロジェクト定義リスク：プロジェクトの目的、範囲、および需要のリスクを含みます
- 人事リスク：スキル、チームメンバー、組織のリスクを含む
- プロジェクトスケジュールリスク
リスクに対処するためにテストマネージャーはどのような対策を取る必要がありますか？
- 回避：関与するリスク要因を排除する
- 削減：リスクへの影響を軽減し、是正措置を講じるリスク削減計画
- 共有：リスクをインソースや保険などの別のリソースに転送する
- 受け入れる：リスクを受け入れ、それらのリスクの計画予算を準備します
テストマネージャーはプロジェクトをどのように、そして何を評価しますか？
テストの評価中、テストマネージャーは4つのことを評価する必要があります：コスト、リソース、テストメンバーのスキル、時間
- 作業分解構造：プロジェクトを小さな部分に分割
- 3点推定：3点推定は統計データに基づいています
- 関数点法：各関数に重みを付け、サイズを測定します
3点推定とは何ですか？
3点推定では、過去の経験に基づいて、各タスクは最初に3つの値を生成します。
- 最良の場合の見積もり：経験豊富なチームメンバーとの120労働時間または15日
- 最も可能性の高い見積もりは、170時間または21日で、十分なリソースと適度なチームメンバーの経験があります。
- 最悪の場合の見積もり：200営業時間または25日、チームでの実務経験が少ない
テスト評価のベストプラクティスはありますか？
- バッファ時間を増やす：バッファ時間を確保することは常に利点であり、才能の突然の辞任などの予期しない理由によって引き起こされる遅延に対処するのに役立ちます。
- 見積もりにおけるアカウントリソースの計画：見積もりが現実的であることを確認し、人的リソースの可用性などの重要な要素を検討します。
- 過去の経験を引用する：過去の経験を通じて、発生する可能性が最も高いすべての障害または可能な障害を回避するようにしてください。
- 見積もりに固執する：見積もりは完全な証明ではありません。また、うまくいかない場合もあります。プロジェクトの初期段階では、テスト評価を再検討し、必要に応じて修正する必要があります
テストレポートには何が含まれますか？
- プロジェクト情報
- テスト対象
- テストの概要
- 欠陥
ソフトウェア品質保証のベストプラクティスは？
- 継続的な改善
- ドキュメントファイルのアーカイブ
- ツールの使用と自動化
- 測る
- チームワークとSQAの責任の共有
テスト実行の品質を決定できる要因は何ですか？
- 不適合率：（不適合品数／適合品数）×100
- 欠陥リーク率：（欠落している欠陥の数/ソフトウェアの欠陥の総数）x100
チームの対立にどのように対処しますか？
- チームメンバーの背景と作業方法は多様であるため、最初のステップは、テストプロジェクトでの競合を予測して準備することです。
- 次のステップは、チームメンバーのプロジェクトステータスを評価するための会議を開催することです。テストマネージャーは、チームの欲求不満と怒りを払拭できるように、全員とのオープンなコミュニケーションを維持する必要があります。
- 最後に、チームメンバーは協力して、プロジェクトの成功のための協力の重要性を強調する必要があります。
