Memory Bank MCP Server

{ "schema": "memory_document_v2", "metadata": { "id": "testing-quality-assurance-plan", "title": "旧API削除のテストと品質保証計画", "documentType": "qa_plan", "path": "testing-quality-assurance-plan.json", "tags": [], "lastModified": "2025-04-12T14:56:48.769Z", "createdAt": "2025-04-12T11:30:00Z", "version": 1 }, "content": { "overview": "このドキュメントは、旧API削除作業における包括的なテスト戦略と品質保証計画を提供します。旧APIの削除が他の機能を壊さないことを確認するための体系的なアプローチを説明します。", "sections": [ { "title": "テスト戦略の概要", "content": "旧APIを安全に削除するためには、以下のテスト戦略を実施します：\n\n1. **ユニットテスト**: コードベースの基本機能が変更後も正常に動作することを確認\n2. **統合テスト**: システムコンポーネント間の相互作用が正常であることを確認\n3. **エンドツーエンドテスト**: ユーザーワークフローが中断されないことを確認\n4. **リグレッションテスト**: 既存の機能が引き続き期待通りに動作することを確認\n5. **手動テスト**: 自動化できない側面をカバーするための手動テスト\n\nすべてのテストを通過した後に初めてPRをマージし、リリース準備を行います。" }, { "title": "自動テスト計画", "content": "### 1. ユニットテスト\n\n削除対象APIのユニットテストを削除または統合APIの使用に変換し、以下を確認します：\n\n- `src/__tests__/tools/`にある対象API専用のテストファイルを特定し更新\n- `write_document`と`read_document`のテストが十分なカバレッジを持つことを確認\n- 削除されたコードへの依存性がないことを確認\n\n### 2. 統合テスト\n\n以下の統合テストに焦点を当てます：\n\n- ブランチコントローラーとグローバルコントローラーの正常動作テスト\n- MCPサーバーの様々なコマンドシーケンスの実行テスト\n- ツール定義と実行フローの一貫性テスト\n\n### 3. エンドツーエンドテスト\n\n以下のシナリオをカバーするE2Eテストを実行します：\n\n- VSCode拡張機能との互換性テスト\n- CLIコマンドの実行テスト\n- APIクライアントとの統合テスト\n\n### 4. CI/CDパイプライン\n\nGitHub Actionsワークフローですべてのテストが自動的に実行されることを確認します。" }, { "title": "手動テスト計画", "content": "自動テストでカバーできない側面をテストするための手動テスト計画です：\n\n### 1. VSCode拡張機能の互換性テスト\n\n- VSCode拡張機能をインストールして起動\n- 基本的なメモリバンク操作（ドキュメントの読み書きなど）\n- ブランチ間の切り替え\n- コア機能の動作確認\n\n### 2. CLI機能のテスト\n\n- CLIのインストールと基本コマンドのテスト\n- write_documentコマンド（ブランチスコープ）のテスト\n- write_documentコマンド（グローバルスコープ）のテスト\n- read_documentコマンドのテスト\n\n### 3. エラーケーステスト\n\n- 非推奨APIを呼び出した場合の適切なエラー応答\n- 誤ったパラメータでの呼び出し時のエラー処理\n- 不明なAPIを呼び出した場合の動作確認" }, { "title": "テスト環境", "content": "テストは以下の環境で実施します：\n\n1. **ローカル開発環境**\n - OS: Windows 10/11, macOS, Linux (Ubuntu)\n - Node.js: v18.x LTS\n - 開発者用セットアップ\n\n2. **CI環境**\n - GitHub Actionsランナー (Ubuntu)\n - Node.js: v18.x LTS\n - 最小限のスコープインストール\n\n3. **統合テスト環境**\n - クリーンなDockerコンテナ\n - 様々なクライアントとの統合テスト用" }, { "title": "カバレッジ要件", "content": "コードカバレッジの目標は以下の通りです：\n\n- **ユニットテスト**: 最低90%のコードカバレッジ\n- **統合テスト**: 主要ワークフローの100%カバレッジ\n- **マニュアルテストケース**: すべての主要ユースケースをカバー\n\nカバレッジレポートはCI/CDパイプラインの一部として生成し、PRのレビューで確認します。" }, { "title": "バグトリアージとリスク管理", "content": "テスト中に問題が見つかった場合、以下のプロセスに従います：\n\n1. **重大度の評価**:\n - P0 (ブロッカー): コア機能が利用不可\n - P1 (重大): 重要な機能に深刻な問題\n - P2 (中程度): 機能に問題があるが回避策あり\n - P3 (軽度): 小さな問題、UI/UXへの影響が少ない\n\n2. **バグの修正戦略**:\n - P0/P1バグは即座に修正し、リリースを延期\n - P2バグはリリース前に修正するよう試みる\n - P3バグはリリース後のパッチで対応可能\n\n3. **回避策のドキュメント化**:\n - 未解決の問題の回避策をリリースノートに記載" }, { "title": "リリース判断基準", "content": "リリース可否を判断するための明確な基準を設定します：\n\n1. **必須合格基準**:\n - すべての自動テストが合格\n - コードレビューが完了\n - P0/P1バグがゼロ\n - ドキュメント更新が完了\n - 主要クライアントとの互換性確認\n\n2. **推奨基準**:\n - P2バグの修正\n - マニュアルテストシナリオの100%合格\n - 性能テストの要件達成\n\n3. **リリース承認**:\n - プロジェクトメンテナによるレビューと承認\n - API削除の最終確認\n - リリースチェックリストの完了" }, { "title": "リリース後のモニタリング計画", "content": "リリース後、以下の項目をモニタリングします：\n\n1. **使用状況メトリクス**:\n - APIエラーの発生率\n - 旧APIへのリクエスト件数（理想的にはゼロ）\n\n2. **コミュニティフィードバック**:\n - GitHubのIssuesの監視\n - DiscordやSlackなどのコミュニティチャンネルのモニタリング\n\n3. **クリティカルバグ用の緊急パッチ計画**:\n - 重大な問題が発見された場合の緊急リリース手順\n - ホットフィックスのデプロイプロセス" } ] } }