記事一覧
JaSST Online Fennel 参加レポート
はじめに今回のテーマ「テスト設計の暗黙知」の通り、「暗黙知の把握」→「暗黙知を言語化」→「再現(再利用)可能にする」という思いをもって、本会に参加しました。
本記事は、おーだんさんが解説や質問に答えてくださっていた内容を元に、筆者が理解/解釈したものを言語化し、書き記しております。
そのため、「おーだんさんの講演内容そのものを紹介する記事ではないこと」「筆者の個人的な理解/解釈が多分に含まれて
TM-7.6.1 (K2)テストチーム内、およびテストチームとステークホルダとの間のコミュニケーションを、効率的に行うための要因を説明する。
テストチームによるコミュニケーションテストプロダクトの文書化
レビュー済みドキュメントのフィードバック
情報収集と拡散
テストマネージャはプロジェクトステータス情報を提示することが多いため、情報を適切な詳細度合いでまとめ、明確に提示し、簡単に理解できるような方法で提示できなけれならない。効果的にコミュニケーションすることで、聴いている人の注意を引き付けることができ、正しいメッセージを伝える
TM-7.5.1 (K2)テスト担当者のモチベーションを上げる要因、および下げる要因について、例を挙げて説明する。
テスト担当者のモチベーションを上げる要因テスト担当者のモチベーションを上げる要因は、大きく分けて以下の3つです。
達成感・充実感
承認・尊敬
成長・自己実現
達成感・充実感
テスト担当者は、自分の仕事がプロジェクトの成功に貢献していることを実感することで、モチベーションが上がります。そのため、テスト担当者が自分の仕事に意義を感じられるよう、プロジェクトの初期段階からテスト担当者を巻き込
TM-7.4.1 (K2)独立テストのオプションを説明する。
独立テストのオプション開発者が自らテストを行う
最も独立性の低いオプションです。開発者が自らテストを行うため、開発者の主観的な判断がテスト結果に反映されやすくなります。ただし、開発者がテストを行うことで、テストのフィードバックが開発に迅速に反映されるというメリットもあります。
開発者以外の開発者がテストを行う
開発者以外の開発者がテストを行うオプションです。開発者とテスト担当者との間の関わ
TM-7.3.1 (K2)特定の状況でテストチームのリーダとなるために必要なハード面とソフト面のスキルについて説明する。
ハードスキル(テクニカルスキル)ハードスキルとは、テストプロセスやテストツールに関する専門知識や技術です。ハードスキルは、テストチームのリーダーがテストプロセスを効果的に管理し、品質の高いテスト結果を達成するために不可欠です。
要件ドキュメントからテストケースを抽出するスキル
テクニカルドキュメント(要件、コードなど)をレビューするスキル
レビューコメントを明確で分かりやすく、目的に沿った
TM-7.2.2 (K4)チームのスキルに関するアセスメント結果を分析し、トレーニングとスキル開発計画を策定する。
チームの強みと弱みを把握するスキルアセスメントでは、チームメンバーの各スキルレベルを評価します。これにより、チームの強みと弱みが把握できます。
強みは、チームの成果を向上させるために活用できます。弱みは、トレーニングやスキル開発の計画を立てることで、補うことができます。
弱みを補うためのトレーニングやスキル開発の計画を立てる弱みを補うためのトレーニングやスキル開発の計画を立てる際には、以下の
TM-7.2.1 (K4)スキルアセスメントスプレッドシートを使用して、ソフトウェアシステムの使用、ドメインおよびビジネスに関する知識、システム開発領域、ソフトウェアテスト、対人関係スキルに関する、チームメンバの強みと弱みを分析する。
スキルアセスメントスプレッドシートの作成スキルアセスメントスプレッドシートには、次の情報が含まれます。
評価するスキル
評価する方法
評価の基準
スキルは、ソフトウェアシステムの使用、ドメインおよびビジネスに関する知識、システム開発領域、ソフトウェアテスト、対人関係スキルの5つのカテゴリに分類されます。評価方法は、主観的評価、客観的評価、またはその両方を使用できます。評価の基準は、スキル
7. スタッフのスキル– チーム構成
7.2 個人のスキルTM-7.2.1 (K4)スキルアセスメントスプレッドシートを使用して、ソフトウェアシステムの使用、ドメインおよびビジネスに関する知識、システム開発領域、ソフトウェアテスト、対人関係スキルに関する、チームメンバの強みと弱みを分析する。
TM-7.2.2 (K4)チームのスキルに関するアセスメント結果を分析し、トレーニングとスキル開発計画を策定する。
7.3 テストチームの
TM-6.4.1 (K2)ツールを活用することでメトリックの収集および評価がどのように改善できるかを説明する。
ツールのメリットツールを活用することで、メトリックの収集および評価のメリットは次のとおりです。
効率性の向上: ツールは、手動でメトリックを収集および評価するより効率的にリアルタイムデータを取得できます。これにより、テストマネージャーは、より重要なタスクに集中することができます。
正確性の向上: ツールは、手動でメトリックを収集および評価するよりも正確です。これにより、テスト活動の全体的な信
TM-6.3.1 (K2)ツールのライフサイクル内の各フェーズについて説明する。
調達このフェーズでは、テストツールの選定、導入、トレーニングを行います。テストツールの選定では、テストチームのニーズと予算を踏まえて、適切なツールを選択することが重要です。導入後は、テストチームのメンバーにツールの操作方法をトレーニングする必要があります。
テストツールの調達フェーズでは、以下の事項を検討する必要があります。
テストツールの機能要件
テストツールの性能要件
テストツールの
TM-6.2.3 (K4)ツール選択計画を策定するために、リスク、コスト、利点などを含む前提の状況を評価する。
テストツール導入のリスクテストツールの導入には、以下のようなリスクが伴います。
組織の準備が整っていない
ツールの変更による成果物のメンテナンス困難
テストアナリストによるテストタスクへの関与減少によるテスト価値低下
テストツール導入のコストテストツールの導入には、以下のようなコストがかかります。
初期コスト:ツールの購入、適用、トレーニング、他ツールとの統合、ツールをサポートするため
TM-6.2.2 (K2)カスタムツールを決定する場合のマネジメント上の問題点について説明する。
カスタムツールを決定する場合の問題点コストと時間の増加
カスタムツールの開発には、ベンダーツールやオープンソースツールの購入に比べて、コストと時間がかかります。これは、ツールの設計、開発、テスト、運用など、すべての段階で、チームの専門的な技術やリソースが必要になるためです。
技術的リスク
カスタムツールは、チームの専門的な技術によって開発されるため、技術的なリスクを伴います。例えば、ツール
TM-6.2.1 (K2)オープンソースツールを選択する場合のマネジメント上の問題点について説明する。
オープンソースツールを選択する場合の問題点オープンソースツールは、初期購入コストが低いが、正式なサポートがほとんどない。
オープンソースツールは、機能が限定されている場合がある。
オープンソースツールは、カスタマイズや拡張が容易だが、複雑性とオーバーヘッドが増加する可能性がある。
オープンソースツールのライセンスには、さまざまな種類があり、注意が必要である。
セーフティクリティカルなソフ
6. テストツールおよび自動化
6.2 ツール選択TM-6.2.1 (K2)オープンソースツールを選択する場合のマネジメント上の問題点について説明する。
TM-6.2.2 (K2)カスタムツールを決定する場合のマネジメント上の問題点について説明する。
TM-6.2.3 (K4)ツール選択計画を策定するために、リスク、コスト、利点などを含む前提の状況を評価する。
6.3 ツールのライフサイクルTM-6.3.1 (K2)ツー
TM-5.7.1 (K2)STEP テストプロセス改善モデルの背景、対象範囲、目的をまとめる。
STEP テストプロセス改善モデルの背景STEP テストプロセス改善モデルは、1990年代に米国のソフトウェアテスト専門家であるデビッド・クレイグ氏によって開発されました。当時、ソフトウェアテストプロセスの改善が求められる一方で、既存のテストプロセス改善モデルでは、特定の順序で改善を進める必要があるという課題がありました。
STEP は、このような課題を解決するために開発されたモデルであり、テ
TM-5.6.1 (K2)CTP テストプロセス改善モデルの背景、対象範囲、目的をまとめる。
CTP テストプロセス改善モデルの背景CTP テストプロセス改善モデルは、1999 年に発表されたテストプロセス改善モデルです。モデルの基本的な前提は、テストプロセスの中で最も重要なプロセスを特定し、そのプロセスを改善することで、テストプロセス全体の品質を向上させることができるというものです。
CTP テストプロセス改善モデルの対象範囲CTP モデルは、ソフトウェア開発のすべてのフェーズで適用