บางครั้งทีมงาน QA ของฉันรายงานข้อบกพร่อง แต่ฉันหรือพวกเขาไม่มีความคิดเกี่ยวกับวิธีการทำซ้ำ สิ่งนี้นำไปสู่เซสชันการดีบักที่ยาวและน่าผิดหวังซึ่งบางครั้งไม่ได้ผลลัพธ์

ซอฟต์แวร์ของฉันเชื่อมโยงอย่างหนักกับฮาร์ดแวร์ที่เป็นกรรมสิทธิ์ดังนั้นข้อบกพร่องอาจมาจากหลายทิศทางพร้อมกัน

ฉันควรคาดหวังจากพวกเขามากกว่า "ซอฟต์แวร์ของคุณล้มเหลวเมื่อฉันกดปุ่ม" หรือฉันควรจะคิดเองว่าเกิดอะไรขึ้น?

แก้ไข:

เพื่อนร่วมงานคนหนึ่งของฉันชี้ให้เห็นว่าเราอาจเป็นนักพัฒนาซอฟต์แวร์ทั้งหมดที่นี่ดังนั้นผลลัพธ์อาจได้รับอคติเล็กน้อย

QA ควรพยายามและทำให้แมลงเป็นเรื่องง่ายสำหรับคุณในการทำซ้ำให้ได้มากที่สุดและคำอธิบายข้อผิดพลาดควรมีขั้นตอน

อย่างไรก็ตามหากพวกเขาไม่สามารถสร้างข้อผิดพลาดได้อย่างง่ายดายพวกเขายังควรได้รับการป้อนลงในฐานข้อมูลบั๊กที่มีชื่อเรื่อง / หัวที่เหมาะสมและคำอธิบายแบบเต็มของสิ่งที่พวกเขาทำเพื่อก่อให้เกิดข้อผิดพลาด คำอธิบายข้อผิดพลาดควรระบุอย่างชัดเจนว่าพวกเขาไม่สามารถทำซ้ำข้อผิดพลาด (อาจมีความคิดเห็นตามบรรทัดของ "ลองห้าครั้งมันเกิดขึ้นเพียงครั้งเดียว") ด้วยวิธีนี้ถ้าคนอื่นเห็นข้อผิดพลาดเดียวกันพวกเขาสามารถเพิ่มลงในฐานข้อมูลข้อผิดพลาดด้วยการค้นพบของพวกเขาและคุณยังได้รับข้อมูลมากที่สุดเท่าที่เป็นไปได้ซึ่งยิ่งไปกว่านั้นอาจมีความสำคัญในการประหยัดเวลา

นอกจากนี้คุณจะได้รับการกรองข้อมูล - อาจมีข้อบกพร่องมากมายในระบบต่าง ๆ ที่คุณรู้ว่ามีการเชื่อมโยงไปยัง (เช่น) ส่วนหนึ่งของรหัส - หาก QA ไม่รายงานอะไรเลย (เพราะพวกเขาไม่สามารถทำซ้ำได้ ) ดังนั้นข้อมูลนี้จะไม่ได้รับจากคุณ

ดูเหมือนว่าแผนกควบคุมคุณภาพของคุณกำลังทำการทดสอบแบบสำรวจมากเกินไป (เช่นพวกเขาไม่มีแผนการทดสอบที่ดี)

การทดสอบเชิงสำรวจนั้นดีและระบุพื้นที่ที่มีปัญหา แต่จากนั้นควรกำหนดกรณีทดสอบที่ทำซ้ำได้ (เช่นแผนทดสอบ) เพื่อดำเนินการที่จะเปิดเผยข้อบกพร่องเฉพาะ

มีเหตุผลหลายประการที่จำเป็นต้องมีการทำสำเนาที่ถูกต้อง (ไม่ใช่แค่ดี แต่จำเป็น):

1. คุณต้องทำซ้ำเพื่อให้คุณสามารถดีบัก / ติดตามสาเหตุ
2. QA จะต้องสามารถยืนยันการแก้ไขได้เมื่อดำเนินการเสร็จ
3. การทดสอบผ่านเพิ่มเติมจะต้องทำการถดถอยข้อบกพร่องก่อนหน้า
4. สามารถกำจัดแมลงที่รู้จักได้หากการรับแสงมีขนาดเล็กเกินไป

ดังนั้นตามที่ SteveCzetty จดบันทึก: ปิดมันโดยไม่ต้องทำซ้ำและกลับไปทำงานได้

หากข้อผิดพลาดไม่สามารถทำซ้ำได้อย่างสม่ำเสมอ QA จะรู้ได้อย่างไรว่ามันได้รับการแก้ไขแล้ว?

ใช่คุณควรคาดหวังจากพวกเขามากขึ้น พวกเขาควรจะพูดว่า:

1. เริ่มต้นอินสแตนซ์ใหม่ของโปรแกรม
2. ฉันกดปุ่ม A
3. ป้อน "ข้อความทดสอบ" ลงในฟิลด์ TEST NAME บนแบบฟอร์ม # 1
4. กดปุ่ม B
5. สังเกตว่าโปรแกรมขัดข้องกับข้อความนี้ (ดูภาพหน้าจอที่แนบมา)

หากสิ่งที่พวกเขาบอกคือ "มันล้มเหลว" พวกเขาไม่ดีมาก แม้ว่าขั้นตอนข้างต้นจะไม่สามารถทำซ้ำได้ 100% ตัวอย่างความล้มเหลวที่มีขนาดใหญ่พออาจช่วยให้สาเหตุแคบลงเมื่อตรวจพบรูปแบบ

คำแนะนำของฉันคือการอ่านข้อบกพร่องเหล่านั้นและให้พวกเขาคิดว่าดีเก่า หากคุณไม่สามารถหาสาเหตุที่เป็นไปได้ให้ลืมเรื่องเหล่านี้ไปก่อน

QA ควรจัดทำเอกสารทุกปัญหาที่พบแม้ว่าจะไม่รู้ว่ามันเกิดขึ้นได้อย่างไร เป็นหน้าที่ของ QA ในการพยายามทำซ้ำปัญหาต่างๆ แต่ในความเป็นจริงสิ่งนี้จะไม่เกิดขึ้นได้เสมอไป บางครั้งไม่มีอะไรเกี่ยวข้องกับสิ่งที่พวกเขาทำในช่วง 10 นาทีที่ผ่านมา มีบางอย่างเข้าสู่สถานะที่ไม่ถูกต้องเมื่อวันก่อนและมันเพิ่งจะปรากฏขึ้นเพราะหนึ่งใน 10 ขั้นตอนสุดท้าย

ด้วยข้อบกพร่อง "1 in 1000" เหล่านี้ QA ควรลองทำซ้ำอีกเล็กน้อย หากพวกเขาไม่ประสบความสำเร็จพวกเขาควรบันทึกข้อผิดพลาดจากนั้นลองอีกเล็กน้อย

เหตุผลที่พวกเขาควรได้รับบั๊กที่ป้อนค่อนข้างเร็วคือโปรแกรมเมอร์รู้โค้ดดีกว่า QA และอาจรู้ปัญหาทันที อาจเป็นรหัสที่พวกเขา refactored อาจเป็นได้ว่าฟังก์ชั่นที่พวกเขาใช้งานไปครึ่งหนึ่งนั้นลืมไปแล้ว พวกเขาอาจไม่มีความคิด แต่ไม่มีเหตุผลในการทดสอบเสียเวลาสองสามชั่วโมงพยายามที่จะทำให้เกิดปัญหาที่ชัดเจนกับคนที่เขียนมัน ผู้ทดสอบสามารถเพิ่มรายละเอียดเพิ่มเติมลงในข้อบกพร่องได้ในภายหลัง

ข้อผิดพลาดควรมีข้อมูลให้มากที่สุด สิ่งที่ผู้ทดสอบสามารถจดจำได้เกี่ยวกับการนำไปสู่ปัญหาควรเขียนลงในรายละเอียดที่เจ็บปวด ควรแนบไฟล์บันทึกการขัดข้องภาพรวมฐานข้อมูลหรือภาพหน้าจอที่เกี่ยวข้องด้วยเช่นกัน

หากข้อผิดพลาดไม่เคยทำซ้ำได้ดีมาก! ไม่เจ็บที่มีอยู่ในฐานข้อมูล หากโปรแกรมนั้นเผยแพร่และผู้ใช้รายงานข้อบกพร่องที่คล้ายกันในภายหลังคุณสามารถเปรียบเทียบประสบการณ์ของพวกเขากับสิ่งที่อยู่ในรายงานและมองหาสิ่งที่คล้ายคลึงกัน

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

ข้อบกพร่องมากมายไม่สามารถทำซ้ำได้จนกว่าคุณจะรู้วิธีแก้ไข ไม่ได้หมายความว่าพวกเขาไม่จำเป็นต้องได้รับการแก้ไข ฉันแก้ไขข้อผิดพลาดเมื่อปีที่แล้วที่ฉันยังไม่รู้วิธีการทำซ้ำ มันต้องมีการผสมผสานที่ผิดปกติของข้อผิดพลาดในการส่งที่กำหนดเวลาอย่างแม่นยำพร้อมกับข้อมูลขยะที่เฉพาะเจาะจงมากในตำแหน่งหน่วยความจำที่แน่นอนบนสแต็ก น่าเสียดายที่ลูกค้าคนหนึ่งของเรา "โชคดี" มากพอที่จะรับสภาพนั้นตลอดเวลา

ดังนั้นโดยทั้งหมดกระตุ้นให้ QA รวมขั้นตอนการทำซ้ำที่เป็นไปได้ แต่อย่าทำผิดถ้าไม่ บางครั้งมันจะช่วยให้คุณรู้ว่าจะเพิ่มการบันทึกที่ไหน บางครั้งมันก็บอกคุณว่าอะไรที่ไม่ทำให้เกิดปัญหา แต่รายงานบั๊กนั้นมีประโยชน์เสมอ

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

โดยทั่วไปแล้วข้อบกพร่องที่ทำซ้ำไม่ได้ควรมีลำดับความสำคัญต่ำ แต่ควรบันทึกไว้อย่างแน่นอน

IMO คุณควร QA ไม่ทำงานหากพวกเขาไม่สามารถทำขั้นตอนการสืบพันธุ์ให้คุณได้ อย่าเสียเวลาพยายามทำสิ่งที่คุณทำไม่ได้เพียงแค่ปิดเพราะ "ไม่สามารถทำซ้ำได้" และเดินหน้าต่อไป

เวลาของคุณมีค่ามากกว่านั้น

รายงานข้อผิดพลาดควรมี:

• ขั้นตอนในการทำซ้ำ
• พฤติกรรมที่แท้จริง
• พฤติกรรมที่คาดหวัง

เช่น:

• ฉันลบผู้จัดหาทั้งหมดจากฐานข้อมูล (โดยใช้DELETE * FROM tSuppliers) เปิดกล่องโต้ตอบผู้จัดหาและคลิกที่รายการผู้ผลิตแบบหล่นลง
• GUPOS ERROR #0000000: SOMETHING WENT WRONG!รายการที่มีข้อความต่อไปนี้: เมื่อฉันคลิกที่ข้อความแอพหายไปจากหน้าจอและตัวจัดการงาน
• ฉันคาดว่าจะเห็นรายการที่ว่างเปล่าหรือ (ควร) ข้อความเช่น "ไม่พบซัพพลายเออร์" คลิกที่รายการว่างเปล่าหรือข้อความไม่ควรมีผลใด ๆ แอพนี้ไม่ควรหายไปโดยไม่มีการเตือนไม่ว่าในกรณีใด ๆ

ดังนั้นใช่ - ควรมีขั้นตอนในการทำซ้ำ ข้อเท็จจริงที่ว่าพวกเขาไม่รู้สึกว่าจำเป็นที่จะต้องรวมสิ่งนี้ดูเหมือนจะบ่งบอกว่าพวกเขาคิดว่างานของพวกเขาคือ "ทำลายซอฟต์แวร์" แทนที่จะระบุความผิดพลาด

QA ควรทำซ้ำข้อบกพร่องตามขั้นตอนที่ป้อน หากพวกเขาพยายามอย่างหนักยังคงทำซ้ำไม่ได้พวกเขายังควรป้อนบั๊กที่มีรายละเอียดมากที่สุดเท่าที่พวกเขามีกับการประทับเวลาเพื่อให้นักพัฒนาสามารถดูแอปพลิเคชันและบันทึกการดีบักสำหรับรายละเอียดเพิ่มเติม

เงินเป็นเดิมพันที่นี่ เหตุใดสมาชิกในทีมควรจะสามารถสร้างงานที่ไม่ชัดเจนและมีโอกาสประสบความสำเร็จต่ำซึ่งเป็นภาระแก่นักพัฒนาที่มีรายได้สูง (หวังว่า)

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

เมื่อปัญหาสามารถแสดงให้เห็นถึงผลกระทบในเชิงลบและวัดได้ต่อมูลค่าของผลิตภัณฑ์ก็ควรจะตรวจสอบทำซ้ำและแก้ไข แก้ไขขั้นตอนข้อบกพร่องของผลิตภัณฑ์ของคุณเพื่อกรองสัญญาณรบกวน

ทีมงาน QA ของคุณแย่จัง

ไปกับพวกเขาและบอกให้พวกเขาอ่านเอกสารที่ใด ๆ ทดสอบมืออาชีพได้ที่จะมีการพิมพ์ภายในสมองของพวกเขา (ผมเป็นผู้ทดสอบครั้งเดียวและฉันยังคงมีมันมีสิทธิในสมองของฉัน): วิธีการรายงานข้อบกพร่องได้อย่างมีประสิทธิภาพ

โดยเฉพาะให้ชี้ไปที่ส่วน"แสดงวิธีแสดงตัวเองให้ฉัน" :

นี่คือยุคของอินเทอร์เน็ต นี่คือยุคของการสื่อสารทั่วโลก นี่คือยุคที่ฉันสามารถส่งซอฟต์แวร์ของฉันไปให้ใครบางคนในรัสเซียได้ด้วยการกดปุ่มเพียงปุ่มเดียวและเขาสามารถส่งความคิดเห็นถึงฉันได้อย่างง่ายดาย แต่ถ้าเขามีปัญหากับโปรแกรมของฉันเขาไม่สามารถให้ฉันยืนต่อหน้ามันได้ในขณะที่มันล้มเหลว "แสดงให้ฉันเห็น" เป็นสิ่งที่ดีเมื่อคุณทำได้ แต่บ่อยครั้งที่คุณทำไม่ได้

หากคุณต้องรายงานข้อผิดพลาดให้โปรแกรมเมอร์ที่ไม่สามารถแสดงตนได้ด้วยตนเองจุดมุ่งหมายของการฝึกคือเพื่อให้พวกเขาสามารถสร้างปัญหาขึ้นมาใหม่ได้ คุณต้องการให้โปรแกรมเมอร์รันสำเนาของโปรแกรมทำสิ่งเดียวกันและทำให้มันล้มเหลวในลักษณะเดียวกัน เมื่อพวกเขาเห็นปัญหาที่เกิดขึ้นต่อหน้าต่อตาพวกเขาก็สามารถจัดการกับมัน ...

หากพวกเขาเริ่มตะโกนใส่คุณบ่นว่า"แมลงมาจากหลายทิศทางพร้อมกัน"บอกพวกเขาว่าพวกเขาดูดมากกว่าที่คุณคิดไว้ก่อน บอกพวกเขาว่าTestabilityเป็นคุณสมบัติที่พวกเขาควรประเมินระหว่างคุณสมบัติของโครงการอื่น ๆ และพวกเขาควรลงทุนในการทำให้คุณสมบัตินี้ถูกต้อง

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