ATDD

## ຄວາມແຕກຕ່າງຈາກ TDD ໃນຂະນະທີ່ TDD ຂັບເຄື່ອນການອອກແບບໂຄດຂອງນັກພັດທະນາ, ATDD ມີຈຸດປະສົງເພື່ອໃຫ້ທີມງານທັງໝົດເຂົ້າໃຈຄວາມຕ້ອງການທາງທຸລະກິດຕົງກັນ. ເຊັ່ນດຽວກັບທີ່ວົງຈອນຂອງ TDD ແມ່ນ「RED→GREEN→Refactor」, ATDD ກໍມີວົງຈອນທີ່ຊັດເຈນເຊັ່ນກັນ. 1. **Discuss（ການປຶກສາຫາລື）**: Product Owner, ນັກພັດທະນາ ແລະ QA ປຶກສາຫາລືກ່ຽວກັບຄວາມຕ້ອງການ ແລະ ຕົກລົງເຫັນດີກ່ຽວກັບເກນການຮັບຮອງໂດຍໃຊ້ຕົວຢ່າງສະເພາະ 2. **Distill（ການສັງລວມ）**: ນຳເກນທີ່ຕົກລົງກັນໄດ້ໄປຈັດຮູບແບບໃຫ້ເປັນໂຄງສ້າງ ເຊັ່ນ Given-When-Then ເປັນຕົ້ນ 3. **Develop（ການພັດທະນາ）**: ເຮັດໃຫ້ການທົດສອບການຮັບຮອງເປັນອັດຕະໂນມັດ ແລ້ວເລີ່ມຕົ້ນການ implement ຈາກສະຖານະທີ່ການທົດສອບຢູ່ໃນສະຖານະ RED 4. **Demo（ການສາທິດ）**: ເມື່ອການທົດສອບຜ່ານເປັນ GREEN ແລ້ວ ໃຫ້ສາທິດໃຫ້ Stakeholder ເບິ່ງ ## ການປຶກສາສາມຝ່າຍ（Three Amigos） ຫົວໃຈຂອງ ATDD ຢູ່ທີ່「ການປຶກສາສາມຝ່າຍ」ກ່ອນການ implement. ການປຶກສາຫາລືເກນການຮັບຮອງຈາກ 3 ມຸມມອງ ຄື ຝ່າຍທຸລະກິດ, ນັກພັດທະນາ ແລະ Tester ຊ່ວຍໃຫ້ສາມາດແກ້ໄຂຄວາມບໍ່ຊັດເຈນຂອງ Specification ແລະ ຄວາມເຂົ້າໃຈທີ່ຄາດເຄື່ອນໄດ້ຕັ້ງແຕ່ຕົ້ນ. ມີຜົນດີຢ່າງຫຼວງຫຼາຍໃນການປ້ອງກັນການຕ້ອງກັບຄືນໄປແກ້ໄຂໃໝ່ ເຊັ່ນ「ບໍ່ໄດ້ໝາຍຄວາມວ່ານັ້ນ」ຫຼັງຈາກເລີ່ມຂຽນໂຄດໄປແລ້ວ. ## ອຸປະສັກໃນການນຳໃຊ້ ເນື່ອງຈາກ ATDD ສົ່ງຜົນກະທົບຕໍ່ກະບວນການພັດທະນາທັງໝົດ, ມັນຈຶ່ງບໍ່ແມ່ນສິ່ງທີ່ຈະເລີ່ມຕົ້ນໄດ້ພຽງແຕ່ການຕິດຕັ້ງ Tool. ສະມາຊິກທີມທຸກຄົນຈຳເປັນຕ້ອງຄຸ້ນເຄີຍກັບວິທີການຂຽນເກນການຮັບຮອງ ແລະ ການມີສ່ວນຮ່ວມຢ່າງຈິງຈັງຂອງ Product Owner ກໍເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້. ວິທີທີ່ເປັນຈິງທີ່ສຸດຄືການລອງໃຊ້ກັບ User Story ໜຶ່ງອັນກ່ອນ, ແລ້ວຈຶ່ງຂະຫຍາຍຂອບເຂດອອກໄປຫຼັງຈາກຮູ້ສຶກໄດ້ເຖິງຜົນໄດ້ຮັບ.