Gruntle Software & Testing

ການທົດສອບຊອບແວທີ່ສໍາຄັນ metrics ແລະການວັດແທກ - ອະທິບາຍດ້ວຍຕົວຢ່າງແລະກາຟ

ຂຽນ​ຂໍ້​ຄວາມ​ຈາກ Stewart Tristianໂພສ​ໄດ້​ອອກ​ແລ້ວ ໂພສ​ໃນ ຜູ້ແນະນຳ

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

ໃນບົດຄວາມມື້ນີ້, ພວກເຮົາຈະຮຽນຮູ້ ດ້ວຍຕົວຢ່າງ ແລະກຣາບ – ການວັດແທກແລະການວັດແທກຊອບແວ ແລະວິທີການນຳໃຊ້ສິ່ງເຫຼົ່ານີ້ໃນຂະບວນການທົດສອບຊອບແວ.

ມີຄຳເວົ້າທີ່ມີຊື່ສຽງຄື: “ພວກເຮົາບໍ່ສາມາດຄວບຄຸມສິ່ງທີ່ພວກເຮົາວັດແທກບໍ່ໄດ້”.3

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

ແມ່ນຫຍັງ ຕົວຊີ້ວັດການທົດສອບຊອບແວ?

A Metric ແມ່ນການວັດແທກປະລິມານຂອງລະດັບທີ່ລະບົບ, ອົງປະກອບຂອງລະບົບ, ຫຼືຂະບວນການມີຄຸນສົມບັດທີ່ໃຫ້ໄວ້.

ການວັດແທກສາມາດຖືກກຳນົດເປັນ “ມາດຕະຖານ ຂອງ ການວັດແທກ ”.

ການວັດແທກຊອບແວແມ່ນໃຊ້ເພື່ອວັດແທກຄຸນນະພາບຂອງໂຄງການ. . ເວົ້າງ່າຍໆ, Metric ແມ່ນຫົວໜ່ວຍທີ່ໃຊ້ໃນການອະທິບາຍຄຸນລັກສະນະ. ເມຕຣິກແມ່ນມາດຖານສຳລັບການວັດແທກ. ເຊັ່ນດຽວກັນ, ໃນຊອຟແວ, "ວິທີການຈໍານວນຫຼາຍບັນຫາໄດ້ຖືກພົບເຫັນຢູ່ໃນລະຫັດເປັນພັນເສັ້ນ?”, h ere ບໍ່. ຂອງ​ບັນ​ຫາ​ແມ່ນ​ຫນຶ່ງ​ໃນ​ການ​ວັດ​ແທກ & amp​; ໝາຍເລກຂອງລະຫັດແມ່ນການວັດແທກອີກອັນໜຶ່ງ. ເມຕຣິກແມ່ນຖືກກໍານົດຈາກການວັດແທກສອງອັນນີ້ .

ຕົວຢ່າງການວັດແທກການທົດສອບ:

  • ມີຂໍ້ບົກພ່ອງຫຼາຍປານໃດພາຍໃນ ໂມດູນ?
  • ມີກໍລະນີທົດສອບຈຳນວນເທົ່າໃດຕໍ່ຄົນ?
  • ຄວາມຄຸ້ມຄອງການທົດສອບແມ່ນຫຍັງ?

ການວັດແທກການທົດສອບຊອບແວແມ່ນຫຍັງ?

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

ຕົວຢ່າງການທົດສອບການວັດແທກ: ຈຳນວນຂໍ້ບົກພ່ອງທັງໝົດ.

ກະລຸນາເບິ່ງແຜນວາດຂ້າງລຸ່ມນີ້ເພື່ອຄວາມເຂົ້າໃຈຢ່າງຈະແຈ້ງກ່ຽວກັບຄວາມແຕກຕ່າງລະຫວ່າງການວັດແທກ & Metrics.

ເປັນຫຍັງຕ້ອງທົດສອບ Metrics?

ການສ້າງຕົວວັດແທກການທົດສອບຊອບແວແມ່ນຄວາມຮັບຜິດຊອບທີ່ສໍາຄັນທີ່ສຸດຂອງຜູ້ນໍາ/ຜູ້ຈັດການການທົດສອບຊອບແວ> ຕັດສິນໃຈສໍາລັບໄລຍະຕໍ່ໄປຂອງກິດຈະກໍາເຊັ່ນ, ຄາດຄະເນຄ່າໃຊ້ຈ່າຍ & amp; ກຳນົດເວລາຂອງໂຄງການໃນອະນາຄົດ.

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

    • ຄວາມສຳຄັນຂອງຕົວຊີ້ວັດການທົດສອບຊອບແວ:

    ດັ່ງທີ່ອະທິບາຍໄວ້ຂ້າງເທິງ, ໂຕວັດແທກການທົດສອບແມ່ນສຳຄັນທີ່ສຸດທີ່ຈະວັດແທກຄຸນນະພາບຂອງຊອບແວໄດ້.

    ດຽວນີ້, ພວກເຮົາຈະວັດແທກໄດ້ແນວໃດ? ຄຸນ​ນະ​ພາບ​ຂອງ​ຊອບແວໂດຍໃຊ້ Metrics ?

    ສົມມຸດວ່າ, ຖ້າໂຄງການບໍ່ມີຕົວຊີ້ບອກໃດໆ, ແລ້ວຄຸນນະພາບຂອງວຽກທີ່ນັກວິເຄາະທົດສອບຈະຖືກວັດແທກແນວໃດ?

    ຕົວຢ່າງ, ນັກວິເຄາະການທົດສອບຕ້ອງ,

    1. ອອກແບບກໍລະນີທົດສອບສໍາລັບ 5 ຄວາມຕ້ອງການ
    2. ປະຕິບັດກໍລະນີທົດສອບທີ່ອອກແບບມາ
    3. ບັນທຶກຂໍ້ບົກພ່ອງ & ຈໍາເປັນຕ້ອງລົ້ມເຫລວໃນກໍລະນີການທົດສອບທີ່ກ່ຽວຂ້ອງ
    4. ຫຼັງຈາກຂໍ້ບົກພ່ອງໄດ້ຖືກແກ້ໄຂແລ້ວ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ທົດສອບຂໍ້ບົກພ່ອງຄືນໃຫມ່ & ປະຕິບັດກໍລະນີການທົດສອບທີ່ລົ້ມເຫລວທີ່ສອດຄ້ອງກັນຄືນໃຫມ່.

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

    ຖ້າ Metrics ມີສ່ວນຮ່ວມໃນໂຄງການ, ສະຖານະການທີ່ແນ່ນອນຂອງການເຮັດວຽກຂອງລາວທີ່ມີຕົວເລກ/ຂໍ້ມູນທີ່ເຫມາະສົມສາມາດຖືກເຜີຍແຜ່ໄດ້.

    i.e. ໃນບົດລາຍງານການທົດສອບ, ພວກເຮົາສາມາດເຜີຍແຜ່:

    1. ມີກໍລະນີທົດສອບຈຳນວນເທົ່າໃດທີ່ໄດ້ຮັບການອອກແບບຕາມຄວາມຕ້ອງການ?
    2. ມີກໍລະນີທົດສອບຈຳນວນເທົ່າໃດທີ່ຍັງບໍ່ທັນອອກແບບ?
    3. ມີກໍລະນີທົດສອບຈຳນວນເທົ່າໃດ?
    4. ມີກໍລະນີທົດສອບຈຳນວນເທົ່າໃດທີ່ຜ່ານ/ບໍ່ສຳເລັດ/ຖືກບລັອກ?
    5. ມີກໍລະນີທົດສອບຈຳນວນເທົ່າໃດ?
    6. ມີຂໍ້ບົກພ່ອງຈຳນວນເທົ່າໃດ? ຖືກກໍານົດ & amp; ຄວາມຮຸນແຮງຂອງຂໍ້ບົກພ່ອງເຫຼົ່ານັ້ນແມ່ນຫຍັງ? ແລະອື່ນໆ.

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

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

    • %ge ຂອງວຽກທີ່ສໍາເລັດ
    • %ge ຂອງວຽກທີ່ຍັງບໍ່ທັນສໍາເລັດ
    • ເວລາທີ່ຈະເຮັດສໍາເລັດວຽກທີ່ຍັງເຫຼືອ
    • ວ່າໂຄງການຈະດໍາເນີນໄປຕາມກໍານົດເວລາຫຼືຊ້າ? ຯລຯ.

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

    ວົງຈອນຊີວິດຂອງເມຕຣິກ

    ປະເພດຂອງການວັດແທກຄູ່ມື

    Metrics ການທົດສອບແມ່ນແບ່ງອອກເປັນ 2 ປະເພດສ່ວນໃຫຍ່.

    1. Base Metrics
    2. Metrics ການຄິດໄລ່

    Base Metrics: Base Metrics ແມ່ນ Metrics ທີ່ມາຈາກຂໍ້ມູນທີ່ເກັບກໍາໂດຍ Test Analyst ໃນລະຫວ່າງການພັດທະນາກໍລະນີທົດສອບ ແລະການປະຕິບັດ.

    ຂໍ້ມູນນີ້ຈະຖືກຕິດຕາມຕະຫຼອດ Test Lifecycle. I.e. ເກັບກໍາຂໍ້ມູນເຊັ່ນ: Total no. ຂອງກໍລະນີທົດສອບທີ່ພັດທະນາສໍາລັບໂຄງການ (ຫຼື) ບໍ່ມີ. ຂອງກໍລະນີທົດສອບຕ້ອງໄດ້ຮັບການປະຕິບັດ (ຫຼື) ບໍ່ມີ. ຂອງກໍລະນີທົດສອບຜ່ານ/ບໍ່ສຳເລັດ/ຖືກບລັອກ ແລະ ອື່ນໆ.

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

    ຕົວຢ່າງຂອງຊອບແວTesting Metrics

    ໃຫ້ເຮົາເອົາຕົວຢ່າງເພື່ອຄິດໄລ່ການວັດແທກການທົດສອບຕ່າງໆທີ່ໃຊ້ໃນບົດລາຍງານການທົດສອບຊອບແວ:

    ຂ້າງລຸ່ມນີ້ແມ່ນຮູບແບບຕາຕະລາງສໍາລັບຂໍ້ມູນທີ່ດຶງມາຈາກ Test Analyst ຜູ້ທີ່ມີສ່ວນຮ່ວມໃນຕົວຈິງ. ການທົດສອບ:

    ຄໍານິຍາມ ແລະສູດການຄິດໄລ່ Metrics:

    #1) %ge ກໍລະນີທົດສອບຖືກປະຕິບັດແລ້ວ : metric ນີ້ຖືກໃຊ້ເພື່ອໃຫ້ໄດ້ສະຖານະການປະຕິບັດຂອງກໍລະນີທົດສອບໃນເງື່ອນໄຂຂອງ %ge.

    %ge Test case Executed = ( No. of Test case executed / Total no. ຂອງກໍລະນີທົດສອບລາຍລັກອັກສອນ) * 100.

    ດັ່ງນັ້ນ, ຈາກຂໍ້ມູນຂ້າງເທິງ,

    %ge ກໍລະນີທົດສອບປະຕິບັດ = (65 / 100) * 100 = 65%

    #2) %ge ກໍລະນີທົດສອບບໍ່ຖືກປະຕິບັດ : metric ນີ້ຖືກໃຊ້ເພື່ອໃຫ້ໄດ້ສະຖານະການປະຕິບັດທີ່ຍັງຄ້າງຂອງກໍລະນີທົດສອບໃນເງື່ອນໄຂຂອງ %ge.

    %ge ກໍລະນີທົດສອບບໍ່ໄດ້ປະຕິບັດ = ( No. of Test case not executed / Total no. of Test case written) * 100.

    ດັ່ງນັ້ນ, ຈາກຂໍ້ມູນຂ້າງເທິງ,

    %ge ກໍລະນີທົດສອບຖືກບລັອກ = (35 / 100) * 100 = 35%

    #3) %ge ກໍລະນີທົດສອບຜ່ານ : ຕົວຊີ້ວັດນີ້ແມ່ນໃຊ້ເພື່ອໃຫ້ໄດ້ Pass %ge ຂອງກໍລະນີທົດສອບທີ່ປະຕິບັດແລ້ວ.

    %ge ກໍລະນີທົດສອບຜ່ານ = ( ບໍ່. ຂອງກໍລະນີທົດສອບຜ່ານ / Total no. of Test case Executed) * 100.

    ດັ່ງນັ້ນ, ຈາກຂໍ້ມູນຂ້າງເທິງ,

    %ge Test case Passed = (30 / 65) * 100 = 46%

    #4) %ge ກໍລະນີທົດສອບລົ້ມເຫລວ : ເມຕຣິກນີ້ຖືກໃຊ້ເພື່ອໃຫ້ໄດ້ Fail %ge ຂອງກໍລະນີທົດສອບທີ່ປະຕິບັດແລ້ວ.

    %ge ກໍລະນີທົດສອບລົ້ມເຫລວ = ( No. of Test Case Failed / Total no. of Test case Executed) * 100.

    ດັ່ງນັ້ນ, ຈາກຂໍ້ມູນຂ້າງເທິງ,

    %ge ກໍລະນີທົດສອບ ຜ່ານ = (26 / 65) * 100 = 40%

    #5) %ge ກໍລະນີທົດສອບຖືກບລັອກ : ເມຕຣິກນີ້ຖືກໃຊ້ເພື່ອໃຫ້ໄດ້ %ge ທີ່ຖືກບລັອກຂອງກໍລະນີທົດສອບທີ່ປະຕິບັດແລ້ວ. ບົດລາຍງານລາຍລະອຽດສາມາດຖືກສົ່ງໂດຍການລະບຸເຫດຜົນທີ່ແທ້ຈິງສໍາລັບການຂັດຂວາງກໍລະນີທົດສອບ.

    %ge ກໍລະນີທົດສອບທີ່ຖືກບລັອກ = ( ຈໍານວນກໍລະນີທົດສອບທີ່ຖືກບລັອກ / ຈໍານວນກໍລະນີທົດສອບທັງຫມົດທີ່ຖືກປະຕິບັດ. ) * 100.

    ດັ່ງນັ້ນ, ຈາກຂໍ້ມູນຂ້າງເທິງ,

    %ge Test case Blocked = (9 / 65) * 100 = 14%

    #6) ຄວາມໜາແໜ້ນຂອງຂໍ້ບົກພ່ອງ = ບໍ່. of Defects identified / size

    ( ທີ່ນີ້ “Size” ຖືວ່າເປັນຄວາມຕ້ອງການ. ເພາະສະນັ້ນ, Defect Density ຢູ່ທີ່ນີ້ແມ່ນຄຳນວນເປັນຈຳນວນຂໍ້ບົກພ່ອງທີ່ລະບຸຕາມຄວາມຕ້ອງການ. ເຊັ່ນດຽວກັນ, Defect Density ສາມາດຄຳນວນໄດ້. ເປັນຈໍານວນຂໍ້ບົກພ່ອງທີ່ຖືກກໍານົດຕໍ່ 100 ແຖວຂອງລະຫັດ [OR] No. of defects identified per module, etc. )

    ດັ່ງນັ້ນ, ຈາກຂໍ້ມູນຂ້າງເທິງ,

    Defect Density = (30 / 5) = 6

    #7) Defect Removal Efficiency (DRE) = ( No. of defects found during QA testing / (No. of Defects found during QA) ການທົດສອບ +No. ຂອງຂໍ້ບົກພ່ອງທີ່ພົບເຫັນໂດຍຜູ້ໃຊ້ສຸດທ້າຍ)) * 100

    DRE ຖືກນໍາໃຊ້ເພື່ອກໍານົດປະສິດທິພາບການທົດສອບຂອງລະບົບ.

    ສົມມຸດວ່າ, ໃນລະຫວ່າງການພັດທະນາ & ການທົດສອບ QA, ພວກເຮົາໄດ້ກໍານົດ 100 ຂໍ້ບົກພ່ອງ.

    ຫຼັງຈາກການທົດສອບ QA, ໃນລະຫວ່າງ Alpha & ການທົດສອບເບຕ້າ,ຜູ້ໃຊ້ສຸດທ້າຍ / ລູກຄ້າໄດ້ກໍານົດ 40 ຂໍ້ບົກພ່ອງ, ເຊິ່ງສາມາດຖືກກໍານົດໃນໄລຍະການທົດສອບ QA.

    ຕອນນີ້, DRE ຈະຖືກຄິດໄລ່ເປັນ,

    DRE = [100 / (100 + 40)] * 100 = [100 / 140] * 100 = 71%

    #8) Defect Leakage : Defect Leakage ແມ່ນ Metric ທີ່ຖືກນໍາໃຊ້ເພື່ອກໍານົດປະສິດທິພາບຂອງການທົດສອບ QA. i.e., ຈຳນວນຂໍ້ບົກພ່ອງທີ່ພາດ/ຫຼຸດໃນລະຫວ່າງການທົດສອບ QA.

    ການຮົ່ວໄຫຼຂອງຂໍ້ບົກພ່ອງ = ( ຈຳນວນຂໍ້ບົກພ່ອງທີ່ພົບໃນ UAT / ຈຳນວນຂໍ້ບົກພ່ອງທີ່ພົບໃນການທົດສອບ QA.) * 100

    ສົມມຸດວ່າ, ໃນລະຫວ່າງການພັດທະນາ & ການທົດສອບ QA, ພວກເຮົາໄດ້ກໍານົດ 100 ຂໍ້ບົກພ່ອງ.

    ຫຼັງຈາກການທົດສອບ QA, ໃນລະຫວ່າງ Alpha & ການທົດສອບເບຕ້າ, ຜູ້ໃຊ້ສຸດທ້າຍ / ລູກຄ້າໄດ້ກໍານົດ 40 ຂໍ້ບົກພ່ອງ, ເຊິ່ງສາມາດຖືກກໍານົດໃນລະຫວ່າງການທົດສອບ QA.

    ການຮົ່ວໄຫຼຂອງຂໍ້ບົກພ່ອງ = (40 /100) * 100 = 40%

    #9) ຂໍ້ບົກພ່ອງໂດຍບຸລິມະສິດ : ຕົວຊີ້ວັດນີ້ແມ່ນໃຊ້ເພື່ອລະບຸຕົວເລກ. of defects identified based on the Severity / Priority of the defects which is used to decision the quality of the software.

    %ge Critical Defects = No. of Critical Defects identified / Total no. ຂອງຂໍ້ບົກພ່ອງທີ່ລະບຸ * 100

    ຈາກຂໍ້ມູນທີ່ມີຢູ່ໃນຕາຕະລາງຂ້າງເທິງ,

    %ge ຂໍ້ບົກພ່ອງທີ່ສໍາຄັນ = 6/ 30 * 100 = 20%

    %ge ຂໍ້ບົກພ່ອງສູງ = No. of High Defects identified / Total no. ຂອງຂໍ້ບົກພ່ອງໄດ້ລະບຸ * 100

    ຈາກຂໍ້ມູນທີ່ມີຢູ່ໃນຕາຕະລາງຂ້າງເທິງ,

    %ge ຂໍ້ບົກພ່ອງສູງ = 10/ 30 * 100 = 33.33%

    %ge Medium Defects = ບໍ່.ຂອງຂໍ້ບົກພ່ອງຂະຫນາດກາງທີ່ໄດ້ກໍານົດ / ຈໍານວນທັງຫມົດ. ຂອງຂໍ້ບົກພ່ອງໄດ້ລະບຸ * 100

    ຈາກຂໍ້ມູນທີ່ມີຢູ່ໃນຕາຕະລາງຂ້າງເທິງ,

    %ge ຂໍ້ບົກພ່ອງປານກາງ = 6/ 30 * 100 = 20%

    %ge ຂໍ້ບົກພ່ອງຕໍ່າ = No. of Low Defects ກໍານົດ / Total no. ຂອງຂໍ້ບົກພ່ອງໄດ້ລະບຸ * 100

    ຈາກຂໍ້ມູນທີ່ມີຢູ່ໃນຕາຕະລາງຂ້າງເທິງ,

    %ge ຂໍ້ບົກພ່ອງຕ່ໍາ = 8/ 30 * 100 = 27%

    0

    ສະຫຼຸບ

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

    ກ່ຽວກັບຜູ້ຂຽນ : ນີ້ແມ່ນການຕອບຮັບໂດຍ Anuradha K. ນາງມີປະສົບການ 7+ ປີຂອງການທົດສອບຊອບແວແລະປະຈຸບັນເຮັດວຽກເປັນທີ່ປຶກສາສໍາລັບ MNC. ລາວຍັງມີຄວາມຮູ້ທີ່ດີກ່ຽວກັບການທົດສອບອັດຕະໂນມັດມືຖື.

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

    ການອ່ານທີ່ແນະນໍາ

      ໄປ​ທີ່​ຂອງ​ໜ້າ