入社一発目で激烈炎上案件にテスターとして参加して得た気付き
- 4. ① 参加時点で納期が半年遅れ
② 要件定義時の三倍に膨れた画面数
③ なのに実装者の数は変わらない（補充は納期が過ぎてから）
④ 納期が遅れすぎて開発初期メンバーが退職したり期限でいなくなる
⑤ 実装者が二年目しかいない
⑥ PLが実装者の質問に対して実装者に正解を委ねる返答をするため
設計書に答えがない
⑦ テスト方法が特殊で効率が悪い
２. 炎上の詳細
- 5. ⑦ issue 1000件、直してもデグレ連発
⑧ そもそも設計書通りの実装ではないし、設計書通りの試験書ではない
⑨ 設計書が変わってもそれが試験書に反映されてない
⑩ というか、仕様が変更されても設計書に反映されてない
⑪ テスト内容が機能要件・正常系に傾いており、非機能要件や異常系が少ない
（結合テスト件数は全体で9000→12000→16000件ほど）
⑫ テスト設計のレビューがされてたりされてなかったりで逆に混乱する
⑬ 結合試験書の修正をテスト実行者が行う
２. 炎上の詳細 その二
- 6. ① 顧客が準備すべきAPIが「ない」
→ こちらで仮想的にレスポンス用の静的 json を用意
→ json を編集して期待通りのレスポンスになるかテストする
② ついでに使用する予定のハードウエアもない
→ 3月現在も上記2つはない
③ 各種ログを tail で監視しその内容も確認する
→ リクエストAPIのパラメータに不備がある可能性（実際あった）
特殊なテスト方法(参加したのは結合試験)
- 9. ４. 課題
① 雑な要件定義
② テスト設計目線の不足
③ チーム体制の不備
④ 設計者と実装者の認識の違い
⑤ 設計書や試験書の連携不備
⑥ 曖昧で不確かな情報共有方法や規定
- 25. Never-あってはならないこと- Must-できなければならないこと- Want-あってほしいこと-
顧客に
とって
の品質
機能適合性 ログインできない
ログインできる
検索できる（ソート・条件指定・フリー）
信頼性 システムダウン
想定10倍のアクセスに耐える
個人情報がもれない
使用性 レスポンスに時間がかかる
各デバイス・ブラウザでアクセス
DBのバックアップがされている
作り手
に
とって
の品質
保守性
エラーログが残らない
メンテに膨大な時間がかかる
バージョンアップでデータ消失
サーバ増設が考慮されている
ヴァージョンアップが想定時間内で終了
DBへのカラム追加が想定されている
移植性 環境が変わると動作しない
既存DBとシステムの互換性
クライアント環境に依存しない
OS・ブラウザ・端末に依存しない
性能効率性
フリーズする
リソース配分がおかしい
各種レスポンスが性能要求時間内
想定100倍以上のデータ保存可能
