Dilemma ของ QA เทียบกับการวนซ้ำ

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

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

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

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

หากไม่มีการใช้การวนซ้ำนี่จะไม่มีปัญหาเพราะเราสามารถซ้อนทับงานสำหรับการปล่อย N และ N + 1 อย่างไรก็ตามจากสิ่งที่ฉันเข้าใจว่าสิ่งนี้ไม่เข้ากันกับวิธีการทำซ้ำเช่น Scrum หรือ XP พวกเขาต้องการให้ทำซ้ำได้ในตอนท้ายด้วยความพยายามในการทดสอบทั้งหมดเพื่อรวมไว้ในการทำซ้ำ

ฉันพบว่าสิ่งนี้จะนำไปสู่ผลลัพธ์ที่ไม่พึงประสงค์อย่างใดอย่างหนึ่งต่อไปนี้:

(A)นักพัฒนาไม่มีการใช้งานเมื่อสิ้นสุดการทำซ้ำเนื่องจาก QA ต้องใช้เวลาในการตรวจสอบผู้สมัครรุ่นใหม่และงานแก้ไขข้อผิดพลาดไม่ได้ทำให้ devs ยุ่งอยู่เสมอ

(B) QA เริ่มทำงานแล้วก่อนที่ผู้สมัครรุ่นแรกจะพร้อม นี่คือสิ่งที่แนะนำเป็นส่วนใหญ่บน Stack Exchange แต่มันไม่ใช่สิ่งที่ บริษัท ของฉันเข้าใจว่าเป็น QA เพราะไม่มีการทดสอบผู้สมัครรุ่นเฉพาะ และ "การเปลี่ยนแปลงเล็ก ๆ น้อย ๆ " ที่ทำลายทุกสิ่งทุกอย่างยังสามารถถูกนำมาใช้โดยไม่สังเกต

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

มีทางออกจากภาวะที่กลืนไม่เข้าคายไม่ออกนี้หรือไม่?

เราเข้าใจว่า QA เป็นบิตของการตรวจสอบเพิ่มเติมสำหรับบิวด์บางตัว (รีลีสผู้สมัคร) ก่อนที่บิลด์นี้จะนำไปใช้กับลูกค้า

ไม่มีสิ่งใดที่เข้ากันไม่ได้โดยเนื้อแท้ระหว่างรูปแบบของการควบคุมคุณภาพและวิธีการทำซ้ำเช่น Scrum
ภายใน Scrum ทีมส่งมอบในรอบ X- รายสัปดาห์ให้กับลูกค้า ส่วนที่สำคัญคือถ้าทีมพัฒนากำลังต่อสู้กับ Scrum ลูกค้าของพวกเขาคือทีม QA ไม่ใช่ผู้ใช้ผลิตภัณฑ์ของคุณ

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

สำหรับสถานการณ์ในชีวิตจริงส่วนใหญ่ความคล่องตัวหยุดส่งถึง QA / UAT หรืออะไรก็ตามที่เรียกว่า

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

ในกรณีที่รุนแรงซอฟต์แวร์อาจต้องการการรับรองจากหน่วยงานภายนอกหรือต้องผ่านการทดสอบความปลอดภัยอย่างเข้มงวด

ในสถานการณ์เหล่านี้เป็นไปไม่ได้ที่จะมองเห็นมากกว่าหนึ่งรุ่นต่อไตรมาสยกเว้นการแก้ไขข้อบกพร่อง

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

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

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

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

ซื้อสำเนาของการส่งมอบอย่างต่อเนื่องของJez Humbleอ่านส่งต่อให้ครอบคลุมรอบ ๆ ทีม รับแรงบันดาลใจทุกคน จากนั้นใช้ทุกสิ่งที่คุณสามารถทำได้

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

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

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

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

อธิบายให้พวกเขาทราบว่าก) มันจะปรับปรุงความเสถียรของการเปิดตัวและ b) จะปรับปรุงความสามารถของคุณในการตอบสนองต่อปัญหาสำหรับพวกเขาและ c) มันจะปรับปรุงความเร็วให้พวกเขาในภายหลัง เป็น บริษัท ที่หายากที่ไม่ต้องการสิ่งเหล่านี้ แน่นอนว่าไม่ใช่ บริษัท เปรียวที่ไม่ต้องการถ้าคุณได้รับการต่อต้านคุณจะรู้ว่าคุณมีปัญหาที่แตกต่าง

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

หากไม่มีการใช้การวนซ้ำนี่จะไม่มีปัญหาเพราะเราสามารถซ้อนทับงานสำหรับการปล่อย N และ N + 1

ดูเหมือนจะมีปัญหากับวิธีการที่คุณตัดสินใจเกี่ยวกับสิ่งที่ถือว่าwork for release Nแท้จริง

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

• ^{ถ้าเป็นเช่นนั้นจริง ๆ แล้วฉันคิดว่าความนิยมของ Agile จะไม่ใกล้เคียงกับที่เราเห็นในตอนนี้ ฉันไม่สามารถจินตนาการหลายโครงการที่สามารถ "เอาตัวรอด" การซิงค์บังคับของทีม dev ซ้ำกับรอบการทดสอบ QA}

มีความคล่องตัวเพิ่มขึ้นเล็กน้อยด้านล่าง แต่ก่อนอื่นมาสังคายนาwork for release N...

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

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

โปรดทราบว่าวิธีการที่คุณกำหนด work for release Nไม่ได้ถูกบังคับโดย QA เวิร์กโฟลว์ จากสิ่งที่คุณอธิบายสิ่งต่าง ๆ ดูเหมือนว่าพวกเขามีตารางเวลาของตนเอง (และค่อนข้างสมเหตุสมผล)

ให้ไว้ข้างต้นวิธีที่สมจริงมากขึ้นในการกำหนดหน่วยงานในกรณีของคุณอาจเป็นดังนี้:

1. กิจกรรมการพัฒนาจนถึงช่วงเวลาที่บิลด์จะถูกส่งไปยัง QA
   Release Candidate N
2. กิจกรรมการพัฒนาที่เกี่ยวข้องกับรอบการทดสอบ QA แรก
   Release Candidate N patch 1
3. กิจกรรมการพัฒนาที่เกี่ยวข้องกับรอบการทดสอบ QA ครั้งที่สอง
   Release Candidate N patch 2
4. เป็นต้นจนกว่าจะสร้างขั้นสุดท้าย

ข้างต้นเป็นหน่วยงานของคุณไม่ว่าคุณจะทำแบบ Agile หรืออะไรก็ตาม

สิ่งเหล่านี้เป็นธรรมชาติและสะดวกสบายในการกำหนดติดตามและติดตาม สิ่งนี้ยังรวมเข้ากับตาราง QA ได้เป็นอย่างดีช่วยให้สามารถประสานงานกับผู้อื่นได้อย่างสะดวก

อย่างไรก็ตามจากสิ่งที่ฉันเข้าใจว่าสิ่งนี้ไม่เข้ากันกับวิธีการทำซ้ำเช่น Scrum หรือ XP พวกเขาต้องการให้ทำซ้ำได้ในตอนท้ายด้วยความพยายามในการทดสอบทั้งหมดเพื่อรวมไว้ในการทำซ้ำ

ความเข้าใจด้านบนของความเข้ากันได้กับ Agile นั้นผิดปกติและนี่คือสาเหตุ ...

อัสสัมชัคุณทำมีอะไรจะทำอย่างไรกับเปรียวถ้าเราเอาของปรัชญาที่มูลค่าตามที่ระบุโดยชื่อของมันนั่นคือวิธีการที่โปรดปรานและการปฏิบัติที่มีความคล่องตัว

จากมุมมองดังกล่าวการยึดติดกับเวิร์กโฟลว์ "คงที่" โดยเฉพาะและไม่สนใจว่าสะดวกหรือไม่เพียง แต่ขัดกับจิตวิญญาณของ Agile ทาสต่อไป "ขั้นตอน" นำไปสู่การปฏิบัติที่denigratedอย่างเลิศหรูในครึ่ง arsed เปรียว "... เรามีกระบวนการบังคับและเครื่องมือในการควบคุมวิธีการที่บุคคลเหล่านั้น (เราชอบ 'ทรัพยากรคำ) โต้ตอบ"

คุณสามารถหาข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ในคำตอบของคำถามอื่นที่ยกมาด้านล่าง ลองดูที่บันทึกใน "การปล่อย shippable" ดูเหมือนว่าตอนนั้น OP สับสนในลักษณะเดียวกัน:

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

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

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

ฉันเห็นใครทำผิดทางอาญาในการรักษา Sprint-end-release เป็นเพียงจุดตรวจสอบบางอย่างที่น่าพอใจของทีม

• ^{dev: ใช่ว่าคนที่ดูดีพอที่จะผ่านไปยังผู้ทดสอบ; QA: ใช่แล้วว่ามันดูดีพอสำหรับกรณีนี้ถ้าต้องการการทดสอบแบบ shippable เพิ่มเติม - สิ่งที่ต้องการ ทีม (dev + QA) พอใจนั่นแหล่ะ}