基本
-
開発＆リリースが早すぎなので、継続的なメンテナンスや、テストを前もって計画するのが不可能
-
テストは開発の負担になるべきではない。テストは開発を遅らせるべきではない。
-
テスターの人数は少ない。テスターを増やすな。
-
ソフトウェアのクオリティはテスターの責任じゃない。すべてのエンジニアはテスター。
-
テストはソフトウェアのクオリティを上げる手段ではない。
-
クオリティを上げるなら、少しコーディングしたらテストする。コーディングはテストと同時に進行すべき。これでクオリティが保障される。
-
クオリティを上げるにはバグを発見する手段を探すではなく、バグを回避する手段を探すだ。
余談：Testing on the Toilet
http://www.flickr.com/photos/dullhunk/1019220380/sizes/l/in/photostream/
http://commondatastorage.googleapis.com/gtb/TotT-2008-08-14.pdf?hl=ja (100回目)
http://commondatastorage.googleapis.com/gtb/TotT-2013-03-20-state-vs-interactions-public.pdf (最新号)
roles
The Software Engineer (SWE)
- プロダクトのフィーチャーを書く
- 自分が作ったフィーチャーのユニットテストも書く
The Software Engineer in Test (SET)
- テスト自動化等のコードを書く
- リファクタリングのこともする
- SWEのテストに役に立つコード、テストフィーチャーを書く
The Test Engineer (TE)
- コードを書く人がいれば、書かない人もいる
- テスト自動化のコードを書く
- SWEとSETのつながりな存在
- ユーザの立場でソフトウェアのクオリティを見る、意見を出す
組織構成の話
- テスターはデベロッパーと同じプロダクトチームに配属される
- SWEはFA(Focus Area)単位でプロダクトマネージャーに報告する
- SETとTEはそういう人に報告しなく、Engineering Productivityのリーダーに報告する（配属もその人が優先度と必要性によって調整する）
- SETとTEを移動させる。アイディアを全社内で流通させる。
製品の話
- 最低限有用なプロダクトを最初バージョンとして作る
- 非常に小さいフィーチャーを少しづつリリースする
- 必ずdevチャンネルを経由させる（プロダクトの価値を証明するため）
テストの分類
small, medium, large だけ
しかしこういう命名は重要じゃない。重要なのは全員がテストの規模に対する認識が一致していること
small
- 自動テストが多い
- 機能面、データ破壊、エラーの条件、off-by-oneミス（境界ミス）等のテスト
- SWEが書く
- モック・fake環境を使う
medium
- 自動テストが多い
- 復数の（連動している）機能(nearest neighbor functions)のテストが多い
- SETが機能開発の前期からこういうテストを計画し、なんじゃらのテストコードを入れる
- 開発の後期にはTEが手動か自動でこういう中規模のテストを実行する
large
- ３つをそれ以上の機能をユーザ視点でテストする
- 経過より結果のほうを重視する
- コーディングはSWE, SET, TEが全員参加
- モックは使わない
手動か、自動か
- 人間が関与しなくていいテストは、自動化
- UIとか人間の目で見て確認する必要があるものなら、手動で
** グーグルにも手動テストをたくさんやってる