ການທົດສອບການຮັບຮອງ

«ເຄື່ອນໄຫວໄດ້» ກັບ «ໃຊ້ງານໄດ້» ແມ່ນຄົນລະເລື່ອງ

ໃນຂະນະທີ່ unit test ແລະ functional test ກວດສອບວ່າ «code ເຮັດວຽກຖືກຕ້ອງຫຼືບໍ່», ສ່ວນ acceptance test ແມ່ນກວດສອບວ່າ «ຕອບໂຈດທາງ business ຫຼືບໍ່». ເຖິງແມ່ນວ່າບໍ່ມີ bug ກໍຕາມ, ຖ້າພຶດຕິກຳຂອງລະບົບບໍ່ສອດຄ່ອງກັບ requirement ກໍບໍ່ສາມາດ release ໄດ້.

ການຂຽນ acceptance test ມັກຈະໃຊ້ຮູບແບບທີ່ໃກ້ຄຽງກັບພາສາທຳມະຊາດ. ຕົວຢ່າງເຊັ່ນ: «ເມື່ອ admin ເຂົ້າສູ່ລະບົບແລ້ວເປີດລາຍຊື່ພະນັກງານ, ຈະສະແດງສະເພາະພະນັກງານໃນ tenant ຂອງຕົນເອງເທົ່ານັ້ນ» ໂດຍຂຽນເປັນ scenario ທີ່ລະບຸການກະທຳຂອງ user ແລະຜົນລັບທີ່ຄາດຫວັງ. Gherkin (Given-When-Then) syntax ແມ່ນ format ທີ່ເປັນຕົວແທນຂອງຮູບແບບດັ່ງກ່າວ.

ລະດັບຂອງການ automate

ມີທັງ acceptance test ທີ່ດຳເນີນການດ້ວຍມື ແລະກໍລະນີທີ່ automate ດ້ວຍເຄື່ອງມືເຊັ່ນ Playwright. ໃນ ATDD (Acceptance Test-Driven Development) ນັ້ນ, ຈະກຳນົດ acceptance criteria ກ່ອນ, ຈາກນັ້ນ implement ເປັນ automated test ແລ້ວຈຶ່ງເລີ່ມ develop. ເນື່ອງຈາກການພຶ່ງພາ manual test ມັກເຮັດໃຫ້ຄວາມຖີ່ໃນການ execute ຫຼຸດລົງ, ການ automate scenario ທີ່ critical ຈຶ່ງກາຍເປັນ best practice ໃນການປະຕິບັດຕົວຈິງ.

ຄວາມສຳພັນກັບ Sprint Review

ໃນການພັດທະນາແບບ Scrum, ມັກຈະມີການກວດສອບຜົນຂອງ acceptance test ໃນ sprint review. ເນື່ອງຈາກເປັນຂໍ້ມູນທີ່ product owner ໃຊ້ຕັດສິນວ່າ «feature ນີ້ສາມາດ accept ໄດ້ຫຼືບໍ່», ສະນັ້ນ test scenario ຄວນໄດ້ຮັບການ agree ຮ່ວມກັນໃນທີມໃນຕອນ sprint planning ຈຶ່ງຈະເໝາະສົມທີ່ສຸດ.