Recommended
Recommended
More Related Content
Similar to 【JSTQB_Advanced Level_TestManager】シラバス第7章
Similar to 【JSTQB_Advanced Level_TestManager】シラバス第7章 (20)
More from ssusercd6d02
【JSTQB_Advanced Level_TestManager】シラバス第7章
- 2. 7.1:イントロダクション • 有能なTMは、様々なスキルがチーム内に共存するように チームメンバの採用を行う • スキル要件は時間とともに変化するため、採用だけでなく トレーニングと成長機会の提供も重要 • チームのスキルだけでなく、TM自身のスキルセット維持も必要 • 短納期＆ハイプレッシャーな環境でも効果的に機能させるため
- 4. 7.2:個人のスキル • ソフトウェアテストの能力の獲得手段 • 「経験」「教育」「トレーニング」 • 知識を身に着けるのに役立つもの・活動（1/2） 役立つもの・活動 獲得できる知識など システムの利用 ● ユーザーがどのように操作するか ● どの部分の故障が重大な障害になるか ● 様々な状況において、ユーザーがシステムに期待するレ スポンス ドメインorビジネスに関する知識 ● ビジネス面で重要な領域（機能）はどこか ● その領域（機能）がビジネスに与える影響
- 5. 7.2:個人のスキル • ソフトウェアテストの能力の獲得手段 • 「経験」「教育」「トレーニング」 • 知識を身に着けるのに役立つもの・活動（2/2） 役立つもの・活動 獲得できる知識など 開発プロセスの各フェーズでの活動 （分析、開発、テクニカルサポート を含む） ● エラーがどのように混入するか ● エラーをどのように防げるか ● プログラミング知識が必要なツールが使える ● コードレビューができる ● UXや使用性要件についての知識 ソフトウェアテストの活動 ● 仕様・リスク分析の能力 ● テストケース設計の能力 ● テストを実行し結果を記録する能力 ● テストマネジメントのための プロジェクトマネジメントの知識・スキル・経験
- 6. 7.2:個人のスキル • テクニカルスキル（前述）に加えて、対人スキルも重要 • 建設的に批評を行う力 • 影響力、交渉力 • 対人関係スキルが無いと、技術的に優れていても失敗する可能性が高い テストの専門家として成功するためには、 組織をうまくまとめ、細かい配慮があり テキストor口頭での優れたコミュニケーションスキル を持っていなければならない
- 7. 7.2:個人のスキル • スキル評価シートの作成と活用 • 仕事で重要なスキルだけでなく、職位に適切なスキルも網羅する • 各スキルを得点化し、各個人の強み弱みを評価する • その情報に基づき個人orグループのトレーニング計画を作成する • 計画は「弱み」から始め、それらの領域に対処する方法を決定する • 弱みだけでなく、強みも強化していく • 各個人の能力目標を設定し、評価基準を定義する # 対処方法 詳 細 1 トレーニング トレーニングコースやeラーニングの受講、社内トレーニングなど 2 自己学習 本、セミナー、インターネットリソースの利用 3 クロストレーニング チューター/チューティー、ペアでの作業など
- 8. 7.2:個人のスキル • 採用について • 最適なチームメンバーを採用できることはほとんどない。 • チームメンバーが「現PJには」最適であっても、 次PJには（スキル構成が）最適でない可能性がある 「知的で」「好奇心が強く」「適応性があり」「仕事熱心で」 「効率的に作業し」「学習意欲と学習能力」が高い人を採用しなければならない 最適な個人の集合は構築できないが、 個人の強み弱みのバランスを取ることで、強いチームは構築できる
- 10. 7.3:テストチームの力学 • 最善なチームの構築のために「人選」は最も重要な仕事である • JOINするメンバーを選択する時は、チームの力学を考慮すること • JOINするメンバーは、チームのスキルを補完できるか？ • 性格が合うかどうか？ 強いテストチームは、多様な複雑性を持つ複数のPJに対応でき、 他のPJチームメンバーともうまく連携できる
- 11. 7.3:テストチームの力学 • テストは多くの場合、プレッシャーの厳しい活動である • スケジュールのひっ迫 • ステークホルダからの（不合理な）高い期待 • これらへの対処はTMの責任であるが、メンバーも 同じようにこのプレッシャーを感じている • プレッシャーの高い状況にうまく対処できる人を採用する必要がある • 性格が作業環境とマッチしているか？ • 与えられた時間以上の作業がチームにある場合、 自身のタスクを完了させ「次に何ができるか」を尋ねられるか？
- 12. 7.3:テストチームの力学 • 「自分に価値があり必要とされている」と感じると、 個人はより熱心に働き、周囲に気を配るようになる • 各個人が認識すべきこと • 「自分がチームの重要なメンバーである」 • 「自身の貢献がチーム全体の成功に必要不可欠である」 このような力学が醸成されると、メンバー自身から 「クロストレーニング」「仕事量の平準化」が行われるようになる その結果TMは、より多くの時間を対外的な対応に割り当てられる
- 13. 7.3:テストチームの力学 • 各個人には、そのチーム内における「明確な役割」を与えなければならない • 【最終目標】 • メンバー個人の成功が、チーム全体の成功に貢献すること • 【目標の実現方法】 • アセスメントプロセスに基づき、性格に応じた役割を割り当てる • その人のスキルを活かしつつ、その向上を図る
- 14. 7.3:テストチームの力学 • テストチームに人を追加する際、評価すべきスキル（1/2） テクニカルスキル（ハードスキル） 要件ドキュメントからのテストケース抽出 ツールを用いたAPIのテスト（正常系・異常系） 要件、コードなどのレビュー SQLを用いたDB情報の検索や変更 明確かつ目的に沿った形式のレビューコメント テスト自動化ハーネスの設計 特定のシナリオでの、テスト技法の適用 自動テストの実行およびトラブルシューティング 故障の評価及び正確な記録 テスト計画・テスト仕様の作成 欠陥分類情報の理解度の提示 テストサマリレポートの作成 欠陥の根本原因の理解度の提示 -
- 16. 7.3:テストチームの力学 • 前述のリストは完全ではない • 要求されるスキルは環境や組織によって異なる • スキル評価及び強み弱みの判断方法 • 効果的な質問を行いスキルを示すチャンスを与える • 評価に使用するスキルセットをまとめ、全メンバーに適用し、 育成とトレーニング領域を決定する必要がある • TMは前述のスキルに加えて、コミュニケーション＆渉外スキルも必要 • 論争が起こりそうな状況を和らげ、 組織内に適切な人間関係を構築・維持しなければならない
- 18. 7.4:組織内におけるテストの適合 独立性 テスト形態 説 明 低 独立したテスト担当者がいない 開発者自身がテストするため欠陥を迅速に修正できる 意図通りに動作するかを判定する 動作が要件に一致するとは限らない コードを書いた開発者とは 異なる開発者によるテスト 欠陥レポートを出すのに消極的になりがち 正常系のテストケースに集中しがち 開発チームに属する テスト担当者によるテスト どちらかといえば、要件への準拠に集中する 重点がスケジュールの維持＞品質目標の達成 になりがち 位置づけが開発活動＞テスト活動になりがち 開発に携わっていない技術組織の テスト担当者によるテスト テスト結果情報を客観的に報告できる テストはキャリアパスとしてみなされる 外部のテスト専門家による 特定のテストタイプのテスト テストタイプは使用性・セキュリティ・性能 などの領域になる 機能要件への準拠は見逃されがち 高 外部組織によるテスト テストを的確に行うための知識の共有が不十分になりがち 定義されたコミュニケーション構造が必要になる 外部組織の品質を定期的に監査しなければならない
- 19. 7.4:組織内におけるテストの適合 • 独立性が高い：移転する知識が少なくなる • 独立性が低い：知識は増えるが、相反する目標が生じる可能性がある • 独立性の度合いは、開発モデルによっても決まる • 例）アジャイル開発→テスト担当者は開発チームの一員 • テスト形態が混在することもある • 例）開発組織内でテスト実行→外部組織が最終認定 という方式 スケジュールや予算を守りながら品質を最大化するためには 各テストフェーズに対し、責任と期待を理解したうえで要件定義する必要がある
- 21. 7.5:モチベーション • テスト担当者をモチベートする方法 • ①達成した仕事に対する評価 • ②マネジメント層からの承認 • ③PJチームや同僚からの尊敬 • ④責任と自己裁量の増加 • ⑤成し遂げた仕事に対する報酬（給与・責任・評価の増加）
- 22. 7.5:モチベーション • PJからの影響がモチベーション向上の阻害要因になる可能性もある • 例）「不可能な納期」 • 品質向上活動のため、テスト担当者が遅くまで残業 • PJ要因により、本来より早くリリース 結果、テスト担当者の努力にも関わらず、 品質の劣るプロダクトになってしまう テスト担当者の貢献に対する理解や評価がなければ、 プロダクトが成功しても、モチベーションは下がってしまう
- 23. 7.5:モチベーション • テストチームは優れた仕事を行っている • 「テスト実行」「リスク軽減」「正確な結果の記録」など • それを証明するために、適切なメトリクスを追跡する必要がある • ただし、データが公開されなかったり、達成に対する 正当な評価がなけれは、モチベーションは簡単に下がる • 「正当な評価」とは？ • 無形物：尊敬や認定 • 有形物：昇進・昇給、キャリアの向上 • 「正当な評価（及び敬意）」の獲得方法 • テスト担当者が「PJの価値向上に貢献」すること • PJ早期から関与させ、品質コスト削減やリスク緩和に貢献させる
- 24. 7.5:モチベーション • TMは、個人のモチベーションを向上させるのに重要な役割を果たす • 個々のテスト担当者の実績を把握し、 ミスに対しても公平かつ誠実に評価すること • 公平で一貫性のあるTMは、手本を示すことでメンバーをモチベートする
- 26. 7.6:コミュニケーション • テストチームが行う主なコミュニケーション（情報伝達） • テストチームが敬意を持たれるには、ステークホルダとのコミュニケーショ ンが専門的、客観的、効果的でなければならない • レビューのフィードバックにおいては外交と客観性が必要になる • コミュニケーションにおいては「テスト目的の達成」と「プロダクト及び開 発プロセスの品質向上」の両方に注力しなければならない コミュニケーションのタイプ 説 明 テストプロダクトの文書化 テスト戦略、テスト計画、テストケース、欠陥レポート等 レビューのフィードバック 要件、機能仕様、ユースケース、単体テストドキュメント等 情報の収集と拡散 開発者、テストチームメンバ、マネジメント層とのやりとり
- 27. 7.6:コミュニケーション • TMは様々な人とコミュニケーションをとる • 例）ユーザー、PJメンバ、マネジメント層、外部テストグループ、顧客 • コミュニケーションは、対象となる人にとって効果的でなければならない • 例）重役へのブリーフィング（簡易報告）の場合、 開発チーム向けの欠陥レポートでは詳細すぎてNG • TMはPJステータス情報を提示することが多い • 情報を適切な粒度でまとめ、簡単に理解できるよう提示する必要がある • プレゼンテーション1つ1つを「品質と品質プロセスを促進する為の機会」 として捉えなければならない
- 28. 7.6:コミュニケーション • TMは様々な人とコミュニケーションをとる • 例）ユーザー、PJメンバ、マネジメント層、外部テストグループ、顧客 • コミュニケーションは、対象となる人にとって効果的でなければならない • 例）重役へのブリーフィング（簡易報告）の場合、 開発チーム向けの欠陥レポートでは詳細すぎてNG • TMはPJステータス情報を提示することが多い • 情報を適切な粒度でまとめ、簡単に理解できるよう提示する必要がある • プレゼンテーション1つ1つを「品質と品質プロセスを促進する為の機会」 として捉えなければならない どのようなコミュニケーションでも、 「伝えたいメッセージ」 「メッセージを受け取ってもらう方法」 「メッセージを受け入れてもらうために必要なもの」 を理解する必要がある
- 30. 7.6:コミュニケーション • TMのコミュニケーションのベクトル 上向き 下向き 外向き 内向き マネジメント層 チームメンバ 部門の外部 テストチーム内 コミュニケーションのベクトルに関係なく 同じルールを適用し、 相手にとって適切なコミュニケーションを行い、 メッセージを効果的に発信し、 理解度を確認する
- 31. 7.6:コミュニケーション • 様々なコミュニケーション手段を使いこなす必要がある • 電子メール • 口頭でのやり取り • 公式or非公式のMTG • 公式or非公式なレポート • ツールを介したコミュニケーション • 緊急を要する場合でも「品質」と「内容」の両方を担保する • ドキュメントによるコミュニケーションは、残り続ける • 品質を推進する組織として、その象徴となるような プロ品質のドキュメントを残す必要がある
- 32. おつかれさまでした！！