ເປັນຫຍັງພວກເຮົາຈຶ່ງຖື hackathon ສໍາລັບຜູ້ທົດສອບ?

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

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

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

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

ສິ່ງທີ່ພວກເຮົາພົບໃນເວລາທີ່ຊອກຫາຜູ້ທົດສອບ

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

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

ພວກເຮົາພະຍາຍາມແກ້ໄຂສະຖານະການແນວໃດ

ໂດຍໄດ້ໝົດຕົວເຮົາເອງກັບຜູ້ຊ່ຽວຊານດ້ານການກຽມຕົວ, ພວກເຮົາເລີ່ມຕັ້ງເປົ້າໝາຍໃສ່ພື້ນທີ່ໃກ້ຄຽງ:

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

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

   ພິ​ເສດ, ພວກ​ເຮົາ​ມາ​ເຖິງ​ບັນ​ດາ​ໜ້າ​ທີ່​ເພື່ອ​ທົດ​ສອບ​ຄວາມ​ເອົາ​ໃຈ​ໃສ່, ຄວາມ​ເຂົ້າ​ໃຈ​ຄວາມ​ສາ​ມາດ​ຂອງ​ເຕັກ​ໂນ​ໂລ​ຊີ ແລະ ຄຸນ​ລັກ​ສະ​ນະ​ຂອງ​ວັດ​ທະ​ນະ​ທຳ:

   
   

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

   ຂ້ອຍຈະບອກເຈົ້າເລັກນ້ອຍກ່ຽວກັບພວກມັນແຕ່ລະຄົນ.

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

   
   
   ຈາກ​ນັ້ນ, ​ໂດຍ​ມີ​ໄລຍະ​ເວລາ 1-2 ​ເດືອນ, ພວກ​ຂ້າພະ​ເຈົ້າ​ໄດ້​ດຳ​ເນີນ​ການ​ພົບ​ປະ​ອີກ 2 ຄັ້ງ. ມີຜູ້ເຂົ້າຮ່ວມຫຼາຍກວ່າສອງເທົ່າ. ທີ່ “Ufa Software QA and Testing Meetup #XNUMX” ພວກເຮົາໄດ້ລົງເລິກເຂົ້າໄປໃນສາຂາວິຊາ. ພວກເຂົາເຈົ້າໄດ້ສົນທະນາກ່ຽວກັບລະບົບການຕິດຕາມແມງໄມ້, ການທົດສອບ UI/UX, ແຕະໃສ່ Docker, Ansible, ແລະຍັງໄດ້ສົນທະນາກ່ຽວກັບຂໍ້ຂັດແຍ່ງທີ່ເປັນໄປໄດ້ລະຫວ່າງນັກພັດທະນາກັບຜູ້ທົດສອບ ແລະວິທີການແກ້ໄຂພວກມັນ.

   ກອງປະຊຸມຄັ້ງທີສາມຂອງພວກເຮົາ, "Ufa Software QA and Testing Meetup #3," ກ່ຽວຂ້ອງກັບການເຮັດວຽກຂອງນັກທົດສອບທາງອ້ອມ, ແຕ່ເປັນປະໂຫຍດໃນການເຕືອນນັກຂຽນໂປລແກລມໃຫ້ທັນເວລາກ່ຽວກັບຫນ້າທີ່ດ້ານວິຊາການແລະການຈັດຕັ້ງຂອງພວກເຂົາ: ການທົດສອບການໂຫຼດ, ການທົດສອບ e2e, Selenium ໃນ autotesting, ຊ່ອງໂຫວ່ຂອງແອັບພລິເຄຊັນເວັບ. .

   ຕະຫຼອດເວລານີ້ພວກເຮົາໄດ້ຮຽນຮູ້ວິທີການສ້າງແສງສະຫວ່າງແລະສຽງປົກກະຕິໃນການອອກອາກາດຈາກເຫດການຂອງພວກເຮົາ:

   → ຂັ້ນ​ຕອນ​ທໍາ​ອິດ​ໃນ​ການ​ທົດ​ສອບ – Ufa Software QA ແລະ​ການ​ທົດ​ສອບ Meetup #1​
   → ການທົດສອບ UI/UX – Ufa Software QA ແລະການທົດສອບ Meetup #2
   → ການທົດສອບຄວາມປອດໄພ, ການທົດສອບການໂຫຼດແລະການທົດສອບອັດຕະໂນມັດ - Ufa QA ແລະການທົດສອບກອງປະຊຸມ #3

3. ແລະໃນທີ່ສຸດພວກເຮົາໄດ້ຕັດສິນໃຈທີ່ຈະພະຍາຍາມຈັດ hackathon ສໍາລັບນັກທົດສອບ

ວິທີການທີ່ພວກເຮົາກະກຽມແລະດໍາເນີນການ hackathon ສໍາລັບຜູ້ທົດສອບ

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

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

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

ນີ້ແມ່ນສິ່ງທີ່ພວກເຮົາໄດ້ຮັບ: backlogs ສໍາລັບ hackathon.

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

ເຮົາ​ໄດ້​ເຮັດ​ຜິດ​ພາດ​ອັນ​ໃດ​ແດ່ ແລະ​ເຮົາ​ຈະ​ເຮັດ​ຫຍັງ​ໄດ້​ດີກວ່າ?

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

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

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

ຫຼັງຈາກການວິເຄາະຜົນຂອງເຫດການ, ພວກເຮົາຮູ້ວ່າພວກເຮົາເຮັດຜິດພາດຫຼາຍ:

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

ເຈົ້າປະສົບຜົນສຳເລັດຫຍັງແດ່?

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

ແຫຼ່ງຂໍ້ມູນ: www.habr.com