A/Bテストでいちばん大切なこと - Kentaro Kuribayashi's blog
「A/Bテスト」が、Webサービスの最適化技法として人口に膾炙して久しい昨今ですが、それでもなお、個々の施策実行時にはいろいろと迷うことがあります。たとえば: 有用なテスト結果を得るためにパターンをどのような基準で用意すればよいのか テスト結果の統計的有意性をどのように検定すればよいのか 個々の改善がそれぞれによかったとしても、それらが局所最適に陥らないためにはどうしたらよいのか といったあたりが挙げられます。(2)については純粋に技術的な問題なので、ここでは議論しません。問題にしたいのは(1)および(3)についてです。ひとまず、いまのところ僕が思う一番大切なことをひとつだけ述べておきましょう。それは: 「それに対してなんらかの肯定的/否定的意見のあるパターンをテストする」 ということです。どういうことか。 視野狭窄的なA/Bテスト A/Bテスト、あるいは同様の最適化技法については、かつて
テスト書きすぎ問題 - hitode909の日記
テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う
テスト戦略、設計、手法、技法などなどのリンクをまとめてみた - うさぎ組
WACATE 2011 夏に申し込んだので、おさらいしましょう。ということでテスト手法、テスト技法を中心としたリンクをまとめてみました。 なので今回はTDDとかテストツールとかはあまり含まれていません。 いくつかかぶっているものもありますが、多面的な表現って大切だと思うので、多少のかぶりは気にせずに選択しました。 これを読めば良いソフトウェアエンジニアとして一歩階段を上れる気がしています。 他にも参考になるものがあったら、コメントやTwitterで@kyon_mmまで教えてくださるととっても嬉しいです！ 次の形式で書いています。 WEBサイト名、資料名：発表者（敬称略）：URL カテゴリー分けしたんですが、不適切であるかもしれません。間違い等あればご指摘ください。 また、ここでのリンクに問題がある場合は削除致しますので、その場合もご指摘ください。 TwitterID:kyon_mm mai
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
