ATDD(Acceptance Test Driven Development)って実際どうですか?
受け入れテスト駆動開発というATDDですが、これから実装しようとしている機能に携わるステークホルダもしくは専任のQAエンジニアが受け入れテストを作成し、それをもとに実装者が実装をスタートしていくものと認識しております。
周りに実践している人がおらず、現在一人でトライアル中です。
今今は、実装する私がPdM作成の仕様把握 -> 受け入れテスト作成 -> 実装着手 -> PdM・デザイナーへレビュー依頼 という形をとっておりますが、いづれはPdMが仕様作成する段階(or デザイン起こし完了後)に受け入れテストをPdMも含めて作成したほうが出戻りが少なくなると思ってます。
ここ気をつけたほうがいいよ! など、ご知見ありましたらご教授いただきたいですm
周りに実践している人がおらず、現在一人でトライアル中です。
今今は、実装する私がPdM作成の仕様把握 -> 受け入れテスト作成 -> 実装着手 -> PdM・デザイナーへレビュー依頼 という形をとっておりますが、いづれはPdMが仕様作成する段階(or デザイン起こし完了後)に受け入れテストをPdMも含めて作成したほうが出戻りが少なくなると思ってます。
ここ気をつけたほうがいいよ! など、ご知見ありましたらご教授いただきたいですm
2年前
view数 279
- 1
- 3
- 1
- 2
- 1
回答を投稿して企業にアピールしましょう!
Q&Aで投稿された回答は、
企業側に表示されるプロフィールにも投稿履歴として表示されます。
Offersにログイン・新規登録して、気になるテーマやトピックを話してみよう!
\回答があります!/
萩原 北斗
エンジニア
2年前
ATDD の取り組み自体は良い考え方だと思います。
スクラム開発の文脈では PO(PdMと同等と定義します) が受け入れ基準となる Acceptance Criteria(ここでは受け入れテストと同義とします) を定義することが謳われていますし、その原理主義的に言えば Shun さんのお考えも不自然ではないと思いました。
一方で、気を払ったほうが良い点としては、実経験ベースでも挙がっていることなのですが、以下の点が挙げられると考えています。
1. 受け入れテストを作成する担当者の知識(ドメイン、仕様)に依存する
2. 受け入れテストの内容に目が向きすぎる
(書いてたら文字数が足りず、後述します)view数 22