「自動受け入れテスト」を考えてみる - 日々常々

きっかけは XP祭り関西2013 の @StoneGuitar777 さんのLTからです。 LTスライド: XP祭り2013-LT-Codeer @ITの記事: 特集：受け入れ検査の自動化手法の考察：Windowsアプリの受け入れテストを自動化しよう (1/5) - ＠IT 「継続的デリバリー」に貼付けた付箋を抜き出してみる 【大阪】継続的デリバリー読書会(8回目) - connpassの範囲でもありました。 受け入れ＝ビジネス的な受け入れ基準＝ユーザーの価値 ユニットテストとの色分け ユニットテスト: 作り手の意図 受け入れテスト: 顧客の意図 うまくやらないとコストが高すぎる 適切に作成して保守すれば自動のほうがはるかに安上がりになる ユニットテストやコンポーネントテストではどれほど包括的にやっても検出出来ない問題がある 手動テストはアプリケーションの複雑さに関わらずきわめて高くつく

[yujiorama]

テスト自動化のことを考えてると投資対効果が幅を効かせるようになる境界があるような気がしてる。根本的なこと？

[teppeis]

「私にとっての自動テストは基本的に手動テストを一発でOKにするためのもの」

[efcl]

自動受け入れテストについて コストと効率と目的の境界

[ryonext]

まさに今悩んでるとこだ。

[mokemokechicken]

落とし所を考えないといけないなぁ

[rti7743]

seleniumもアプリ改修時(特にUI)にダメになるし、なかなか難しいと思う

[absj31]

この辺に関するお話も今度して欲しいかもな～ (ﾁﾗｯﾁﾗｯ @irof

[mazinlabs]

読ませる

[gikazigo]

「自動受け入れテスト」を考えてみる - 日々常々

[calpo]

「継続的デリバリー」で説明されている「受け入れてスト」について

[pochi-mk]

自分もいつかちゃんと受け入れテスト自動化を考えないといけない。今は完全に手動で手間がかかり過ぎという問題がある。考えるタイミングは今しかないので、タイムリーな記事だった。