Please enable JavaScript.
Coggle requires JavaScript to display documents.
パッケージセット不具合 再発防止案 - Coggle Diagram
パッケージセット不具合
再発防止案
テスト
観点としてあがってこなかった (大塚)
実はデータ全体の整合性を考えるテスト段階が存在しない(強いて言っても手作業の動作確認)(goto)
API-UT参照
UT
ハンドラに対してのみテストを行なっているAPI-UTを分割する(goto)
API-UT参照
E2E
手動テスト
リリース時の手順を受け入れ観点にする (大塚)
受け入れ観点がないケースのフォローが必要 (小杉)
ヒアリングする
ヒアリングタスクの追加
リファクタリング時：当初の機能想定をベースにする
ユーザーストーリーが提示されている場合は、動作確認観点をユーザーストーリーに準じる
リリース手順の確認観点は設計者が設計時に作成する。
細かい手順は実装者が行う。 (大塚)
リリース時の動作確認を複数人で行う（中澤）
自分の実装した機能の観点が甘くなる
実装者が自身の実装機能を動作確認しない
Dev/QAで担当者を分ける
画面共有して動作確認
(設計 →) テスト設計 → 実装 → ドキュメント作成
新機能はフリーテストしてみるとか (大塚)
動作確認手順書のガイドライン……？？ (小杉)
「動作確認」事態役割が曖昧(goto)
レビュー前に、少なくとも要件通りに動作することを確認する手順
運用に沿った動作確認の実施（中澤）
初期データの変更：初期状態で複数データが存在する状況を前提とする(小杉)
テストデータの内容を見直し（中澤）
人間はミスをするものなのでテストで拾う方面を拡充したい (小杉)
マトリックス図を作っていればテスト観点が漏れることもなかった(goto)
結合テストやってない問題 (小杉)
UT/E2Eに吸収されていればよい
そも結合テストとは？
ブラックボックステストの実施
単体テスト/結合テストの意識がそもそも曖昧
APIで言うとinteractorが単体
FEで言うとclassが単体
テスト実装・設計担当者を
実装者と別にする
PG
画面で気づけ無いつくりになっているのも検出を難しくした要因の１つ？ (大塚)
DB全体を素早く走査するようにチェックできるフェーズとして、UT-APIの拡充が適当と考える(goto)
API controllerのUTの拡充：最終的なデータの中身のチェック
全体ロジックのテストがE2Eにあつまりがち(goto)
動作確認時にDBまで見なくない？
PG, PGR の粒度がでかい。
確認観点が荒くなりがち。 (大塚)
タスクの粒度が荒い
必要に応じてタスクを分割する
見積もり時に可能な限り分割出来るようにする
レビューの粒度を細かくする
commitの粒度を意味単位にする
プランニング内で完了しない複雑なタスクの見積もりタスク作成
それを踏まえて再分割
スパイクをスパイクのまま作業しない
今回のケースだと、ORM経由で得られたエンティティに対して削除メソッドを呼び出すような実装ならこの問題は起こらなかった(goto)
操作対象のレコードを取り違える余地をなくす実装
更新・削除対象のIDを抽出して削除する
そもそも操作対象が異なっている場合
packages
テーブルの構造が特殊
設計
どこのデータをどういじるかがふんわりしている (大塚)
簡単な修正であればよいが、複雑な修正になればなると実装時にやると考慮漏れが発生しやすい (大塚)
実装完（レビュー依頼前）までには、どこから ID を引っ張ってきて、どこのテーブルのどんなデータを操作するのか...といったところは明記したほうがよさそう。
ER 図と並べて。 (大塚)
複雑なロジックなのだから状態遷移図を作るフェーズを設けてもよかった(簡単に思考を共有する目的なのでconfluで永続化するほどではない)(goto)
複雑な機能、データ変更が伴うケースの場合、簡易でもよいので状態遷移図を作成してレビュー対象にする
テスト設計のフェーズを設ける
更新・削除系の「他のデータに対する影響」の確認
ER図が欲しい
複雑な機能、データ変更が伴うケースのみでも書き起こしてIssueに記載
設計書を見てテスト仕様書を作成すると思うが、現在の設計書がテスト仕様書の参考にするには粒度が粗い
複雑な機能、(外部API連係含む) データ変更が伴う
設計書の詳細化
追加
ペアプロ
ペア設計
その他
サポートツールとアプリ配信のサービスが疎になっていない
DBを共有するの、マイクロサービス的によくない
配信にかかるテーブルの更新責任は配信側のシステムが持つべき