ในการต่อสู้ใครยืนยันว่า "เสร็จสิ้น"

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

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

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

หากมีข้อสงสัยให้หารือกับทีมและอาจารย์การต่อสู้และตัดสินใจร่วมกัน

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

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

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

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

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

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

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

ในท้ายที่สุดมันเป็นเจ้าของผลิตภัณฑ์ที่ลงนามในเรื่องใดเรื่องหนึ่งดังนั้นในตอนท้ายของวันที่เขาหรือเธอมีการตัดสินใจขั้นสุดท้ายว่าเรื่องราวทั้งหมดนั้นเสร็จสิ้นแล้วหรือไม่

คำถามแรกที่คุณควรถามตัวเอง

คุณเป็นอาจารย์การต่อสู้หรือไม่ ถ้าใช่.

ในกระบวนการต่อสู้ถูกควบคุมและจัดการโดย Scrum Master

คุณจะทำอย่างไรมันได้หรือไม่:

ในขั้นตอนความต้องการคุณสามารถใช้เรื่องราวของผู้ใช้สำหรับแต่ละการทดสอบที่ต้องได้รับการยืนยัน

ใน Sprint แต่ละรายการงานจะถูกดึงมาจากการค้างสินค้าและกำกับโดยเจ้าของผลิตภัณฑ์แต่ละรายการจะมีเกณฑ์การตรวจสอบเช่นกัน

ตอนนี้ในความต้องการการต่อสู้ไม่เปลี่ยนแปลงหลังจากการเริ่มต้น Sprint ในตอนท้ายของ Sprint คุณสามารถวิเคราะห์การตรวจสอบตามเกณฑ์สำหรับแต่ละรายการที่ทำ

หากพบว่าเสร็จสิ้นสามารถพบได้โดยการตอบสนองของเจ้าของผลิตภัณฑ์เท่านั้น

จำไว้ว่าใน Agile คุณ"ยอมรับการเปลี่ยนแปลง"แม้จะอยู่ในช่วงพัฒนาแล้วก็ตาม

ทีมตัดสินใจ ฉันใช้รายการตรวจสอบสำหรับสิ่งที่ถือว่า 'เสร็จสิ้น' สิ่งที่ 'เสร็จสิ้น' ต่อเรื่องราวต่อการวิ่งหนึ่งครั้งต่อการเปิดตัว

ดังที่คนอื่น ๆ ได้กล่าวถึงในที่สุดการตัดสินใจขึ้นอยู่กับเจ้าของผลิตภัณฑ์

ยอมรับว่านี่เป็นสิ่งที่ทีมพัฒนา / ทดสอบจำเป็นต้องกำหนดขึ้นอยู่กับวิธีปฏิบัติของคุณเอง บางโครงการมีความว่องไวและเต็มใจที่จะเสี่ยงที่จะปล่อยบั๊กไปยังกระแสอัลฟ่า บางคนพิจารณาข้อผิดพลาดใด ๆ ที่ทำให้กระบวนการกลุ่มล้มเหลว

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

เห็นได้ชัดว่าไม่ได้รับประกันว่าจะไม่มีใครพบวิธีใหม่ในการล้มเหลว แต่ลดความเสี่ยงลงสู่ระดับที่ยอมรับได้โดยไม่ขัดขวางการพัฒนาอย่างรวดเร็ว