ATDD（Acceptance Test Driven Development）って実際どうですか？

受け入れテスト駆動開発というATDDですが、これから実装しようとしている機能に携わるステークホルダもしくは専任のQAエンジニアが受け入れテストを作成し、それをもとに実装者が実装をスタートしていくものと認識しております。

周りに実践している人がおらず、現在一人でトライアル中です。
今今は、実装する私がPdM作成の仕様把握 -> 受け入れテスト作成 -> 実装着手 -> PdM・デザイナーへレビュー依頼 という形をとっておりますが、いづれはPdMが仕様作成する段階(or デザイン起こし完了後)に受け入れテストをPdMも含めて作成したほうが出戻りが少なくなると思ってます。

ここ気をつけたほうがいいよ！ など、ご知見ありましたらご教授いただきたいですm
2年前
view数 279
  • 1
  • 3
  • 1
  • 2
  • 1

回答を投稿して企業にアピールしましょう！

Q&Aで投稿された回答は、
企業側に表示されるプロフィールにも投稿履歴として表示されます。

Offersにログイン・新規登録して、気になるテーマやトピックを話してみよう！

簡単1分登録(無料) ログインする

＼回答があります！／

  • 萩原 北斗

    エンジニア

    2年前

    ATDD の取り組み自体は良い考え方だと思います。
    スクラム開発の文脈では PO（PdMと同等と定義します） が受け入れ基準となる Acceptance Criteria（ここでは受け入れテストと同義とします） を定義することが謳われていますし、その原理主義的に言えば Shun さんのお考えも不自然ではないと思いました。

    一方で、気を払ったほうが良い点としては、実経験ベースでも挙がっていることなのですが、以下の点が挙げられると考えています。
    1. 受け入れテストを作成する担当者の知識（ドメイン、仕様）に依存する
    2. 受け入れテストの内容に目が向きすぎる

    （書いてたら文字数が足りず、後述します）
    view数 22