ວິທີທີ່ທີມ QA ໃຊ້ອີເມວຊົ່ວຄາວເພື່ອທົດສອບການສະຫມັກ ແລະ ການເຂົ້າຮ່ວມໃນຂະຫນາດໃຫຍ່

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

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

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

TL; DR

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

ເຂົ້າ ເຖິງ ໄວ
ໃຫ້ແຈ່ມແຈ້ງເປົ້າຫມາຍການສະຫມັກ QA ສະໄຫມໃຫມ່
ວາງແຜນຈຸດຕິດຕໍ່ທາງອີເມວໃນ Onboarding
ເລືອກແບບແຜນຈົດຫມາຍຊົ່ວຄາວທີ່ຖືກຕ້ອງ
ລວມເອົາຈົດຫມາຍຊົ່ວຄາວເຂົ້າກັບອັດຕະໂນມັດ
ຈັບ OTP ແລະ ກໍລະນີ Verification Edge
ປົກປ້ອງຂໍ້ມູນທົດສອບ ແລະ ພັນທະການປະຕິບັດຕາມ
ປ່ຽນການຮຽນຮູ້ QA ໃຫ້ເປັນການປັບປຸງຜະລິດຕະພັນ
ຄໍາຖາມທີ່ຖາມເລື້ອຍໆ

ໃຫ້ແຈ່ມແຈ້ງເປົ້າຫມາຍການສະຫມັກ QA ສະໄຫມໃຫມ່

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

ຈາກຮູບແບບທີ່ຫັກໄປສູ່ວັດແທກປະສົບການ

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

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

ຫີບເຂົ້າຊົ່ວຄາວເປັນວິທີທີ່ໃຊ້ການໄດ້ໃນການສ້າງຈໍານວນການສະຫມັກສອບເສັງທີ່ຈໍາເປັນເພື່ອຕິດຕາມວັດແທກເຫຼົ່ານັ້ນດ້ວຍຄວາມຫມັ້ນໃຈ. ເມື່ອ QA ສາມາດ ແລ່ນ ຂະ ບວນການ end-to-end ຫລາຍ ຮ້ອຍ ເທື່ອ ໃນ ວົງ ຈອນ ການ ຖອຍ ຫລັງ, ການ ປ່ຽນ ແປງ ເລັກ ນ້ອຍ ໃນ ເວລາ ສົ່ງ ຫລື ຄວາມ ເຊື່ອ ຖື ຂອງ link ຈະ ປະກົດ ວ່າ ເປັນ ຕົວ ເລກ ແທ້ໆ, ບໍ່ ແມ່ນ ເລື່ອງ ເລົ່າ.

ສອດຄ່ອງກັບທີມ QA, ຜະລິດຕະພັນ ແລະ ການເຕີບໂຕ

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

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

ຜົນ ທີ່ ຕາມ ມາ ກໍ ງ່າຍໆ: ການ ສອດ ຄ່ອງ ກັບ ການ ເດີນ ທາງ ຈະ ບັງຄັບ ໃຫ້ ມີ ການ ທົດ ສອບ ທີ່ ດີກວ່າ. ແທນ ທີ່ ຈະ ຂຽນ script ການ ສະຫມັກ ໃນ ເສັ້ນທາງ ດຽວ ທີ່ ມີ ຄວາມສຸກ, ທີມ ຈະ ອອກ ແບບ ຊຸດ ທີ່ ລວມ ທັງ ຜູ້ ມາ ຢ້ຽມຢາມ ເທື່ອ ທໍາ ອິດ, ຜູ້ ໃຊ້ ທີ່ ກັບ ຄືນ ມາ, ການ ລົງ ຊື່ ຂ້າມ ອຸປະກອນ ແລະ ກໍລະນີ ຂອບ ເຂດ, ດັ່ງ ເຊັ່ນ ການ ເຊື້ອ ເຊີນ ທີ່ ຫມົດ ອາຍຸ ແລະ ການ ຕິດ ຕໍ່ ກັບ ຄືນ ໃຫມ່.

ກໍານົດ ຄວາມ ສໍາ ເລັດ ຜົນ ສໍາ ລັບ ການ ເດີນ ທາງ ທາງ ອີ ເມວ

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

QA ທີ່ ມີ ປະສິດທິພາບ ຖື ວ່າ ການ ເດີນທາງ ທາງ ອີ ເມວ ເປັນ ລະບົບ ທີ່ ວັດ ແທກ ໄດ້. ວັດແທກຫຼັກລວມເຖິງອັດຕາການສົ່ງອີເມວຢືນຢັນ, ເວລາໄປສົ່ງອີເມວ, ການສໍາເລັດການຢືນຢັນ, ພຶດຕິກໍາການສົ່ງຄືນ, ການວາງໂປຣແກຣມຫຼືການໂຄສະນາ, ແລະ ການຫລຸດລົງລະຫວ່າງການເປີດອີເມວແລະການກະທໍາ. ແຕ່ລະວັດແທກກ່ຽວຂ້ອງກັບຄໍາຖາມທີ່ສາມາດທົດສອບໄດ້. ຕາມ ປົກກະຕິ ແລ້ວ ອີ ເມວ ຢືນຢັນ ຈະ ມາ ເຖິງ ພາຍ ໃນ ສອງ ສາມ ວິນາທີ ໃນ ຫລາຍ ກໍລະນີ. ການສົ່ງຄືນຈະເຮັດໃຫ້ລະຫັດທີ່ຜ່ານມາເປັນโมฆะຫຼືເກັບໄວ້ໂດຍບໍ່ຕັ້ງໃຈບໍ? ເຈົ້າຮູ້ບໍວ່າສໍາເນົາອະທິບາຍຢ່າງຈະແຈ້ງວ່າຈະເກີດຫຍັງຂຶ້ນຕໍ່ໄປ?

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

ວາງແຜນຈຸດຕິດຕໍ່ທາງອີເມວໃນ Onboarding

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

ລາຍ ຊື່ ອີ ເມວ ທຸກ ຢ່າງ ໃນ ການ ເດີນ ທາງ

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

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

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

ຈັບ ເວລາ, ຊ່ອງ ແລະ ເງື່ອນ ໄຂ

ອີ ເມວ ບໍ່ ໄດ້ ເປັນ ພຽງ ແຕ່ ອີ ເມວ ເທົ່າ ນັ້ນ. ມັນ ເປັນ ຊ່ອງ ທາງ ທີ່ ແຂ່ງ ຂັນ ກັບ ການ ສົ່ງ ຂໍ້ ມູນ, ການ ກະ ຕຸ້ນ ໃນ ແອັບ, SMS ແລະ ບາງ ເທື່ອ ແມ່ນ ແຕ່ ການ ເອື້ອມ ອອກ ໄປ ຫາ ມະ ນຸດ. ເມື່ອ ທີມ ບໍ່ ສາມາດ ກໍານົດ ເວລາ ແລະ ເງື່ອນ ໄຂ ຢ່າງ ແຈ່ມ ແຈ້ງ, ຜູ້ ໃຊ້ ຈະ ໄດ້ ຮັບ ຂ່າວສານ ທີ່ ຊ້ໍາ ກັນ ຫລື ບໍ່ ມີ ຫຍັງ ເລີຍ.

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

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

ລະບຸການຫລັ່ງໄຫລທີ່ມີຄວາມສ່ຽງສູງໂດຍໃຊ້ລະຫັດ OTP

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

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

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

ເລືອກແບບແຜນຈົດຫມາຍຊົ່ວຄາວທີ່ຖືກຕ້ອງ

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

Single Shared Inbox Versus Per-Test Inboxes

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

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

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

Address ທີ່ ໃຊ້ ຄືນ ໄດ້ ສໍາລັບ ການ ເດີນທາງ ອັນ ຍາວ ນານ

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

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

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

ຍຸດທະສາດຂອບເຂດສໍາລັບສະພາບແວດລ້ອມ QA ແລະ UAT

domain ທີ່ຢູ່ ເບື້ອງ ຂວາ ຂອງ ອີ ເມວ ແມ່ນ ເກີນ ກວ່າ ການ ເລືອກ ຂອງ brand. ມັນກໍານົດວ່າ MX server ໃດທີ່ຈັດການກັບການຈໍາຫນ່າຍ, ວິທີທີ່ລະບົບຮັບຈະປະເມີນຊື່ສຽງ ແລະຄວາມສາມາດໃນການສົ່ງຍັງມີສຸຂະພາບດີຫຼືບໍ່ເມື່ອຈໍານວນການທົດສອບເພີ່ມຂຶ້ນ.

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

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

ລວມເອົາຈົດຫມາຍຊົ່ວຄາວເຂົ້າກັບອັດຕະໂນມັດ

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

ການ ດຶງ ເອົາ ອີ ເມວ ໃຫມ່ ຢູ່ ໃນ ການ ທົດ ສອບ

ອີ ເມວ ທີ່ ມີ ໂປຣແກຣມ ຢູ່ ໃນ ການ ທົດ ສອບ ເປັນ ແຫລ່ງ ທໍາ ມະ ດາ ຂອງ ການ ສອບ ເສັງ. ເມື່ອ script ໄດ້ ຢືນຢັນ address ຫລື trigger a edge case, ການ ແລ່ນ ໃນ ອະນາຄົດ ອາດ ປະພຶດ ທີ່ ແຕກ ຕ່າງ ກັນ, ເຮັດ ໃຫ້ ທີມ ສົງໄສ ວ່າ ຄວາມ ລົ້ມ ເຫ ລວ ນັ້ນ ເປັນ bug ແທ້ໆ ຫລື ເປັນ ຜົນ ສະທ້ອນ ຂອງ ຂໍ້ ມູນ ທີ່ ໃຊ້ ຄືນ ໃຫມ່.

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

ສ່ວນສໍາຄັນກໍຄື ເຄື່ອງທົດສອບ, ບໍ່ແມ່ນຜູ້ພັດທະນາ, ເປັນເຈົ້າຂອງການສ້າງອີເມວ. ເມື່ອ harness ສາມາດ ຂໍ ຮ້ອງ ແລະ ເກັບ ລາຍ ລະອຽດ ຂອງ inbox ຊົ່ວຄາວ ໂດຍ ທາງ ໂປຣແກຣມ, ມັນ ຈະ ກາຍ ເປັນ ເລື່ອງ ເລັກ ນ້ອຍ ທີ່ ຈະ ແລ່ນ ຊຸດ ດຽວ ກັນ ໃນ ຫລາຍໆ ສະພາບ ແວດ ລ້ອມ ແລະ ສາຂາ ໂດຍ ບໍ່ ຕ້ອງ ແຕະຕ້ອງ script ທີ່ຢູ່ ຂ້າງ ໃນ.

ການຟັງອີເມວແລະສະກັດກັ້ນການເຊື່ອມຕໍ່ຫຼືລະຫັດ

ເມື່ອຂັ້ນຕອນການລົງທະບຽນຖືກກະຕຸ້ນແລ້ວ, ການທົດສອບຕ້ອງມີວິທີທີ່ເຊື່ອຖືໄດ້ເພື່ອລໍຖ້າອີເມວທີ່ຖືກຕ້ອງແລະເອົາຂໍ້ມູນທີ່ກ່ຽວຂ້ອງອອກຈາກອີເມວນັ້ນ. ຕາມ ປົກກະຕິ ແລ້ວ ນັ້ນ ຫມາຍ ຄວາມ ວ່າ ການ ຟັງ inbox, polling API ຫລື ໃຊ້ webhook ທີ່ ເປີດ ຂ່າວສານ ໃຫມ່.

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

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

ການ ທົດ ສອບ ທີ່ ຫມັ້ນຄົງ ເພື່ອ ຕ້ານທານ ກັບ ການ ຊັກ ຊ້າ ຂອງ ອີ ເມວ

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

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

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

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

ຈັບ OTP ແລະ ກໍລະນີ Verification Edge

ການອອກແບບການທົດສອບທີ່ເຈຕະນາທໍາລາຍລະບົບ OTP ແລະ ການກວດສອບກ່ອນຜູ້ໃຊ້ແທ້ໆຈະປະສົບກັບຄວາມຂັດແຍ່ງທີ່ເກີດຂຶ້ນ.

ການจําลองຂ່າວສານ OTP ທີ່ຊ້າຫຼືສູນເສຍ

ຈາກ ທັດສະນະ ຂອງ ຜູ້ ໃຊ້, OTP ທີ່ ສູນ ເສຍ ໄປ ຈະ ຮູ້ສຶກ ວ່າ ບໍ່ ແຕກ ຕ່າງ ຈາກ ຜະລິດພັນ ທີ່ ຫັກ. ຜູ້ ຄົນ ບໍ່ ຄ່ອຍ ຈະ ກ່າວ ໂທດ ຜູ້ ຈັດ ຫາ ອີ ເມວ ຂອງ ເຂົາ ເຈົ້າ; ແທນ ທີ່, ເຂົາ ເຈົ້າຄິດ ວ່າ app ບໍ່ ທໍາ ງານ ແລະ ດໍາ ເນີນ ຕໍ່ ໄປ. ດ້ວຍເຫດນີ້ການจําลองລະຫັດທີ່ຊ້າໆຫຼືຂາດໄປຈຶ່ງເປັນຫນ້າທີ່ຮັບຜິດຊອບຫຼັກຂອງທີມ QA.

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

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

ການທົດສອບຂໍ້ຈໍາກັດການສົ່ງຄືນແລະຂໍ້ຄວາມຜິດພາດ

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

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

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

ການກວດສອບການບັງຄັບໂດເມນ, ເຄື່ອງຕອງ Spam ແລະຂໍ້ຈໍາກັດຂອງອັດຕາ

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

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

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

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

ປົກປ້ອງຂໍ້ມູນທົດສອບ ແລະ ພັນທະການປະຕິບັດຕາມ

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

ຫຼີກລ່ຽງຂໍ້ມູນລູກຄ້າແທ້ໆໃນ QA

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

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

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

ການ ແບ່ງ ແຍກ QA Traffic ຈາກ ຊື່ ສຽງ ຂອງ ການ ຜະລິດ

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

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

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

ການບັນທຶກການໃຊ້ຈົດຫມາຍຊົ່ວຄາວສໍາລັບການກວດສອບ

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

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

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

ປ່ຽນການຮຽນຮູ້ QA ໃຫ້ເປັນການປັບປຸງຜະລິດຕະພັນ

ປິດ ວົງ ຈອນ ເພື່ອ ວ່າ ຄວາມ ຮູ້ ແຈ້ງ ທຸກ ຢ່າງ ຈາກ ການ ທົດ ສອບ ທີ່ ໃຊ້ ຈົດຫມາຍ ຊົ່ວຄາວ ຈະ ເຮັດ ໃຫ້ ການ ສະຫມັກ ງ່າຍ ຂຶ້ນ ສໍາລັບ ຜູ້ ໃຊ້ ແທ້ໆ.

ແບບ ແຜນ ການ ລາຍ ງານ ໃນ ການ ລົງ ຊື່ ທີ່ ລົ້ມ ເຫລວ

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

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

ການແບ່ງປັນຄວາມຮູ້ກັບທີມຜະລິດຕະພັນ ແລະ ການເຕີບໂຕ

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

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

ການ ສ້າງ ປຶ້ມ ທີ່ ມີ ຊີວິດ ຢູ່ ສໍາລັບ ການ ທົດ ສອບ ການ ສະຫມັກ

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

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

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

ແຫຼ່ງຂໍ້ມູນ

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

ຄໍາຖາມທີ່ຖາມເລື້ອຍໆ

ແກ້ໄຂຄວາມເປັນຫ່ວງທົ່ວໄປທີ່ທີມ QA ຍົກຂຶ້ນມາກ່ອນທີ່ຈະນໍາໃຊ້ອີເມວຊົ່ວຄາວເປັນສ່ວນສໍາຄັນຂອງເຄື່ອງມືການທົດສອບຂອງເຂົາເຈົ້າ.

ເຮົາສາມາດໃຊ້ອີເມວຊົ່ວຄາວໃນອຸດສະຫະກໍາທີ່ມີການຄວບຄຸມໄດ້ບໍ?

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

ເຮົາຈໍາເປັນຕ້ອງມີຈົດຫມາຍຊົ່ວຄາວຈັກຫນ່ວຍສໍາລັບ QA?

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

domain mail ຊົ່ວຄາວຈະຖືກປິດກັ້ນໂດຍແອັບຂອງເຮົາເອງ ຫຼື ESP ບໍ?

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

ເຮົາຈະຮັກສາການທົດສອບ OTP ໄວ້ວາງໃຈໄດ້ແນວໃດເມື່ອອີເມວຊັກຊ້າ?

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

ເມື່ອ ໃດ ທີ່ QA ຄວນ ຫລີກ ເວັ້ນຈາກ ການ ໃຊ້ ອີ ເມວ ຊົ່ວຄາວ ແລະ ໃຊ້ ທີ່ ຢູ່ ແທ້ໆ?

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

ເຮົາສາມາດໃຊ້ທີ່ຢູ່ຊົ່ວຄາວແບບດຽວກັນໃນການທົດລອງຫຼາຍເທື່ອໄດ້ບໍ?

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

ເຮົາ ຈະ ອະທິບາຍ ກ່ຽວ ກັບ ການ ໃຊ້ ຈົດຫມາຍ ຊົ່ວຄາວ ໃຫ້ ແກ່ ທິມ ຄວາມ ປອດ ໄພ ແລະ ການ ປະຕິບັດ ຕາມ ກົດຫມາຍ ໄດ້ ແນວ ໃດ?

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

ຈະ ມີ ຫຍັງ ເກີດ ຂຶ້ນ ຖ້າ ຫາກ ອາຍຸ ຂອງ inbox ສັ້ນກວ່າ ການ ເດີນທາງ ຂອງ ເຮົາ?

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

ທີ່ຢູ່ອີເມວຊົ່ວຄາວສາມາດທໍາລາຍການວິເຄາະຫຼືການຕິດຕາມຊ່ອງທາງໄດ້ບໍ?

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

inbox ຊົ່ວຄາວຈະເຂົ້າກັບຍຸດທະວິທີການອັດຕະໂນມັດ QA ທີ່ກວ້າງຂວາງໄດ້ແນວໃດ?

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

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