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 ໜຶ່ງອັນກ່ອນ, ແລ້ວຈຶ່ງຂະຫຍາຍຂອບເຂດອອກໄປຫຼັງຈາກຮູ້ສຶກໄດ້ເຖິງຜົນໄດ້ຮັບ.