hotfix3回つまり障害が3回起きたってこった
それぞれの影響UU数調査が超たいへん
時間も給与もすごいことになった
ラスイチの概要は「開発者が設計書を実現してなかった」これが一番デカかった
ありえなくない？モデル部分なんだけど（たとえばこれが新設なのに実装してなきゃ結合でエラーになるんだけどさ）既存の修正が必要だったのよ それをやってなかったわけ！
あたしはレビュワだったんだけど「上がってる差分のコードレビュー」をしたんであって、設計と読み合わせることはしてない＝実装の漏れがあることに気づかない
さあテストはどうだったんですかテストは
テストは何をしてたんですか
テストは何を見てたんですか
UIしか見てなかったらわからない話
APIのクエリが間違ってて後段がおかしくなるってそんなのUIは死んでもわからん
これをdetectするはずだったテストは一体なんだったんですか？？？
再発防止はどうすりゃいいんですかね
とにかくこれでまたテストがきつくなるのは間違いない
ソフトウェアテストには、テスト設計とテスト実装以外にもさまざまなフェーズがあります。一般的なソフトウェアテストのフェーズは以下の通りです：
テスト計画（Test Planning）：
- テストの目的、範囲、スケジュール、リソース、予算、リスク、およびテスト戦略を定義するフェーズです。
テスト分析（Test Analysis）：
- テスト対象のシステムの仕様や要件を分析し、テスト条件やテストケースを特定するフェーズです。
テスト設計（Test Design）：
- テスト分析で特定されたテスト条件に基づいて、具体的なテストケースやテストスクリプトを設計するフェーズです。
テスト実装（Test Implementation）：
- テスト設計で作成したテストケースやテストスクリプトを実際に準備し、テスト環境を構築するフェーズです。
テスト実行（Test Execution）：
- テストケースを実際に実行し、ソフトウェアが期待通りに動作するかどうかを検証するフェーズです。テスト実行中にはバグや欠陥を記録します。
テスト報告（Test Reporting）：
- テスト結果を分析し、テストの進捗状況、発見された欠陥、テストの効果などを報告するフェーズです。
テスト完了（Test Closure）：
- 全てのテスト活動を終了し、テストの成果物をまとめ、テストプロセスの評価を行うフェーズです。テストプロジェクトの振り返りを行い、将来の改善点を明らかにします。
これらのフェーズを順次進めることで、効果的かつ効率的にソフトウェアの品質を保証することができます。
だそうだが現状は
設計者：設計、1)
開発者：実装、単体試験、結合試験の2)〜7)
試験者：システム試験、受け入れ試験のの2)〜7)
だな
ちなみにいまは設計者がテキトーな設計したままぶんなげて、実装中にその過不足に気づいた開発者が設計書を修正してる
ほんっとーにやめてほしいと思ってる 設計がアホで開発もアホだったらどうすんねん
で。
あたしのご提案は「設計者は3)のテスト設計までをやる」
開発者は3)を見て4)を作り、レビュワはコードレビューかつ3)と4)を読み合わせるつまり設計全体を理解して把握する必要はない
「いやいや今まで通りレビュワが設計書読んで理解して実装と試験の不備を指摘しろ」ってんなら、最初からレビュワがコード書けばいいんじゃね？？いちいちコメント書いて修正させてる工数より軽くね？って話だよ 非効率すぎるんだって
設計者はコード読めなくていいのと同様に、レビュワは設計を理解する必要はないと思うわけ
で、レビュワはUTが「コードとして」記述が正しいことはわかっても、ケースを網羅してるかはコード上からはわからない。だから百歩ゆずってレビュワはコードではなく設計書3)を見て4)が正当性を担保しているかどうかを見る、にしたい
よしこれでいこう
「設計者はテスト設計もしてくれ ぶん投げて終わりにすんな」
これに尽きる
