คำถามติดแท็ก qa

ฉันรู้ว่ามันฟังดูเหมือนคำถามอื่น ๆ ที่ถูกถามไปแล้ว แต่จริงๆแล้วมันแตกต่างออกไปเล็กน้อย ดูเหมือนว่าโดยทั่วไปแล้วผู้เขียนโปรแกรมจะไม่เก่งในการทดสอบบทบาทของแอปพลิเคชัน ตัวอย่างเช่น: โจเอลซอฟแวร์ - Top Five (ผิด) เหตุผลที่คุณไม่ได้มีการทดสอบ (เหมืองเน้น) อย่าคิดแม้แต่จะพยายามบอกผู้สำเร็จการศึกษาจากวิทยาลัย CS ว่าพวกเขาสามารถมาทำงานให้คุณได้ แต่ "ทุกคนจะต้องควบคุมคุณภาพในช่วงเวลาหนึ่งก่อนที่จะเปลี่ยนเป็นรหัส" ฉันเห็นสิ่งนี้มากมาย โปรแกรมเมอร์ไม่ทำการทดสอบที่ดีและคุณจะสูญเสียโปรแกรมเมอร์ที่ดีซึ่งยากที่จะแทนที่ และในคำถามนี้หนึ่งในคำตอบที่ได้รับความนิยมมากที่สุดบอกว่า (อีกครั้งฉันขอเน้น): นักพัฒนาสามารถเป็นผู้ทดสอบได้ แต่พวกเขาไม่ควรเป็นผู้ทดสอบ นักพัฒนามีแนวโน้มที่จะหลีกเลี่ยงการใช้แอปพลิเคชั่นโดยไม่ตั้งใจ / ไม่ตั้งใจ นั่นเป็นเพราะพวกเขาเขียนและทดสอบเป็นส่วนใหญ่ในแบบที่ควรจะใช้ ดังนั้นคำถามคือโปรแกรมเมอร์ไม่ดีในการทดสอบหรือไม่ มีหลักฐานหรือข้อโต้แย้งอะไรบ้างที่สนับสนุนข้อสรุปนี้? โปรแกรมเมอร์ไม่ดีเพียงทดสอบรหัสของตนเองหรือไม่ มีหลักฐานที่แสดงว่าโปรแกรมเมอร์ดีจริง ๆที่ทดสอบหรือไม่ ฉันหมายถึงอะไรโดย "การทดสอบ" ฉันไม่ได้หมายถึงการทดสอบหน่วยหรือสิ่งใดก็ตามที่ถือว่าเป็นส่วนหนึ่งของวิธีการที่ทีมซอฟต์แวร์ใช้เพื่อเขียนซอฟต์แวร์ ฉันหมายถึงวิธีการประกันคุณภาพบางอย่างที่ใช้หลังจากสร้างรหัสและปรับใช้กับสิ่งที่ทีมซอฟต์แวร์จะเรียกว่า "สภาพแวดล้อมการทดสอบ"

36 testing  qa 

ในงานของฉันนักพัฒนาทั้งหมดที่แก้ไขข้อผิดพลาดจะต้องเพิ่มการทดสอบหน่วยใหม่ที่เตือนเกี่ยวกับข้อบกพร่องประเภทนี้ (ในกรณีที่มันเกิดขึ้นอีกครั้ง) หากไม่สามารถทดสอบหน่วย (ตัวอย่างเช่นปัญหาการออกแบบเว็บเพจ) แผนก QA จะต้องสร้างกรณีทดสอบเพื่อตรวจสอบด้วยตนเอง แนวคิดเบื้องหลังคือถ้าหากไม่พบข้อบกพร่องก่อนที่จะเปิดตัวผลิตภัณฑ์เนื่องจากไม่มีการทดสอบหน่วยที่เหมาะสมในการตรวจจับ ดังนั้นผู้พัฒนาจะต้องเพิ่มมัน คำถามคือสิ่งนี้เป็นเรื่องธรรมดาในวิธีการพัฒนาซอฟต์แวร์หรือไม่ เทคนิคนี้มีชื่อหรือไม่? ฉันต้องการเรียนรู้เพิ่มเติมเกี่ยวกับมัน แต่ฉันต้องการข้อมูลบางอย่างเพื่อเริ่มต้นด้วย

35 unit-testing  issue-tracking  qa 

ฉันเป็นนักเรียนที่ทำงานเกี่ยวกับ BE (CS) และคำถามของฉันคือ: จำเป็นต้องทำการทดสอบในสาขาซอฟต์แวร์หรือไม่? ถ้าเราสร้างซอฟต์แวร์ด้วยความระมัดระวังเราจะทดสอบทำไม หลังจากการทดสอบเรามั่นใจได้หรือไม่ว่าเราบรรลุเป้าหมายนี้ (ผลิตภัณฑ์ / ซอฟต์แวร์ทำงานตามที่ตั้งใจ) เพราะเราทำการทดสอบเสร็จแล้ว? มันเป็นไปได้? คำถามของฉัน: จำเป็นต้องมีการทดสอบซอฟต์แวร์หรือไม่

33 testing  quality  validation  qa  verification 

มีคนใน บริษัท ของฉันเสนอการเปลี่ยนแปลงผลิตภัณฑ์หลักของเราที่ผู้จัดการของเรารู้สึกว่าควรเรียกสิ่งที่ฉันคิดว่า บริษัท ของฉันพิจารณาวงจรการควบคุมคุณภาพเต็มรูปแบบ (เช่นการทดสอบชุดผลิตภัณฑ์ทั้งหมดตั้งแต่ต้น) เห็นได้ชัดว่า QA ของเราใช้เวลา 12 สัปดาห์ในการทำ QA แบบเต็มสำหรับผลิตภัณฑ์ของเรา ปัญหาของฉันคือสิ่งนี้คือเรากำลังพยายามพัฒนา Agile (แม้ว่าส่วนใหญ่ครึ่งความคิดเห็นของฉัน) การพัฒนา เราจะทำชุดวิ่งทั้งหมดแล้วปล่อยซึ่ง QA จะใช้เวลาตลอดไปในการผ่านฉันเดา คำถามนี้จริง ๆ ถ้า QA ของเราจะใช้เวลา 12 สัปดาห์ในการทำงานของพวกเขาเราไม่ควรที่จะลอง Agile หรือไม่? อะไรคือจุดพยายามที่จะทำ Agile ในสถานการณ์เช่นนี้?

24 agile  qa 

เราเป็นทีมใหญ่ (นักพัฒนา 10-12 คนและ 4 คน) ทำงานหลายโครงการด้วยที่เก็บ git เดียวกัน มันเป็นบริการเว็บแบ็กเอนด์ในฤดูใบไม้ผลิตาม เรากำลังมองหาการแยกทางและใช้กลยุทธ์ที่ดี นอกจากนี้เรายังมีทีมงาน qa ที่ทำให้มั่นใจว่าคุณสมบัติของเราทำงานได้ตามที่คาดไว้ (ปราศจากข้อบกพร่องในระดับหนึ่ง) หลังจากอ่านบทความไม่กี่ฉันรู้สึกว่าแบบจำลองGitflowทำงานได้ดีสำหรับเรา ที่นี่คำถามของฉันมา ทีม QA ของเราควรทดสอบคุณสมบัติของเราที่ไหน? พวกเขาควรทดสอบสาขาคุณลักษณะที่พวกเขาจะเพิ่มข้อผิดพลาดและนักพัฒนาจะแก้ไขและเมื่อผ่านการทดสอบ QA เรารวมการพัฒนา และ QA จะทำการทดสอบจำนวนเต็มอีกครั้งในสาขาที่กำลังพัฒนา เราควรรวมคุณสมบัติทั้งหมด (หลังการทดสอบหน่วยและการทดสอบพื้นฐานจากผู้พัฒนา) เพื่อพัฒนาสาขาและให้ทดสอบ qa จากที่นั่น การแก้ไขและการทดสอบทั้งหมดจะเกิดขึ้นในการพัฒนาเช่นกัน ฉันอยากรู้ว่าวิธีการใดที่ทำงานได้ดีสำหรับผู้อื่น

23 testing  git  branching  qa  gitflow 

มีการทดสอบการจัดการภายในการวิ่งเช่นเดียวกับการเข้ารหัสอย่างไรหากการเข้ารหัสทั้งหมดหรือส่วนใหญ่ไม่ได้ทำจนกว่าจะสิ้นสุดการวิ่ง (ฉันหมายถึงการพัฒนา "ซุปถึงถั่ว" และการทดสอบ PBI เดียวภายในการวิ่ง) คำตอบส่วนใหญ่ที่ฉันเคยเห็นทางออนไลน์เกี่ยวข้องกับการควบคุมอัตโนมัติ QA แต่ก็เป็นไปไม่ได้จริง ๆ เพราะคุณต้องใช้ UI การทำงานเพื่อบันทึกหรือสร้างการทดสอบอัตโนมัติจาก ฉันมีสตอรี่บอร์ดที่พัฒนาต่อไปในขณะที่ฉันพัฒนาฟีเจอร์และค้นหาข้อกำหนดใหม่ ๆ ในกรณีของฉันฉันกำลังพัฒนาแอปพลิเคชันเดสก์ท็อปใหม่ แอปเดสก์ท็อปมักไม่ให้ยืมตัวเองกับการทดสอบอัตโนมัติเป็นอย่างดี ฉันมีการทดสอบหน่วยอัตโนมัติบางอย่าง แต่ไม่ใช่การทดสอบการใช้งาน / การรวมด้วยตนเองที่ผู้เชี่ยวชาญด้านคุณภาพจะทำ ดังนั้นที่ฉันอยู่ตอนนี้คือการวิ่งของฉันจะสิ้นสุดในวันพรุ่งนี้ฉันยังคงเขียนโค้ดให้เสร็จและคน QA ของฉันยังไม่มีการทดสอบ ฉันแน่ใจว่าฉันไม่ใช่คนแรกที่มีปัญหานี้ ในอดีตที่ผ่านมาฉันได้ทำไปป์ไลน์: ในการวิ่งปัจจุบันทีมทดสอบจะทดสอบคุณสมบัติที่มีการใช้งานในระหว่างการวิ่งครั้งก่อนหน้า ที่งานปัจจุบันของฉัน PM อ้างถึงวิธีการนี้ว่า "น้ำตก" และเป็นที่ยอมรับไม่ได้

22 agile  testing  unit-testing  scrum  qa 

ที่ตำแหน่งปัจจุบันของฉัน QA ได้กลายเป็นคอขวด เรามีการเกิดขึ้นของคุณสมบัติที่โชคร้ายจากการสร้างปัจจุบันเพื่อให้ QA สามารถทำการทดสอบให้เสร็จสิ้นได้ ซึ่งหมายความว่าฟีเจอร์ที่ได้รับการพัฒนาแล้วอาจไม่ได้รับการทดสอบเป็นเวลา 2-3 สัปดาห์หลังจากที่นักพัฒนาซอฟต์แวร์ได้ทำการพัฒนาต่อไป เมื่อ dev เคลื่อนที่ได้เร็วขึ้นและมีคุณภาพ QA ช่องว่างในเวลานี้จะยิ่งใหญ่ขึ้นเท่านั้น ฉันเปิดอ่านสำเนาของ Code Complete อย่างต่อเนื่องโดยมองหาข้อมูล "Hard Data" ที่แสดงค่าใช้จ่ายในการแก้ไขข้อบกพร่องที่เพิ่มขึ้นแบบทวีคูณยิ่งมีอยู่นานขึ้น ใครสามารถชี้ให้ฉันดูการศึกษาบางอย่างที่สนับสนุนแนวคิดนี้ได้บ้าง ฉันพยายามโน้มน้าวใจพลังที่เป็นไปได้ว่าคอขวด QA แพงกว่าที่คิดไว้มาก

18 development-process  qa 

เมื่อสร้างการประมาณเวลาสำหรับตั๋วควรรวมเวลาที่ใช้สำหรับผู้ทดสอบ (QAs) ไว้ในการประมาณตั๋วหรือไม่ ก่อนหน้านี้เราได้ประเมินไว้เสมอโดยไม่มีเวลาทดสอบ แต่เรากำลังพูดถึงรวมถึงมันเสมอ มันสมเหตุสมผลแล้วสำหรับการวิ่งในปัจจุบันของเราล่าสุดก่อนการเปิดตัวเนื่องจากเราจำเป็นต้องรู้ว่าเวลาทั้งหมดจะใช้เวลาหนึ่งสัปดาห์ ฉันเข้าใจเสมอว่าการประเมินนั้นใช้สำหรับนักพัฒนาเท่านั้นเพราะมันมีแนวโน้มว่าจะเป็นทรัพยากรที่ จำกัด ในทีม เพื่อนร่วมงานคนหนึ่งบอกว่าไม่ว่าพวกเขาจะทำงานที่ไหนมาก่อนเวลาทดสอบ เพื่อความชัดเจนนี่เป็นกระบวนการที่นักพัฒนากำลังเขียนหน่วยการรวมและการทดสอบ UI ที่มีความครอบคลุมที่ดี

17 agile  scrum  estimation  qa 

ใน บริษัท ของฉันเราประสบความสำเร็จในการปฏิบัติงานด้วยความคล่องตัว - แต่ไม่ต้องใช้การทำซ้ำ เหตุผลหลักคือเราไม่สามารถหาวิธีที่สะอาดเพื่อให้เหมาะสมใน QA ในรอบการวนซ้ำ เราเข้าใจว่า QA เป็นบิตของการตรวจสอบเพิ่มเติมสำหรับบิวด์บางตัว (รีลีสผู้สมัคร) ก่อนที่บิลด์นี้จะนำไปใช้กับลูกค้า จุดประสงค์คือเพื่อหลีกเลี่ยงการกระทำที่มุ่งร้ายเพียงอย่างเดียวที่สร้างความเสียหายต่อการเปิดตัวทั้งหมด เนื่องจากคุณไม่เคยรู้ว่าที่หนึ่งมันเป็น QA ต้องรอจนกว่าทุกคุณลักษณะ / กระทำสำหรับการเปิดตัวอยู่ในการสร้าง (ไม่มีคำพูดสุดท้ายที่มีชื่อเสียง "อนุญาตให้เปลี่ยนแปลงเพียงเล็กน้อย") หาก QA พบข้อบกพร่องในตัวเลือกการเปิดตัวนักพัฒนาแก้ไขข้อบกพร่องเหล่านี้ในสาขาการเปิดตัวที่เกี่ยวข้อง (และผสานเข้ากับลำตัว) เมื่อแก้ไขบั๊กทั้งหมดแล้วบิลด์ใหม่จะถูกปรับใช้เพื่อให้ QA ทำการทดสอบอีกครั้ง เฉพาะเมื่อไม่พบข้อบกพร่องในตัวเลือกการเปิดตัวบางอย่างมันจะถูกเสนอให้กับลูกค้าเพื่อการตรวจสอบ โดยปกติจะใช้เวลาประมาณสองถึงสามผู้สมัครประมาณหนึ่งสัปดาห์ต่อการเปิดตัว เวลาในการเขียนการแก้ไขนั้นปกติแล้วจะต่ำกว่าความพยายามในการทดสอบ ดังนั้นเพื่อให้นักพัฒนาไม่ว่างพวกเขาทำงานในการเปิดตัว N + 1 ในขณะที่ QA ทำงานบน N หากไม่มีการใช้การวนซ้ำนี่จะไม่มีปัญหาเพราะเราสามารถซ้อนทับงานสำหรับการปล่อย N และ N + 1 อย่างไรก็ตามจากสิ่งที่ฉันเข้าใจว่าสิ่งนี้ไม่เข้ากันกับวิธีการทำซ้ำเช่น Scrum หรือ XP พวกเขาต้องการให้ทำซ้ำได้ในตอนท้ายด้วยความพยายามในการทดสอบทั้งหมดเพื่อรวมไว้ในการทำซ้ำ …

17 agile  teamwork  qa  sdlc 

เราทุกคนได้เห็นตัวอย่างมากมายของซอฟต์แวร์ที่มาพร้อมกับ "ความต้องการขั้นต่ำของระบบ" ดังต่อไปนี้: Windows XP / Vista / 7 RAM 1GB พื้นที่เก็บข้อมูล 200 MB โดยทั่วไปแล้วจะมีวิธีพิจารณาอย่างไร เห็นได้ชัดว่าบางครั้งมีข้อ จำกัด เฉพาะ (ถ้าโปรแกรมใช้พื้นที่ 200 MB บนดิสก์นั่นเป็นข้อกำหนดที่ยากมาก) นอกเหนือจากสถานการณ์เหล่านั้นหลาย ๆ ครั้งสำหรับสิ่งต่าง ๆ เช่น RAM หรือตัวประมวลผลปรากฎว่ามากขึ้น / เร็วขึ้นดีขึ้นโดยไม่มีข้อ จำกัด อย่างหนัก สิ่งเหล่านี้ถูกกำหนดอย่างไร? นักพัฒนาทำตัวเลขที่ดูเหมือนสมเหตุสมผลหรือไม่ QA ผ่านกระบวนการที่เข้มงวดเพื่อทดสอบข้อกำหนดต่างๆจนกว่าพวกเขาจะพบการตั้งค่าต่ำสุดพร้อมประสิทธิภาพที่ยอมรับได้หรือไม่? สัญชาตญาณของฉันบอกว่ามันควรจะเป็นหลัง แต่มักจะเป็นอดีตในทางปฏิบัติ

17 documentation  requirements  qa 

ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังคำตอบที่จะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้อาจเรียกร้องให้มีการถกเถียงอภิปรายโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน8 ปีที่ผ่านมา Sony เพิ่งถูกแฮ็กด้วยการฉีด SQL และรหัสผ่านของผู้ใช้ของพวกเขาถูกเก็บไว้ในรูปแบบข้อความล้วน นี่เป็นความผิดพลาดหน้าใหม่ ใน บริษัท ขนาดใหญ่เช่นนี้จะผ่าน QA ได้อย่างไร พวกเขาไม่มีทีมที่ดีกว่ารู้ดีกว่านี้ได้อย่างไร ขนาดที่แท้จริงของ บริษัท ที่ถูกแฮ็กทำให้สิ่งนี้แตกต่าง มันมีผลกระทบต่อพวกเราทุกคนเพราะวันหนึ่งเราอาจพบว่าตัวเองอยู่ในทีมที่มีหน้าที่รับผิดชอบอะไรเช่นนี้และจากนั้นเราก็ได้ขวาน แล้วอะไรคือปัจจัยที่นำไปสู่สิ่งนี้และเราจะป้องกันได้อย่างไร

15 security  qa  mistakes 

อัปเดต / ชี้แจงลูกค้าของฉันเข้าใจถึงความจำเป็นในการทดสอบภายในและพวกเขา / พวกเขาสาบานเสมอว่าพวกเขาจะ "ทำได้ดีกว่า" (เช่นทำอะไร) แต่มันก็ไม่ได้เกิดขึ้น พวกเขาไม่มีงบประมาณสำหรับการทดสอบภายนอก ฉันเดาว่าฉันกำลังถาม (ราง ๆ ฉันยอมรับ) เกี่ยวกับสิ่งที่สามารถปลูกฝัง "การทดสอบก่อนการทดสอบบ่อยทดสอบบนร๊อคของเครื่องเป้าหมาย? คำถาม:วิธีการกระตุ้นให้ผู้ใช้ใช้เวลาในการทดสอบและรายงานปัญหาเกี่ยวกับการออกรุ่นใหม่อย่างชัดเจนไม่ใช่ "test-as-They-go" ในโครงการผลิต พื้นหลัง:ฉันมีลูกค้ารายย่อยซึ่งฉันได้เขียนชุดเครื่องมือนำเสนอมัลติมีเดีย พวกเขาเป็นลูกค้าที่ดีและเรามีความสัมพันธ์ที่ดี โครงการกำลังดำเนินการอยู่เพิ่มคุณสมบัติตามที่เราไปด้วย ฉันมีสองประเด็น: คำจำกัดความของคุณสมบัติกระทำได้ตามปกติบ่อยครั้งที่โทรศัพท์การเปลี่ยนแปลงการแก้ไขการพลิกกลับ (นิดหน่อยเหมือนของ Kennedy "เราจะไปยังดวงจันทร์และทำสิ่งอื่น ๆ " - ฉันมักจะถูกขบขันโดย "สิ่งอื่น ๆ " ส่วนหนึ่งของที่) การทดสอบ QA แทบจะไม่เสร็จสิ้น ฉันสามารถจัดการกับ # 1 มากหรือน้อย นี่ไม่ใช่ไคลเอนต์ที่จะอ่านข้อกำหนดก่อนการประชุม ฉันคุ้นเคยกับมัน มันเป็นรายการ # 2 ที่ฉันมีปัญหากับ: พวกเขาไม่ได้หรือจะไม่ทดสอบรุ่นใหม่ สิ่งที่พวกเขาทำคือการใช้พวกมันในการผลิตดังนั้นเมื่อเกิดข้อบกพร่องขึ้นพวกเขาจะหาวิธีแก้ปัญหาและไม่รายงานหรือไม่ก็รีบเข้าโครงการด้วยรายงานข้อผิดพลาดที่คลุมเครือ เรามีการพูดคุยมากมายเกี่ยวกับสิ่งนี้ …

14 client-relations  qa 

หากดำเนินโครงการโดยใช้ BDD ที่มีเนื้อหาครอบคลุม 100% ของเรื่องราวของผู้ใช้ด้วยการทดสอบการยอมรับอัตโนมัติสิ่งที่จะเป็นบทบาทของผู้ทดสอบ / ประกันคุณภาพ ฉันเดาว่าฉันจะจินตนาการว่านักพัฒนาจะเขียนการทดสอบการยอมรับร่วมกับเจ้าของผลิตภัณฑ์แจ้งให้เราทราบหากนั่นดูเหมือนว่าเป็นข้อสมมุติที่โง่เขลา

13 testing  team  qa  bdd  acceptance-testing 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว ฉันเชื่อว่ามันเป็น ทำไม? ฉันพบวิศวกรซอฟต์แวร์หลายคนที่เชื่อว่าพวกเขาเหนือกว่าวิศวกร QA ฉันคิดว่ามันอาจช่วยระงับความเชื่อนี้ได้หากพวกเขาทำงานของวิศวกรควบคุมคุณภาพในบางครั้งและตระหนักว่ามันเป็นชุดทักษะที่เป็นเอกลักษณ์และมีค่าของตัวเอง วิศวกรซอฟต์แวร์ที่ดีกว่ากำลังทำการทดสอบโปรแกรมของพวกเขาเองซึ่งจะมีค่าใช้จ่ายน้อยกว่าในเวลาที่รหัสของพวกเขาจะเกิดขึ้นเมื่อทำผ่านส่วนที่เหลือของวงจรการพัฒนาซอฟต์แวร์ ยิ่งวิศวกรซอฟต์แวร์ใช้เวลาคิดเกี่ยวกับวิธีที่โปรแกรมสามารถหยุดพักได้บ่อยครั้งที่พวกเขาจะต้องพิจารณากรณีเหล่านี้เมื่อพวกเขาพัฒนาพวกเขาซึ่งจะช่วยลดข้อบกพร่องในผลิตภัณฑ์สุดท้าย คำนิยาม "สมบูรณ์" ของ Software Engineer นั้นน่าสนใจอยู่เสมอ ... หากพวกเขาใช้เวลาเป็นวิศวกร QA บางทีนิยามนี้จะตรงกับผู้ออกแบบซอฟต์แวร์มากขึ้น หมายเหตุฉันทำตามคำแนะนำข้างต้นโดยมีกรอบเวลาเล็ก ๆ ในใจเนื่องจากฉันรู้ว่ามีคนทำงานในตำแหน่งที่ไม่ใช่ตำแหน่งที่พวกเขาได้รับการว่าจ้างเป็นสูตรสำหรับการสูญเสียผู้พัฒนารายนั้น คุณคิดอย่างไร?

12 code-quality  skills  qa 

ฉันกำลังจะเข้าร่วมการสนทนากับฝ่ายบริหารเกี่ยวกับการวัดประสิทธิภาพการทดสอบของเราในฐานะองค์กร QA เหตุผลหลักที่อยู่เบื้องหลังคือว่าทีมงานของเราครึ่งหนึ่งถูกทำสัญญาและธุรกิจของเราต้องการที่จะให้ข้อมูลบางอย่างเกี่ยวกับประสิทธิภาพและประสิทธิภาพของเราดังนั้นเราจึงมีข้อมูลพื้นฐานที่จะเจรจาต่อรองพารามิเตอร์สัญญากับข้อตกลงการบริการของผู้รับเหมาของเรา . ฉันแหย่ไปรอบ ๆ เล็กน้อยและส่วนใหญ่ของความเห็นที่ฉันได้พบในเรื่องนี้เกี่ยวกับประสิทธิภาพของนักพัฒนา: บรรทัดของรหัสจุดเรื่องราวส่งมอบข้อบกพร่องแนะนำ ฯลฯ แต่แล้วผู้ทดสอบล่ะ การทดสอบของเรานั้นเป็นไปตามความต้องการเป็นส่วนใหญ่และการทดสอบด้วยตนเองกึ่งอัตโนมัติและการทดสอบอัตโนมัติ (ไม่ใช่เพราะเราไม่ได้มีระบบอัตโนมัติทุกอย่าง แต่เนื่องจากบางสิ่งไม่สามารถทำงานได้อัตโนมัติในระบบทดสอบของเรา)

11 testing  efficiency  qa  metrics