テスト工程管理（ソフトウェアテスト管理_品質管理）
2024-11-12 11:03:04 0 報告
ログインして完全な内容を表示
著者の他の作品
概要/内容
1. ニーズ分析
製品を探して要件/原型を求める場合、1日/半日前に要件を理解し、疑問点をまとめ、実際の業務運用の状況、各フィールドの実際の意味/役割を含めます。
ニーズレビュー、疑問、質問を述べ、ニーズを確認する
明示的なイテレーションの提测時間、テスト時間
2. 開発段階
バージョン管理基準
コードレビュー
テストポイント/ユースケース作成 --- 出力①
3.テスト段階
テスト提出範囲の確認：① テスト提出の要件範囲が明確であること ② テスト内容の影響範囲が明確であること（不明確な場合は、常に確認する）
テスト範囲記録：テスト文書はテスト時に明確に記述する必要があります。後期に影響範囲が増えた場合、文字で表現する必要があり、口頭での表現は正確ではありません。
冒烟テストの受け入れが通り、テスト段階へ進入しました。
4.テスト段階
テスト対象範囲：① 需求範囲② 今回のイテレーションの影響範囲③ メインフローのリグレッションテスト
バグ記録基準：
バグ再開追跡（tapd）
バージョン毎にテストポイントをXMind（テストケース）で記述します --- 出力①
テスト進捗の把握、リスクチェックの実施、同期の実施
5. 受け入れ
明示した受け入れ内容/受け入れ時間に沿って、受け入れを行います。
項目ごとに必要な場合に事前検証を行うかどうかを確認してください（例：機能が動作するときに製品を呼び出して効果を検証し、後期のテストが完了した後にユーザー検証を行う）
受入確認率（1つの要件イテレーションで受入確認される回数）
受入が通らない理由
6. リリース＆デプロイ
機能確認、関係者に通知
生产データベーススクリプトの実行、サービス構成、フロントエンドとバックエンドのデプロイ順序の確認
生産機能検証
オンライン【ユーザーマニュアル】の作成、更新 --- 出力②
7. 終わり
最新の【説明書】を整理しました：重要なビジネス、操作ロジック、説明が必要な機能--- 出力③
製造に関する問題を収集し、【問題記録表】に記録し、解決に対応します。（バグ、最適化、疑問、データ修正などを含む）
定期的にバグを見直します。
集める
集める
集める
集める
集める
0 コメント
次のページ
