ソフトウェア品質向上セミナーを受講して

※ここでいう経験は講師のものである。

傾向として

• 成功するパターン : 最初にテストを考える
• 失敗するパターン : 取り敢えず作るものを作って、後で確認

テストのコツ

結論：最初にテストを考える（テスト駆動・テストファースト）
「何ができればOKか？」を考える。

スポーツと一緒で基本の「型」は大事

レビューもテストの一つ

レビュー（静的テスト）
プログラムのテスト（動的テスト）

仕様書を読むときの注意点

仕様書は足りないことが多い。
そのため、自分で補うことが必要

ただ、レビュー時点は書かれていることを注目しがちだが、
書かれていないことも注意すべき。

最初に何がmust・never・wantを考えてから仕様書を読むと書かれていないことに関しても気づきが得れる。
ここでは、機能面を注視しがちだが、セキュリティや信頼性も考える必要がある。

これは仕様書についてだけでなく開発における設計・実装・テストの全てにおいて言える。

これにより、リリースの3日前のテストでバグを見つけるのでなく、前もっと見つけるフローを用意できる。

手戻りコストの法則

• （基本）設計１
• 単体テスト１０
• システムテスト４０
• リリース後１００以上

経験上、半分以上は設計段階で気づけば手戻りでもっと減るのに。

要求分析

最低、5～10分やったら半日コストが浮ける

何ができればOKか？　＝　品質目標
開発がスタートするに連れ、劣化する。（忘却、伝言ゲーム）

方針としては

• 上流工程は品質を下げない
• 下流工程は品質を上げる

リバースエンジニアリング（足りない仕様を補う）は大事
仕様の無いことを片っ端から見つけ出して、提案して潰して行く必要がある（欧米では普通）

品質は「要求を満たすこと」である
品質は「誰か」にとっての価値である

見やすいGUIとは？（seniorなのかteenagerなのか）

まとめ

人間は自分にとって大事なことでなければ思いつかない。
独りで考えるのではなくメンバー間で全体を考える（自分の考えは全体のどれだけを賄っているか）
全体でmust・never・wantを考えるが、各の機能must・never・wantも考える
（例：検索機能のmust・never・wantを考える）

上記を意識し生産性が高いエンジニアになろう。