ການເຂົ້າໃຈຜິດໂດຍອັດຕະໂນມັດທົ່ວໄປ

ໃນບົດຂຽນນີ້, ພວກເຮົາຈະພິຈາລະນາບາງຄວາມເຂົ້າໃຈຜິດຂອງການທົດສອບອັດຕະໂນມັດທີ່ມັກແລະວິທີການເຫຼົ່ານີ້ປ້ອງກັນບໍ່ໃຫ້ອົງກອນເຫຼົ່ານີ້ປະສົບຜົນ ສຳ ເລັດໃນການທົດສອບອັດຕະໂນມັດ.

ມັນບໍ່ຍາກທີ່ຈະຈິນຕະນາການເຖິງຜົນປະໂຫຍດຂອງການມີການທົດສອບແບບອັດຕະໂນມັດຄຽງຄູ່ກັບການພັດທະນາຜະລິດຕະພັນ - ການປ່ອຍຕົວໄວຂຶ້ນ, ການຄຸ້ມຄອງການທົດສອບທີ່ເພີ່ມຂື້ນ, ການປະຕິບັດການທົດສອບເລື້ອຍໆ, ການຕອບສະ ໜອງ ຕໍ່ທີມພັດທະນາໄວຂຶ້ນ, ພຽງແຕ່ຕັ້ງຊື່ໃຫ້ອີກສອງສາມອົງກອນ, ແຕ່ຍັງມີຫຼາຍອົງກອນຍັງບໍ່ທັນໄດ້ຍ້າຍຫຼືບໍ່ ທົນທານຕໍ່ການລົງທືນໃນການທົດສອບອັດຕະໂນມັດ.



ຄວາມເຂົ້າໃຈຜິດໂດຍອັດຕະໂນມັດ

ຄວາມເປັນໄປໄດ້ໃນແງ່ທີ່ຍາກແລະທ້າທາຍທີ່ສຸດຂອງຄວາມພະຍາຍາມອັດຕະໂນມັດຂອງການທົດສອບແມ່ນການເຂົ້າໃຈຂໍ້ ຈຳ ກັດຂອງການທົດສອບອັດຕະໂນມັດແລະການຕັ້ງເປົ້າ ໝາຍ ແລະຄວາມຄາດຫວັງທີ່ແທ້ຈິງເພື່ອຫລີກລ້ຽງຄວາມຜິດຫວັງ. ດ້ວຍຄວາມຄິດດັ່ງກ່າວ, ຂໍໃຫ້ເບິ່ງບາງຄວາມເຂົ້າໃຈຜິດແລະນິຍາຍ ທຳ ມະດາກ່ຽວກັບການອັດຕະໂນມັດການທົດສອບ:


ການທົດສອບອັດຕະໂນມັດແມ່ນດີກ່ວາການທົດສອບຄູ່ມື

ໂດຍອ້າງອີງໃສ່ບົດຄວາມ blog ຂອງ Michael Bolton ການທົດສອບທຽບກັບການກວດສອບ , ການທົດສອບແບບອັດຕະໂນມັດບໍ່ແມ່ນການທົດສອບແທ້ໆ. ມັນແມ່ນການກວດສອບຂໍ້ເທັດຈິງ. ເມື່ອພວກເຮົາມີຄວາມເຂົ້າໃຈກ່ຽວກັບລະບົບ, ພວກເຮົາສາມາດບັງຄັບຄວາມເຂົ້າໃຈນັ້ນໃນຮູບແບບຂອງການກວດສອບແລະຫຼັງຈາກນັ້ນໂດຍການ ດຳ ເນີນການກວດສອບແບບອັດຕະໂນມັດ, ພວກເຮົາຢັ້ງຢືນຄວາມເຂົ້າໃຈຂອງພວກເຮົາ. ໃນທາງກົງກັນຂ້າມ, ແມ່ນການອອກ ກຳ ລັງກາຍການສືບສວນເຊິ່ງພວກເຮົາມີຈຸດປະສົງທີ່ຈະໄດ້ຮັບຂໍ້ມູນ ໃໝ່ ກ່ຽວກັບລະບົບທີ່ຢູ່ພາຍໃຕ້ການທົດສອບໂດຍຜ່ານການ ສຳ ຫຼວດ.

ການທົດສອບຮຽກຮ້ອງໃຫ້ມະນຸດຕັດສິນໃຈຢ່າງຖືກຕ້ອງກ່ຽວກັບຄວາມເປັນໄປໄດ້ຂອງລະບົບ. ພວກເຮົາສາມາດເຫັນຈຸດຜິດລັກເມື່ອພວກເຮົາບໍ່ໄດ້ຄາດຄິດ. ພວກເຮົາບໍ່ຄວນອົດທົນຕໍ່ວິທີ ໜຶ່ງ ຫລືອີກທາງ ໜຶ່ງ, ເພາະວ່າທັງສອງວິທີການແມ່ນ ຈຳ ເປັນເພື່ອໃຫ້ມີຄວາມເຂົ້າໃຈກ່ຽວກັບຄຸນນະພາບຂອງການສະ ໝັກ.


ບັນລຸການທົດສອບອັດຕະໂນມັດ 100%

ເຊັ່ນດຽວກັນກັບບໍ່ມີວິທີການປະຕິບັດຕົວຈິງໃນການບັນລຸການຄຸ້ມຄອງການທົດສອບ 100% (ເນື່ອງຈາກການອະນຸຍາດທີ່ເປັນໄປໄດ້ບໍ່ມີທີ່ສິ້ນສຸດ), ມັນກໍ່ຄືກັນກັບການທົດສອບອັດຕະໂນມັດ. ພວກເຮົາສາມາດເພີ່ມການຄຸ້ມຄອງການທົດສອບໂດຍການທົດສອບແບບອັດຕະໂນມັດດ້ວຍຂໍ້ມູນເພີ່ມເຕີມ, ການຕັ້ງຄ່າຫຼາຍຂື້ນ, ກວມເອົາຫຼາຍໆລະບົບປະຕິບັດການ, ໂປຣແກຣມທ່ອງເວັບ, ແຕ່ການບັນລຸ 100% ແມ່ນຍັງເປັນເປົ້າ ໝາຍ ທີ່ບໍ່ມີຄວາມຈິງ. ໃນເວລາທີ່ມັນກ່ຽວກັບການທົດສອບອັດຕະໂນມັດ, ການທົດສອບເພີ່ມເຕີມບໍ່ໄດ້ ໝາຍ ຄວາມວ່າຄຸນນະພາບດີຫລືຄວາມ ໝັ້ນ ໃຈທີ່ດີກວ່າ. ມັນທັງ ໝົດ ແມ່ນຂື້ນກັບວ່າການອອກແບບການທົດສອບທີ່ດີຂື້ນ. ແທນທີ່ຈະແນໃສ່ການຄຸ້ມຄອງຢ່າງເຕັມທີ່ແທນທີ່ຈະ, ສຸມໃສ່ພື້ນທີ່ທີ່ ສຳ ຄັນທີ່ສຸດ ສຳ ລັບທຸລະກິດ.

ROI ດ່ວນ

ເມື່ອປະຕິບັດວິທີແກ້ໄຂແບບອັດຕະໂນມັດການທົດສອບ, ມີກິດຈະ ກຳ ພັດທະນາທີ່ກ່ຽວຂ້ອງກັນຫຼາຍກ່ວາພຽງແຕ່ກໍລະນີທົດສອບຕົວອັກສອນ. ໂດຍປົກກະຕິແລ້ວຕ້ອງມີການພັດທະນາກອບກອບທີ່ສາມາດສະ ໜັບ ສະ ໜູນ ການ ດຳ ເນີນງານຂອງ bespoke ເຊິ່ງເປັນປະໂຫຍດແລະມີຄວາມ ໝາຍ ສຳ ລັບທຸລະກິດເຊັ່ນ: ການຄັດເລືອກກໍລະນີການທົດສອບ, ການລາຍງານ, ການ ນຳ ໃຊ້ຂໍ້ມູນ, ແລະອື່ນໆ.

ການພັດທະນາກອບແມ່ນໂຄງການດ້ວຍຕົນເອງແລະຮຽກຮ້ອງໃຫ້ນັກພັດທະນາທີ່ມີສີມືແລະຕ້ອງໃຊ້ເວລາໃນການກໍ່ສ້າງ. ເຖິງແມ່ນວ່າໃນເວລາທີ່ໂຄງຮ່າງການເຮັດວຽກເຕັມທີ່, ການກວດສອບອັດຕະໂນມັດໃນການກວດສອບເບື້ອງຕົ້ນແມ່ນໃຊ້ເວລາດົນກວ່າການປະຕິບັດການທົດສອບແບບດຽວກັນດ້ວຍຕົນເອງ. ເພາະສະນັ້ນເມື່ອພວກເຮົາຮຽກຮ້ອງໃຫ້ມີ ຄຳ ຕຳ ນິຕິຊົມຢ່າງໄວວາກ່ຽວກັບຄຸນລັກສະນະ ໃໝ່ ທີ່ ກຳ ລັງພັດທະນາ, ການກວດສອບດ້ວຍຕົນເອງແມ່ນໄວກວ່າການທົດສອບໂດຍອັດຕະໂນມັດ. ເຖິງຢ່າງໃດກໍ່ຕາມ, ROI ຈະຖືກສົ່ງຄືນໃນໄລຍະຍາວເມື່ອພວກເຮົາຕ້ອງການທົດສອບດຽວກັນໃນໄລຍະປົກກະຕິ.

ອັດຕາການກວດພົບຜິດປົກກະຕິທີ່ສູງຂື້ນໂດຍຜ່ານການກວດສອບອັດຕະໂນມັດ

ເຖິງແມ່ນວ່າວິທີແກ້ໄຂການທົດສອບອັດຕະໂນມັດຂອງຜູ້ຂາຍແລະຜະລິດພາຍໃນບ້ານແມ່ນມີຄວາມຊັບຊ້ອນແລະມີຄວາມສາມາດສູງໃນການ ດຳ ເນີນງານທີ່ຊັບຊ້ອນ, ແຕ່ພວກເຂົາຈະບໍ່ສາມາດແຂ່ງຂັນກັບຄວາມສະຫຼາດຂອງນັກທົດລອງຂອງມະນຸດຜູ້ທີ່ສາມາດເຫັນຄວາມຜິດປົກກະຕິທີ່ບໍ່ຄາດຄິດໃນການສະ ໝັກ ໃນຂະນະທີ່ ສຳ ຫຼວດຫລື ປະຕິບັດຊຸດຂອງການທົດສອບສະຄິບຕໍ່ລະບົບທີ່ຢູ່ພາຍໃຕ້ການທົດສອບ. ກົງກັນຂ້າມ, ປະຊາຊົນຄາດຫວັງວ່າການທົດສອບແບບອັດຕະໂນມັດຈະພົບຂໍ້ບົກຜ່ອງຫຼາຍເພາະວ່າມີການກ່າວເຖິງການຄຸ້ມຄອງທີ່ເພີ່ມຂື້ນ, ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ, ນີ້ບໍ່ແມ່ນຄວາມຈິງ.


ແມ່ນແລ້ວ, ການທົດສອບແບບອັດຕະໂນມັດແມ່ນດີໃນການຫາບັນຫາການເກີດ ໃໝ່ - ຫຼັງຈາກທີ່ຄຸນສົມບັດ ໃໝ່ ໄດ້ຖືກເພີ່ມເຂົ້າໃນລະຫັດທີ່ມີຢູ່ແລ້ວ, ພວກເຮົາຕ້ອງຮັບປະກັນວ່າພວກເຮົາບໍ່ໄດ້ ທຳ ລາຍ ໜ້າ ທີ່ໃນປະຈຸບັນແລະພວກເຮົາຕ້ອງການຂໍ້ມູນນັ້ນຢ່າງໄວວາ - ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ມັກຈະມີຫນ້ອຍກ່ວາຫນ້າທີ່ໃຫມ່ທີ່ຖືກພັດທະນາ.

ອີກຈຸດ ໜຶ່ງ ທີ່ຕ້ອງ ຄຳ ນຶງເຖິງແມ່ນວ່າການກວດສອບແບບອັດຕະໂນມັດພຽງແຕ່ກວດເບິ່ງສິ່ງທີ່ພວກເຂົາໄດ້ຖືກ ກຳ ນົດໄວ້ເພື່ອກວດສອບໂດຍຜູ້ທີ່ຂຽນບົດ. ສະຄິບກໍ່ດີເທົ່າກັບຄົນທີ່ຂຽນມັນ. ການກວດສອບແບບອັດຕະໂນມັດທັງ ໝົດ ສາມາດຜ່ານໄປໄດ້ຢ່າງມີຄວາມສຸກແຕ່ຂໍ້ບົກຜ່ອງທີ່ ສຳ ຄັນສາມາດເບິ່ງຂ້າມເຊິ່ງສາມາດສ້າງຄວາມປະທັບໃຈທີ່ບໍ່ຖືກຕ້ອງກັບຄຸນນະພາບຂອງສິນຄ້າ. ໂດຍເນື້ອແທ້ແລ້ວ, ການກວດສອບສາມາດພິສູດໄດ້ວ່າມີຂໍ້ບົກຜ່ອງ, ແຕ່ມັນບໍ່ສາມາດພິສູດການຂາດຂອງພວກມັນ.

ພວກເຮົາພຽງແຕ່ຕ້ອງການເຄື່ອງຈັກທົດສອບອັດຕະໂນມັດ

ດັ່ງນັ້ນ, ຖ້າຄວາມເປັນໄປໄດ້ໃນການຊອກຫາຂໍ້ບົກພ່ອງຫຼາຍຂື້ນໃນການທົດສອບຄຸນສົມບັດ ໃໝ່, ເປັນຫຍັງພວກເຮົາບໍ່ທົດລອງທົດລອງອັດຕະໂນມັດທຽບກັບ ໜ້າ ທີ່ ໃໝ່ ຍ້ອນວ່າມັນ ກຳ ລັງຖືກພັດທະນາ? ດີ, ນີ້ແມ່ນບາງກໍລະນີສໍາລັບທີມທີ່ປະຕິບັດ TDD .

ນັກພັດທະນາຂຽນການທົດສອບຫົວ ໜ່ວຍ ກ່ອນ, ສັງເກດເບິ່ງວ່າມັນລົ້ມເຫລວແລະຫຼັງຈາກນັ້ນຂຽນລະຫັດພຽງພໍເພື່ອໃຫ້ ໜ່ວຍ ງານຜ່ານການທົດສອບແລະວົງຈອນຈະຖືກເຮັດຊ້ ຳ ອີກຈົນກ່ວາການເຮັດວຽກທີ່ມີຈຸດປະສົງຖືກສົ່ງ. ໂດຍເນື້ອແທ້ແລ້ວ, ການທົດສອບຫົວ ໜ່ວຍ ອັດຕະໂນມັດເຫຼົ່ານີ້ແມ່ນການກວດສອບການເຮັດວຽກ ໃໝ່ ແລະໃນໄລຍະເວລາພວກມັນປະກອບເປັນຊຸດ regression ຂອງ ໜ່ວຍ ເຊິ່ງຖືກປະຕິບັດຫຼາຍຄັ້ງຍ້ອນວ່າມີການເຮັດວຽກ ໃໝ່.


ແຕ່ວ່າ, ມັນກໍ່ມີຄວາມລະແວງສົງໄສຕໍ່ເລື່ອງນີ້. ໃນຂະນະທີ່ TDD ໄດ້ຮັບການສະ ໜັບ ສະ ໜູນ ສູງແລະເປັນການພັດທະນາທີ່ເຂັ້ມແຂງໃນການສ້າງຄຸນນະພາບຈາກພື້ນຖານ, ການທົດສອບຫົວ ໜ່ວຍ ແມ່ນດີພຽງແຕ່ຊອກຫາຂໍ້ຜິດພາດຂອງນັກຂຽນໂປແກມ, ບໍ່ແມ່ນຄວາມລົ້ມເຫຼວ. ມີລັກສະນະໃຫຍ່ກວ່າຂອງການທົດສອບທີ່ເກີດຂື້ນເມື່ອສ່ວນປະກອບທັງ ໝົດ ຖືກເຊື່ອມເຂົ້າກັນແລະສ້າງເປັນລະບົບ.

ໃນຄວາມເປັນຈິງ, ຫຼາຍອົງກອນມີສ່ວນໃຫຍ່ຂອງການກວດສອບອັດຕະໂນມັດຂອງພວກເຂົາທີ່ລະບົບ UI ລະບົບ. ເຖິງຢ່າງໃດກໍ່ຕາມ, ການກວດສອບ scripting ແບບອັດຕະໂນມັດ ສຳ ລັບ UI ຫລືລະບົບ, ໃນຂະນະທີ່ຄຸນລັກສະນະຕ່າງໆ ກຳ ລັງຖືກພັດທະນາແມ່ນ ໜ້າ ວຽກທີ່ ໜ້າ ຢ້ານທີ່ສຸດ, ເນື່ອງຈາກວ່າ ໜ້າ ທີ່ ໃໝ່ ນີ້ມີຄວາມຜັນຜວນ (ຂຶ້ນກັບການປ່ຽນແປງຫຼາຍຢ່າງ) ໃນລະຫວ່າງການພັດທະນາ. ອີກຢ່າງ ໜຶ່ງ, ໜ້າ ທີ່ທີ່ຄາດໄວ້ອາດຈະບໍ່ຮູ້ຈົນຮອດເວລາຕໍ່ມາ, ສະນັ້ນການໃຊ້ເວລາໃນການເຮັດວຽກທີ່ມີການປ່ຽນແປງແມ່ນບໍ່ໄດ້ຮັບການຊຸກຍູ້.

ພວກເຮົາພຽງແຕ່ຮຽກຮ້ອງໃຫ້ມີລະບົບການປັບປຸງລະບົບ UI ແບບອັດຕະໂນມັດເທົ່ານັ້ນ

ມີຄຸນຄ່າໃນການ ດຳ ເນີນການກວດສອບແບບອັດຕະໂນມັດໃນລະດັບ UI ແລະລະບົບ. ພວກເຮົາໄດ້ຮັບການເບິ່ງສິ່ງທີ່ຜູ້ໃຊ້ມີປະສົບການໃນເວລາທີ່ພົວພັນກັບຄໍາຮ້ອງສະຫມັກ; ພວກເຮົາສາມາດທົດສອບກະແສທ້າຍແລະທ້າຍການລວມຕົວຂອງພັກໃນເວລາທີ່ພວກເຮົາບໍ່ສາມາດທົດສອບຖ້າບໍ່ດັ່ງນັ້ນ; ພວກເຮົາຍັງສາມາດສະແດງການທົດສອບໃຫ້ແກ່ລູກຄ້າແລະຜູ້ຊົມໃຊ້ທີ່ສຸດເພື່ອໃຫ້ພວກເຂົາສາມາດຮູ້ສຶກໄດ້ເຖິງການຄຸ້ມຄອງການທົດສອບ. ເຖິງຢ່າງໃດກໍ່ຕາມ, ການອີງໃສ່ການກວດສອບແບບອັດຕະໂນມັດທີ່ຊັ້ນ UI ມີບັນຫາຂອງມັນເອງ.

UI ມີການປ່ຽນແປງເລື້ອຍໆເພື່ອເພີ່ມການອອກແບບສາຍຕາແລະການໃຊ້ງານແລະການກວດສອບແບບອັດຕະໂນມັດລົ້ມເຫລວຍ້ອນການປ່ຽນແປງຂອງ UI ແລະບໍ່ແມ່ນການປ່ຽນແປງໃນ ໜ້າ ທີ່ສາມາດສ້າງຄວາມຮູ້ສຶກທີ່ບໍ່ຖືກຕ້ອງຂອງສະພາບການຂອງແອັບພລິເຄຊັນ.


ການກວດສອບແບບອັດຕະໂນມັດຂອງ UI ຍັງມີຄວາມໄວຊ້າຫຼາຍກ່ວາຄວາມໄວຂອງການປະຕິບັດຫຼາຍກ່ວາຢູ່ໃນລະດັບຫນ່ວຍຫລື API ແລະຍ້ອນເຫດນີ້, ວົງຈອນຕອບສະ ໜອງ ຕໍ່ທີມແມ່ນຊ້າ. ມັນອາດຈະໃຊ້ເວລາສອງສາມຊົ່ວໂມງກ່ອນທີ່ຈະພົບຂໍ້ບົກຜ່ອງແລະລາຍງານກັບນັກພັດທະນາ. ແລະເມື່ອບາງສິ່ງບາງຢ່າງບໍ່ຖືກຕ້ອງ, ການວິເຄາະສາເຫດຂອງຮາກໃຊ້ເວລາດົນກວ່າເພາະວ່າມັນບໍ່ສາມາດເຫັນໄດ້ງ່າຍວ່າບັກຢູ່ບ່ອນໃດ.

ການເຂົ້າໃຈສະພາບການຂອງແຕ່ລະການທົດສອບແລະການທົດສອບແບບໃດທີ່ຄວນຈະອັດຕະໂນມັດແມ່ນມີຄວາມ ສຳ ຄັນ. ອັດຕະໂນມັດການທົດສອບຄວນເປັນສ່ວນ ໜຶ່ງ ຂອງກິດຈະ ກຳ ການພັດທະນາ, ສະນັ້ນທີມງານທັງ ໝົດ ແມ່ນຮັບຜິດຊອບໃນການທົດສອບອັດຕະໂນມັດ, ໂດຍນັກພັດທະນາຂຽນການທົດສອບຫົວ ໜ່ວຍ, ນັກພັດທະນາຊອບແວໃນການຂຽນການປະຕິບັດແລະຮັກສາການທົດສອບການຍອມຮັບທີ່ API ແລະ / ຫຼື UI.

ການສູນເສຍຄວາມເຊື່ອແລະຄວາມໄວ້ວາງໃຈໃນການທົດສອບອັດຕະໂນມັດ

ຂໍ້ສຸດທ້າຍນີ້ບໍ່ແມ່ນຄວາມລຶກລັບກ່ຽວກັບການທົດສອບອັດຕະໂນມັດ, ແຕ່ຜົນຂ້າງຄຽງເມື່ອການທົດສອບອັດຕະໂນມັດເຮັດຜິດ. ທ່ານໃຊ້ເວລາຫຼາຍຊົ່ວໂມງໃນການພັດທະນາວິທີແກ້ໄຂແບບອັດຕະໂນມັດແບບທົດສອບ, ໂດຍໃຊ້ເຄື່ອງມືແລະການປະຕິບັດທີ່ດີທີ່ສຸດ, ແຕ່ຖ້າການກວດສອບແບບອັດຕະໂນມັດບໍ່ຊ່ວຍໃຫ້ທີມງານມັນບໍ່ມີຄ່າ.

ຖ້າທີມງານບໍ່ມີການເບິ່ງເຫັນຫຼືຄວາມຮູ້ກ່ຽວກັບສິ່ງທີ່ຖືກປະຕິບັດໂດຍອັດຕະໂນມັດແລະການປະຕິບັດ, ພວກເຂົາອາດຈະປ່ອຍຕົວດ້ວຍຄວາມຢ້ານກົວທີ່ບໍ່ຮູ້ຈັກຫຼືຊໍ້າກັບຄວາມພະຍາຍາມທົດສອບການສືບພັນຂອງພວກເຂົາ. ຖ້າການກວດສອບແບບອັດຕະໂນມັດມີລັກສະນະແປກໆ, ຊ້າ, ໃຫ້ຜົນໄດ້ຮັບທີ່ມີການຂັດແຍ້ງກັນຫຼັງຈາກນັ້ນມັນສາມາດເຮັດໃຫ້ທີມງານສັບສົນຫຼາຍກ່ວາການສະ ໜອງ ຕາ ໜ່າງ ຄວາມປອດໄພແລະການເສີມສ້າງຄວາມ ໝັ້ນ ໃຈ.


ຢ່າຢ້ານທີ່ຈະ ກຳ ຈັດການກວດສອບແບບອັດຕະໂນມັດທີ່ມັກຈະລົ້ມເຫລວຫລືໃຫ້ຜົນໄດ້ຮັບທີ່ບໍ່ສອດຄ່ອງ. ແທນທີ່ຈະ, ແນໃສ່ຊຸດທົດສອບທີ່ສະອາດແລະເຊື່ອຖືໄດ້ເຊິ່ງສາມາດໃຫ້ຕົວຊີ້ບອກທີ່ຖືກຕ້ອງກ່ຽວກັບສຸຂະພາບຂອງການສະ ໝັກ.



ສະຫຼຸບ

ການທົດສອບອັດຕະໂນມັດແມ່ນການລົງທືນໄລຍະຍາວ. ມັນຈະຕ້ອງໃຊ້ເວລາແລະຄວາມ ຊຳ ນານໃນການພັດທະນາແລະຮັກສາກອບອັດຕະໂນມັດທົດສອບແລະອັກສອນອັດຕະໂນມັດ. ການທົດສອບອັດຕະໂນມັດບໍ່ແມ່ນຄວາມພະຍາຍາມແບບດຽວທີ່ທ່ານໃຫ້ທາງອອກແລະປ່ອຍໃຫ້ມັນໃຊ້ໄດ້. ມັນຕ້ອງການການຕິດຕາມກວດກາແລະປັບປຸງເລື້ອຍໆ.

ແທນທີ່ຈະຕັ້ງໃຈທົດແທນ QAs ຄູ່ມືຫຼືຄາດຫວັງວ່າການກວດສອບແບບອັດຕະໂນມັດເພື່ອຊອກຫາຂໍ້ບົກຜ່ອງຫຼາຍ, ພວກເຮົາຄວນຈະຮັບເອົາຂໍ້ໄດ້ປຽບທີ່ມັນ ນຳ ມາສູ່ທີມ, ເຊັ່ນ: ການປົດປ່ອຍເວລາ QA ສຳ ລັບການທົດລອງການຄົ້ນຄວ້າທີ່ມີຄວາມສ່ຽງຫຼາຍຂື້ນເຊິ່ງໂອກາດທີ່ຈະເປີດເຜີຍຂໍ້ບົກພ່ອງໄດ້ສູງສຸດ, ຫຼືໃຊ້ອັດຕະໂນມັດ ສະຄິບເພື່ອສ້າງຂໍ້ມູນການທົດສອບທີ່ສາມາດໃຊ້ ສຳ ລັບການທົດສອບຄູ່ມື.

ການເຂົ້າໃຈຂໍ້ ຈຳ ກັດແລະການຕັ້ງຄວາມຄາດຫວັງທີ່ແທ້ຈິງແມ່ນມີຄວາມ ສຳ ຄັນໃນການເອົາຊະນະຄວາມລຶກລັບເຫລົ່ານີ້ຂອງການທົດສອບອັດຕະໂນມັດ.