ID:70039さん

# プロジェクト概要 - 派生開発で利用するコア機能のSDKを開発するプロジェクト 例:地図と店舗位置をピン表示する店舗検索機能をまとめたSDK ## 使用ツール - TestRail, Android Studio, Xcode, Proxyman, VisualStudioCode - TestRail:テストの進捗、実行結果の管理や実行ログを集計するコストを下げるためにテスト管理ツールを利用 - Android Studio:アプリの動作ログ確認やAndroid Manifestの編集、アプリのローカルビルドで利用 - Xcode:アプリの動作ログ確認やPodファイルの編集、アプリのローカルビルドで利用 - Proxyman:レスポンスタイムアウトや500エラーなどエラーハンドリングのテストで利用 - VisualStudioCode:マークダウン形式のドキュメント編集やjson、csvの編集に利用 ## 目的、背景 - 下記課題を解決するために、アプリ基盤の機能を分割してSDK群を開発するプロジェクト - 10年以上提供していたアプリ基盤の機能が増えすぎ、機能の取捨選択が顧客ニーズになっていた - かつてのアプリ基盤だと各機能が密結合になっていて、機能ごとの改修コストが肥大していた - CRMのデータ構造の変更に対応できるアプリ設計が必要 ## プロジェクト参画時の状況 1. 派生開発のテスト専任として入社、テスト人員の増加とコア開発でのテスト必要性からチーム変更 2. フロントエンド（SDK）開発メンバーは10名以下で、そこにQAとして参加 3. テスト分析やテスト設計、テスト実行が担当業務 4. リリース済、開発中のSDKともにテストが必要な状態 5. SDK開発はリリース間隔が決まっていて、期間に収まるように開発タスクが消化されていた 6. テストは反復開発の枠組みからはずれ、任意の期間でプランを立てていた ## 取り組んだ課題 1. テストに必要なツールの選定 2. 成果物やテスト活動の定義、タスク開始から完了までの形式化に挑戦 3. 短期のテスト依頼に対応するためのテスト手法の導入 ## 取り組みの成果 1. テストに必要なツールの選定 - テスト管理ツールの導入 - 導入時、説得のようなものも必要なく対応していただけた 2. 成果物やテスト活動の定義、タスク開始から完了までの形式化に挑戦 - テストケースやテスト計画のフォーマット、サンプル情報の作成 - テスト対象、テスト要件のパターンが多く、テスト観点の形式化はできなかった 3. 短期のテスト依頼に対応するためのテスト手法の導入 - ドキュメントも不足しており、テスト方法として探索的テストの導入 - Miroに探索的テストのテンプレートを用意 > 参考:半田技術研究所　探索的テストの進め方 改訂版

# プロジェクト概要 - BtoBtoCで利用されているサービスの改修、新機能の開発 ## 使用ツール - Android Studio:アプリの動作ログ確認やFlutterアプリのローカルビルドで利用 - Xcode:アプリの動作ログ確認やFlutterアプリのローカルビルドで利用 - VisualStudioCode:マークダウン形式のドキュメント編集やjson、csvの編集に利用 ## プロジェクト参画時の状況 1. コアとなるサービスは数年前に市場投入済 2. コアサービスの改修、開発チームのほかに関連サービス開発のチームもある 3. 1人目のQAがいてすでに開発→テスト→リリースの流れはできている 4. ドキュメント整理よりもサービス開発が優先 5. チーム内で顧客にとって良い選択はなにか？を考える文化がある 6. テストは反復開発の枠組みからはずれ、任意の期間でプランを立てていた ## 取り組んだ課題 1. 他チームからプロダクトフィードバックの吸い上げ 2. テスト関連のドキュメント不足 3. 開発機能のドキュメント不足 ## 取り組みの成果 1. 他チームからプロダクトフィードバックの吸い上げ - ドッグフーディングの企画と小さな新機能でイベント実施 - CSチームの意見反映 - 個人的には、職種が異なると視点や価値感が変わることが実感できた 2. テスト関連のドキュメント不足 - テスト計画、テスト振り返りのフォーマット作成 - アカウントや端末準備の手順ドキュメント作成 3. 開発機能のドキュメント不足 - テスト担当機能の仕様を大雑把にドキュメント化 - 入力上限や画面制御などの情報は開発段階でタスクチケットなどに残した方がテストや運用フェーズが楽になるという印象