การสั่งซื้อ / การจัดการข้อบกพร่องหลายพันข้อก่อนปล่อย
คำถามนี้ถูกถามกับฉันในการสัมภาษณ์กับ บริษัท ที่ดีจริงๆด้านล่างนี้ฉันจะให้คำถามในรูปแบบของการโต้ตอบของเรา (M: me & I: ผู้สัมภาษณ์) แม้ว่าจะไม่มี ans ที่ชัดเจน แต่ฉันต้องการรู้อะไร แนวคิด / คำตอบที่ผู้สัมภาษณ์ต้องการจริงๆ :
I: สถานการณ์คือคุณและอีก 2 คนประกอบด้วยทีมทดสอบ คุณซึ่งเป็นผู้นำเป็นเพียงคนเดียวที่สามารถทำระบบอัตโนมัติได้ส่วนคนอื่น ๆ สามารถทดสอบด้วยตนเองเท่านั้น คุณมีข้อบกพร่องเกือบ 10,000 รายการที่ถูกเลี้ยงและคุณมีเวลา 4-5 สัปดาห์หรือน้อยกว่าก่อนที่จะส่งมอบผลิตภัณฑ์นี้ คุณจะทำอย่างไรเพื่อให้แน่ใจว่าสินค้าจะถูกส่งทันเวลา?
M: กรองลำดับความสำคัญของจุดบกพร่องอย่างชาญฉลาดและทดสอบอีกครั้ง ในระหว่างนี้ให้บันทึกเกี่ยวกับฟังก์ชันการทำงานที่ถดถอยมากขึ้นและเริ่มทำงานโดยอัตโนมัติ ข้อบกพร่องที่คล้ายกันหรือเกี่ยวข้องจะถูกมอบให้กับผู้อื่นเพื่อทำการทดสอบต่อไป
ฉัน: สมมติว่าไม่มีข้อบกพร่องใดที่ถูกทำเครื่องหมายด้วยลำดับความสำคัญใด ๆ คุณจะทำอะไร?
ตอบ: ฉันจะกรองด้วยวันที่ใน SDLC ทุกประเภทแม้แต่แบบเปรียวส่วนประกอบหลักจะได้รับการพัฒนาก่อนหากมีจุดบกพร่องหลักก็ต้องได้รับการแก้ไขก่อน
ฉัน: (ไม่เห็นด้วย) จะเป็นอย่างไรหากมีการเพิ่มฟังก์ชันที่สำคัญมากในการวิ่งครั้งหลัง นอกจากนี้คุณจะใช้ประโยชน์จากเพื่อนร่วมทีมและความสามารถในการทำงานอัตโนมัติได้อย่างไร
ตอบ: นอกจากวันที่แล้วในฐานะผู้ทดสอบฉันจะต้องรู้แกนหลักและฟังก์ชันการทำงานที่สำคัญของผลิตภัณฑ์จนถึงปัจจุบันดังนั้นโปรดทราบว่าจะพบว่าพื้นที่หลักของการวิ่งแต่ละครั้งต้องดำเนินการ (เกี่ยวกับเพื่อนร่วมทีมก็ตอบในสิ่งเดียวกัน เหมือนก่อน).
ฉัน: สมมติว่าข้อบกพร่องไม่ได้ถูกทำเครื่องหมายด้วยไทม์ไลน์ของการวิ่งแต่ละครั้ง คุณจะทำอะไร?
ตอบ: ฉันจะค้นหารายการจุดบกพร่องด้วยคีย์เวิร์ดซึ่งแสดงถึงฟังก์ชันการทำงานที่สำคัญโดยที่ผลิตภัณฑ์ไม่สามารถออกได้ ฉันจะเลือกข้อบกพร่องจากที่นั่น
ฉัน: (ไม่เห็นด้วยอีกครั้ง) ด้วยคำหลักคุณจะได้รับผลลัพธ์มากมายคุณจะอ่านทีละคำหรือไม่?
M: (สูญเสียความหวังอย่างช้าๆ) ฉันจะดูชื่อเรื่องและตัดสินใจ
ฉัน: โดยทั่วไปชื่อเรื่องจะไม่ค่อยมีคำอธิบายคุณจะจัดการอย่างไร?
ตอบ: ฉันจะเริ่มทดสอบผลิตภัณฑ์ด้วยตัวเองและค้นหาจุดบกพร่องที่คล้ายกันที่ฉันเผชิญแทนที่จะพยายามผ่านจุดบกพร่องเพราะฉันต้องตัดสินใจในการจัดส่งผลิตภัณฑ์
ฉัน: คุณจะเพิกเฉยต่อข้อบกพร่องมากมายเหล่านั้นเหรอ? ผู้มีส่วนได้ส่วนเสียอาจไม่เห็นด้วย (หลังจากนั้นฉันก็ทำมันหายไปโดยสิ้นเชิงและเอาแต่พูดพึมพัมและฉันจำไม่ได้ว่ามีอะไรอีกบ้างที่ถามนอกจากนี้ทุกที่ที่มีการถามการจัดการ / การทำงานของผู้ทดสอบด้วยตนเองอีก 2 คน)
นี่คือบทสัมภาษณ์ของ Sr SDET
คำตอบ
นอกเหนือจากสิ่งที่คำตอบอื่น ๆ กล่าวแล้วฉันจะบอกว่าผู้สัมภาษณ์กำลังมองหาวิธีที่คุณเป็นส่วนเสริมใหม่ของทีมที่จะจัดการกับสถานการณ์ที่ไม่มีชัยชนะ ตรงไปตรงมาฉันสงสัยว่าอย่างน้อยที่สุด บริษัท ก็พบว่าตัวเองตกอยู่ในสถานการณ์แบบนี้ในอดีต ที่แย่ที่สุด (ฉันยอมรับอย่างอิสระว่าฉันเหยียดหยาม) สิ่งที่คล้ายกันกำลังจะเผชิญหน้ากับใครก็ตามที่ได้รับตำแหน่ง
ในฐานะผู้สัมภาษณ์ฉันต้องการสิ่งนี้จากบุคคลที่ฉันกำลังสัมภาษณ์:
อันดับแรกฉันต้องการทราบว่าข้อบกพร่องเหล่านี้มีการจัดระเบียบอย่างไรโดยเฉพาะลำดับความสำคัญความรุนแรงและความเสี่ยง ฉันสมมติว่าฉันกำลังเข้ามาในสถานการณ์นี้และไม่ใช่ว่าฉันมีส่วนร่วมตั้งแต่แรกเพราะสถานการณ์แบบนี้บ่งบอกว่ามีบางอย่างผิดปกติ
หากข้อบกพร่องไม่ได้รับการจัดระเบียบในลักษณะที่เกี่ยวข้องกับลำดับความสำคัญความรุนแรงและความเสี่ยงฉันต้องการพูดคุยกับผู้ทดสอบคนอื่น ๆ การจัดการโครงการและการพัฒนาเพื่อพิจารณาว่าปัญหาใดที่พวกเขาทราบว่าก่อให้เกิดความเสี่ยงสูงสุดต่อการปรับใช้ที่คาดการณ์ไว้ วันที่.
หากมีองค์กรดังกล่าวฉันต้องการพูดคุยกับผู้ทดสอบการจัดการโครงการและการพัฒนาเพื่อยืนยันข้อบกพร่องที่มีความเสี่ยงสูงสุด ตามหลักการแล้วฉันกำลังมองหาวิธีสร้างรายการข้อบกพร่องที่ต้องได้รับการแก้ไขก่อนที่จะออกผลิตภัณฑ์ ด้วยข้อบกพร่อง 10,000 รายการจะต้องใช้เวลาในการสร้างและสมมติว่าไม่มีข้อบกพร่องใดที่ผู้ทดสอบไม่สามารถค้นหาได้เนื่องจากข้อบกพร่องที่รายงานซ่อนอยู่หรือปิดกั้น
เมื่อฉันมีความคิดว่าสถานการณ์เลวร้ายแค่ไหนฉันก็ตัดสินใจได้ว่าในความคิดของฉันเป็นไปได้หรือไม่ที่จะปล่อยแอปพลิเคชันตามแผนที่วางไว้ หากข้อบกพร่องส่วนใหญ่มีความเสี่ยงค่อนข้างต่ำและข้อบกพร่องที่มีความเสี่ยงสูงดูเหมือนจะแก้ไขได้ง่ายพอสมควรฉันจะเน้นทีมของฉันไปที่จุดบกพร่องที่มีความเสี่ยงสูงและทำงานร่วมกับผู้จัดการโครงการและทีมอื่น ๆ เพื่อให้ได้รับความเสี่ยงสูงสุด (ความรุนแรงสูงส่วนใหญ่มักเกิดขึ้นในสนามและ / หรือบล็อกพื้นที่ของแอปพลิเคชัน) แก้ไขข้อบกพร่องและทดสอบแล้ว
หากฉันไม่เห็นวิธีในการเปิดตัวผลิตภัณฑ์ได้ทันเวลาฉันจะเริ่มคุยกับผู้จัดการโครงการและหัวหน้าของฉันเพื่อดูว่ามีวิธีในการใช้ฟังก์ชัน Solid รุ่นเบต้าแบบ จำกัด หรือเพื่อชะลอการเปิดตัว เนื่องจากฉันเพิ่งเข้าสู่ตำแหน่งนี้ฉันไม่รู้ว่ามีข้อกำหนดในสัญญาหรือปัจจัยอื่นใดที่อยู่นอกเหนือการควบคุมของฉันที่อาจบังคับให้วันที่วางจำหน่ายไม่สามารถเคลื่อนย้ายได้
นอกจากนี้ฉันยังตรวจสอบให้แน่ใจว่าหลังจากการเปิดตัวฉันได้พบกับผู้นำของทุกทีมที่เกี่ยวข้องเพื่อหาว่าสถานการณ์ดังกล่าวเกิดขึ้นได้อย่างไรและเราจะดำเนินการอย่างไรเพื่อป้องกันไม่ให้เกิดขึ้นอีกตลอดจนเราจะทำงานร่วมกันได้อย่างไร ทำให้ข้อผิดพลาดค้างลง
โปรดทราบว่าสิ่งนี้ไม่เกี่ยวข้องกับบทบาท SDET เป็นที่ชัดเจนจากคำถามที่ผู้สัมภาษณ์คาดหวังว่า SDET จะทำหน้าที่เป็นผู้นำในการทดสอบด้วย - ฉันไม่คิดว่านี่เป็นสิ่งที่ดีเป็นพิเศษและตรงไปตรงมาฉันต้องการทราบว่านี่เป็นสิ่งที่ บริษัท คาดหวังจากมันหรือไม่ SDET
ควรจำไว้ว่าแม้ว่าการสัมภาษณ์จะเป็นสถานการณ์ที่มีความเครียดสูง แต่พยายามคิดไปด้านข้างและมองไปที่ผลกระทบของคำถามที่คุณถามแทนที่จะดำดิ่งลงไปมันยากที่จะทำเพราะคุณเครียดและพยายามทำให้ดีที่สุด แต่ถ้าคุณสามารถใช้เวลาสักเล็กน้อยในการถามตัวเองทางจิตใจว่าผู้สัมภาษณ์กำลังมองหาคำถามอะไรคุณก็สามารถให้คำตอบที่ดีกว่าได้
สิ่งแรกที่ควรคำนึงถึงคือ - การทดสอบเหล่านี้เคยได้ผลมาก่อนหรือไม่? ถ้าเป็นเช่นนั้นอย่าเพิ่งตกใจ มีการเปลี่ยนแปลงบางอย่างในโค้ดเบสหรือกรอบการทดสอบที่อาจทำให้กลุ่มของพวกเขาล้มเหลว ติดตามสิ่งนั้นและดูว่าคุณสามารถกำจัดความล้มเหลวหลายพันครั้งได้หรือไม่ คุณยังคงต้องอ่านเรื่องที่ผ่านอีกครั้งด้วยตนเองและตรวจสอบอีกครั้ง แต่อาจใช้เวลาเพียงไม่กี่วัน
หากพวกเขาไม่เคยถูกตรวจสอบมาก่อนฉันก็ยังคงทำสิ่งที่คล้ายกันให้มองหาสิ่งธรรมดา ๆ ที่อาจช่วยให้คุณแก้ไขกลุ่มใหญ่ได้ในคราวเดียว
มิฉะนั้นจะมีเสียงดังมากอาจทำให้คุณพลาดสิ่งสำคัญที่ล้มเหลวได้
หลังจากนั้นยอมรับว่าคุณอาจไม่สามารถเข้าถึงทุกอย่างและมุ่งเน้นไปที่เส้นทางรหัสผู้ผลิตเงิน สิ่งที่ต้องทำงานหรือธุรกิจพับไป จากนั้นหลังจากที่คุณล้างข้อมูลเหล่านี้อีกสองสามครั้งวันเว้นวันหรือสามครั้งและดูว่ามีความล้มเหลวที่จัดกลุ่มอีกต่อไปตามที่กล่าวไว้ก่อนหน้านี้หรือไม่และลองล้างกลุ่มอื่น ๆ อีกสองสามกลุ่ม
หมายเหตุ: ตอบสิ่งนี้จากมุมมองของ SDET - คนที่สามารถแก้ไขฐานรหัสที่ละเมิดได้เอง
หากผู้สัมภาษณ์กล่าวถึงข้อบกพร่องและไม่ได้ทดสอบความล้มเหลว (หากการทดสอบล้มเหลวอ้างอิงคำตอบโดย @Lewis
ประการแรกการมีจุดบกพร่อง 10,000 รายการในผลิตภัณฑ์ถือเป็นธงสีแดงขนาดใหญ่จริงๆ
และคุณไม่ควรปล่อยผลิตภัณฑ์ดังกล่าว แต่หากการตัดสินใจของฝ่ายบริหารยังคงปล่อยไป
คำตอบที่ผู้สัมภาษณ์คาดหวังคือ " ความรุนแรง "
ทีมควรให้ความสำคัญกับการแก้ไขจุดบกพร่องที่มีความรุนแรงสูงก่อนหากไม่มีลำดับความสำคัญและให้หยุดพักชั่วคราวหากไม่ใช่ข้อกำหนดเร่งด่วนและไม่ส่งผลกระทบต่อตรรกะทางธุรกิจที่แท้จริง
และให้ความสำคัญกับการทดสอบควันโดยอัตโนมัติในขั้นต้นจากนั้นเริ่มชุดการถดถอยทั้งหมดโดยอัตโนมัติ
จัดกลุ่มจุดบกพร่องและดูว่าการจัดกลุ่มข้อบกพร่องเกิดขึ้นที่ใดและทดสอบโมดูลนั้นอย่างเข้มงวดเมื่อทำการแก้ไขแล้ว
ก่อนปล่อยให้ทดสอบสถานการณ์ทดสอบควันทั้งหมดด้วยตนเอง (ตรรกะทางธุรกิจที่สำคัญ)
นอกจากนี้การมีจุดบกพร่อง 10,000 จุดอาจส่งผลให้เกิดข้อบกพร่องในการกำบังซึ่งจุดบกพร่องเหล่านี้กำลังปกปิดจุดบกพร่องที่สำคัญบางอย่างภายในผลิตภัณฑ์
ดังนั้นเมื่อทำการแก้ไขแล้วควรทำการทดสอบอย่างเข้มงวดมากขึ้นรอบ ๆ โมดูลเพื่อขุดหาจุดบกพร่องที่สำคัญมากขึ้น
ดังนั้นถ้าฉันอยู่ในการสัมภาษณ์ฉันจะตอบว่า:
- จุดบกพร่อง 10,000 จุดในโครงการใด ๆ จะเป็นธงสีแดงขนาดใหญ่แสดงว่าไม่มีกระบวนการแก้ไขข้อบกพร่องและการประมาณค่าที่เหมาะสม ฉันจะกังวลอย่างแน่นอนเกี่ยวกับข้อบกพร่องการจัดกลุ่มและการกำบังข้อบกพร่องซึ่งหมายความว่ามีความเป็นไปได้ที่ข้อบกพร่องส่วนใหญ่จะรวมอยู่ในโมดูลเดียวและข้อบกพร่องจำนวนมากนี้อาจปกปิดข้อบกพร่องที่สำคัญอื่น ๆ ซึ่งจะระบุได้หลังจากแก้ไขและทดสอบโมดูลใหม่อย่างเข้มงวดเท่านั้น . และจะแนะนำให้ผลักดันวันที่วางจำหน่ายต่อไปเนื่องจากเหตุผลนี้
ในขณะที่ทีมพัฒนากำลังยุ่งอยู่กับการแก้ไขข้อบกพร่องเราจะเริ่มใช้กรณีการทดสอบควันและกรณีการใช้งานข้อบกพร่องโดยอัตโนมัติ เมื่อการแก้ไขมาถึงเราจะมอบหมายงานการทดสอบซ้ำให้กับผู้ทดสอบด้วยตนเองและเราเองก็ทำการทดสอบ adhoc อย่างเข้มงวดในโมดูลเพื่อค้นหาจุดบกพร่องที่สำคัญที่ถูกปิดบังไว้
- หากไม่มีลำดับความสำคัญก็คงไม่จำเป็นต้องทบทวนข้อบกพร่องที่สำคัญหรือมีความรุนแรงสูงก่อนและตรวจสอบอายุการใช้งานของข้อผิดพลาดและทำความเข้าใจว่าเหตุใดข้อบกพร่องที่ไม่ได้รับการแก้ไขเป็นเวลานานเพื่อช่วยในการปรับปรุงกระบวนการโดยรวมในอนาคต
เกี่ยวกับจุดบกพร่องที่มีความรุนแรงต่ำเราจำเป็นต้องทำการตัดสินใจของทีมเกี่ยวกับไทม์ไลน์และในการตัดสินใจในการเผยแพร่ว่าจะปล่อยเวอร์ชันแรกที่มีข้อบกพร่องเหล่านี้หรือไม่ แต่ยังคงจัดทำเอกสารเหมือนเดิมและวิธีแก้ปัญหาเมื่อจำเป็น ระบุวันที่เผยแพร่ถัดไปสำหรับการแก้ไขที่เป็นไปได้หากเป็นไปได้
ดังนั้นในการเป็น QA อาวุโสคุณควรแสดงความคิดเห็นที่หนักแน่นของคุณที่จะ "ไม่" เมื่อคุณเห็นธงสีแดง อย่ายืดหยุ่นเกินไป
คำตอบอื่น ๆ ที่นี่เป็นสิ่งที่ดีหากประเด็นของคำถามคือการให้คำตอบที่เป็นรูปธรรม
อย่างไรก็ตามผู้สัมภาษณ์จำนวนมากถามคำถามที่คลุมเครือโดยไม่มีคำตอบที่เจาะจงเพราะพวกเขาต้องการทราบว่าคุณคิดอย่างไรหรือเข้าใจว่าคุณตั้งสมมติฐานเกี่ยวกับคำถามนั้นอย่างไร พวกเขาต้องการให้คุณถามคำถามที่ชัดเจนเพื่อให้ได้ข้อมูลที่เฉพาะเจาะจง สิ่งนี้ช่วยแนะนำคำตอบของคุณ
สถานการณ์คือคุณและอีก 2 คนประกอบด้วยทีมทดสอบ คุณซึ่งเป็นผู้นำเป็นเพียงคนเดียวที่สามารถทำระบบอัตโนมัติได้ส่วนคนอื่น ๆ สามารถทดสอบด้วยตนเองเท่านั้น คุณมีข้อบกพร่องเกือบ 10,000 จุดที่ถูกเลี้ยงและคุณมีเวลา 4-5 สัปดาห์หรือน้อยกว่าก่อนที่จะส่งมอบผลิตภัณฑ์นี้ คุณจะทำอย่างไรเพื่อให้แน่ใจว่าสินค้าจะถูกส่งทันเวลา?
คำถามที่จะถาม:
- ผู้ทดสอบ qa ด้วยตนเองมีประสบการณ์แค่ไหน?
- ผู้ทดสอบด้วยตนเองมีประสบการณ์ในโครงการนี้หรือไม่? หรือยังใหม่กับโครงการด้วย?
- ทั้งหมด 10,000 ต้องได้รับการแก้ไขก่อนวันส่งมอบหรือไม่?
- มีซอฟต์แวร์ติดตามข้อบกพร่องที่ทีมใช้หรือไม่? ถ้าเป็นเช่นนั้นคืออะไร?
- ข้อบกพร่องที่ทราบได้รับการติดตามอย่างไร? พวกเขามีลำดับความสำคัญความรุนแรงที่ระบุไว้หรือไม่? พวกเขาจัดกลุ่ม / แท็กตามคุณลักษณะหรือไม่?
- มีการทดสอบอัตโนมัติที่ใช้กับซอฟต์แวร์อยู่หรือไม่? ถ้าเป็นเช่นนั้นการทดสอบหน่วยการทดสอบการรวมการทดสอบ UI มีกี่แบบ? หรือฉันต้องสร้างการทดสอบ / กรอบการทำงานอัตโนมัติทั้งหมดตั้งแต่เริ่มต้นในกรอบเวลา 4-5 สัปดาห์
- นักพัฒนารับผิดชอบการทดสอบมากน้อยเพียงใด พวกเขากำลังสร้างการทดสอบหน่วย / การรวมหรือไม่
- บัก UI 10,000 บั๊กหรือเปล่า หรือการผสมผสานของจุดบกพร่องที่สามารถทดสอบได้โดยใช้การทดสอบหน่วยการทดสอบการรวมการทดสอบ UI?
- ต้องใช้อุปกรณ์อะไรบ้างในการทดสอบ?
- ระดับคุณภาพที่เราต้องเข้าถึงเพื่อตอบสนองผู้ใช้และผู้มีส่วนได้ส่วนเสียคืออะไร? ผู้มีส่วนได้ส่วนเสียรับรู้ถึงคุณภาพอย่างไร?
- ผู้มีส่วนได้ส่วนเสียจะพิจารณาการเปิดตัวโครงการที่ประสบความสำเร็จได้อย่างไร?
- คำจำกัดความของทีมคืออะไร?
- ทีมงานจะมีเวลาหลังจากการเผยแพร่โครงการเพื่อแก้ไขข้อบกพร่องหรือไม่? หรือเรากำลังเดินหน้าโครงการต่อไป? เราจะมีเวลาเท่าไหร่ถ้าเรามีเวลา?
- ทีมใช้ Agile SDLC หรือ Waterfall SDLC หรือไม่
มีคำถามมากมายที่คุณสามารถถามเพื่อรับคำชี้แจงที่คุณต้องการเพื่อให้คำตอบที่ไตร่ตรองไว้อย่างดี
และจากการสนทนาโดยละเอียดข้างต้นผู้สัมภาษณ์ยังคงแจ้งให้ทราบถึงรายละเอียดเกี่ยวกับวิธีรวมผู้ทดสอบด้วยตนเองไว้ในแผนของคุณ สิ่งนี้ช่วยให้คุณทราบได้อย่างชัดเจนว่าผู้สัมภาษณ์กำลังมองหาอะไรพวกเขาไม่ต้องการให้คุณรับภาระทั้งหมดในการทดสอบโครงการนี้ด้วยตัวเอง พวกเขาต้องการทราบว่าในฐานะวิศวกร SDET / QA ระดับอาวุโสคุณให้คำปรึกษา / นำทีมผู้ทดสอบระดับจูเนียร์อย่างไร
โปรดทราบว่าการสัมภาษณ์ไม่ควรเป็นการซักถามที่คุณเพียงแค่ตอบคำถามของพวกเขา การสัมภาษณ์ควรเป็นการสนทนาที่คุณสามารถถามอะไรก็ได้ที่ช่วยชี้แจงคำถามของพวกเขา