แนวทางปฏิบัติที่ดีที่สุดในการทดสอบกลยุทธ์สำหรับทีม Scrum

Scrum ลบแผนการทดสอบเท่ากับ POC บนสเตียรอยด์

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

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

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

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

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

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

กระจายความเจ็บปวด

เราจะเริ่มต้นที่ไหนอีกเมื่อต้องรับมือกับการรบกวนที่ไม่จำเป็นมากกว่าการแยกความเจ็บปวด :)

และสิ่งที่ฉันหมายถึงคือการสร้างแผนที่จะต้องมีกิจกรรมเพิ่มเติมเล็กน้อยจากนักพัฒนาที่นี่และที่นั่น แต่นั่นจะนำไปสู่เป้าหมายร่วมกันอย่างมากเมื่อเวลาผ่านไป ทีละน้อยแต่สม่ำเสมอ

#1. พัฒนารหัสทดสอบหน่วยสำหรับรหัสใหม่แต่ละชิ้นที่สร้างขึ้น

หากคุณสามารถโน้มน้าวให้ทีม Scrum ของคุณเพิ่มส่วนคำสั่ง Definition Of Done ในการพัฒนาการทดสอบหน่วยสำหรับแต่ละรหัสใหม่ที่สร้างขึ้นภายใน Sprint จากมุมมองระยะยาว นี่จะเป็นความสำเร็จที่ยิ่งใหญ่

เหตุผลค่อนข้างชัดเจน:

มันจะบังคับให้นักพัฒนาคิดเกี่ยวกับเส้นทางที่ไม่ได้มาตรฐานต่างๆ ของโค้ด –

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

สิ่งสำคัญที่สุดคือการเริ่มต้นเร็ว ๆ นี้ ยิ่งภายหลังการทดสอบหน่วยจะเริ่มพัฒนา ผู้พัฒนาจะเพิ่มสิ่งเหล่านั้นลงใน Sprint จะทำให้เสียสมาธิมากขึ้น

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

#2. ทำกิจวัตรในการดำเนินการทุกส่วนของ Unit Tests ในสภาพแวดล้อมการพัฒนา

แม้กระทั่งก่อนที่จะสร้างคำขอดึงสำหรับการรวมรหัสใหม่เข้ากับสาขาหลัก มันจะเป็นกิจกรรมมาตรฐานในการทดสอบทั้งรหัสคุณสมบัติและรหัสการทดสอบหน่วยในสภาพแวดล้อม dev การทำเช่นนี้จะทำให้มั่นใจได้ว่า:

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

#3. คาดหวังการดำเนินการทดสอบหน่วยหลังจากรวมรหัสเข้ากับสาขาหลัก

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

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

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

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

ตอนนี้ สามารถข้ามขั้นตอนนี้ได้ในกรณีเฉพาะ:

• การทดสอบหน่วยอัตโนมัติในไปป์ไลน์ DevOps นั้นครอบคลุมมากจนครอบคลุมการทดสอบด้วยตนเองทั้งหมดที่ดำเนินการนอกเหนือจากนั้นแล้ว

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

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

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

จะทำการตรวจสอบขั้นสุดท้ายสำหรับความพร้อมของสาขาหลักสำหรับขั้นตอนการทดสอบการเปิดตัว นอกจากนี้ ยังช่วยในการค้นหาจุดบกพร่องทางเทคนิคส่วนใหญ่ (เช่น จุดบกพร่องที่ทำให้ไม่สามารถดำเนินการซอร์สโค้ดได้สำเร็จจนกว่าจะสิ้นสุดการทำงานที่ประสบความสำเร็จ) ปล่อยให้ขั้นตอนต่อไปมุ่งเน้นไปที่การตรวจสอบฟังก์ชันการทำงานของธุรกิจเพียงอย่างเดียว

เตรียมพร้อมสำหรับการทดสอบการทำงาน

กิจกรรมการทดสอบก่อนหน้านี้ทั้งหมดจะนำไปสู่ข้อสรุปหนึ่งเดียว – โค้ดสาขาหลักปราศจากข้อผิดพลาดทางเทคนิคและดำเนินการได้โดยไม่มีปัญหาสำหรับโฟลว์การทำงานแบบ end-to-end

นี่เป็นช่วงที่สามารถครอบคลุมได้ง่ายเพียงแค่คนเดียว และบุคคลนี้ไม่จำเป็นต้องมีพื้นฐานทางเทคนิคด้วยซ้ำ

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

#1. เรื่องราวการวิ่งใหม่ที่กำหนดเป้าหมายการทดสอบการทำงาน

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

ช่างเป็นประสบการณ์ที่น่าเศร้าเมื่อในที่สุดฟังก์ชั่นที่สัญญาไว้ (ยาว) ได้รับการประกาศให้เปิดตัว เพียงเพื่อจะพบว่าวันก่อนมันใช้งานไม่ได้จริง ๆ

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

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

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

ด้วยวิธีนี้ นักพัฒนาจะใช้เวลาน้อยที่สุดในการทดสอบการทำงานและยังสามารถมีสมาธิกับกิจกรรมที่พวกเขาชอบมากที่สุดได้

#2. การดำเนินการกรณีทดสอบการถดถอย

ส่วนอื่น ๆ ของการทดสอบการทำงานจะต้องทำให้แน่ใจว่าทุกอย่างที่ใช้งานได้จนถึงตอนนี้จะทำงานหลังจากรุ่นถัดไป นี่คือสิ่งที่ใช้ทดสอบการถดถอย

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

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

ในบางกรณี การทดสอบการถดถอยยังครอบคลุมถึงคุณสมบัติใหม่ใน sprint โดยปริยาย เช่น ถ้าเรื่องราวใหม่ใน sprint กำลังเปลี่ยนแปลงบางส่วนของโฟลว์ที่มีอยู่

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

ยืนยันในการดำเนินการทดสอบการประกันคุณภาพก่อนการเปิดตัวการผลิตทุกครั้ง

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

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

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

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

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

ต่อจากนี้จะไปที่ไหน?

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

แต่แน่นอนว่าคุณไม่จำเป็นต้องหยุดที่นี่

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

การเลื่อนระดับขึ้นไปหนึ่งระดับยังหมายถึงการแนะนำการทดสอบอัตโนมัติอีกด้วย

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

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