เหตุใดคู่มือการแย่งชิงจึงไม่บอกผู้ทดสอบ

ฉันได้อ่านคู่มือการแย่งชิงกันจาก scrum.org และมันบอกว่า:

ทีมพัฒนาไม่ได้มีทีมย่อยสำหรับโดเมนเฉพาะเช่นการทดสอบหรือการวิเคราะห์ธุรกิจ

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

มันหมายความว่าอย่างใดอย่างหนึ่ง:

1. ผู้ทดสอบได้รวมเข้ากับเครื่องมือสร้างทีมพัฒนาเพื่อช่วยให้นักพัฒนาทดสอบและทดสอบ

   หรือ:

2. ทีมปฏิบัติพัฒนาการทดสอบขับเคลื่อน - เช่นพวกเขาเขียนการทดสอบอัตโนมัติที่ใช้ระบบ

อย่างใดอย่างหนึ่งเหล่านี้หมายความว่าไม่จำเป็นต้องมีทีมทดสอบแยกต่างหาก

ในการแปลตามตัวอักษรนี่หมายความว่าไม่มีผู้ทดสอบที่สับสน ... พวกเขาจะแนะนำสิ่งนี้ได้อย่างไร

ใช่นี้เป็นว่าสิ่งที่พวกเขาแนะนำ กล่าวอีกนัยหนึ่ง - นักพัฒนาคือผู้ทดสอบและผู้ทดสอบคือผู้พัฒนา

ความคิดที่จะเป็นเจ้าของรหัสอุปถัมภ์และมีคุณภาพ

นี่ไม่ได้หมายความว่ารหัสนั้นไม่ได้ทดสอบ แต่คนที่เกี่ยวข้องในการเขียนนั้นเป็นคนที่มีส่วนร่วมในการทดสอบ - ไม่มีการแบ่งแยกหน้าที่

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

ส่วนพื้นฐานของเรื่องนี้ก็คือความรับผิดชอบของนักเขียนโค้ดคือการสร้างรหัสที่ทำงานและเติมเต็มความต้องการ สิ่งนี้ต้องใช้ความคิดเฉพาะ - "รหัสที่ฉันกำลังเขียนทำในสิ่งที่ควรทำ"

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

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

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

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

• Coder / QA - "รหัสทำงานได้อย่างสมบูรณ์แบบและฉันได้เขียนโค้ดเพื่อจัดการทุกวิธีที่เป็นไปได้ที่ฉันสามารถคิดได้
• รหัส / BA - "รหัสควรทำงานในแบบที่ฉันต้องการและสิ่งเหล่านี้จะเป็นระเบียบเพื่อเพิ่มไปยังที่ลูกค้าไม่ได้คิด

นี่ไม่ใช่การบอกว่า coder ทุกตัวมีความอ่อนไหวต่อปัญหาเหล่านี้ (ฉันได้พบกับ coder / QA ที่มีพรสวรรค์มากบางอย่าง ... แม้ว่าจะไม่ใช่รหัสที่เขียน)

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

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

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

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

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

นอกจากนี้ยังมีการพูดคุยอย่าง จำกัด เกี่ยวกับบทบาทใน Scrum Guide ในความเป็นจริงพวกเขาพูดคุยเกี่ยวกับทีมพัฒนา สิ่งที่พวกเขาหมายถึงคือคุณต้องการทีมข้ามสายงานที่แข็งแกร่ง ซึ่งหมายความว่าขึ้นอยู่กับสิ่งที่โครงการของคุณต้องการคุณจำเป็นต้องมีทักษะที่หลากหลายเช่น UX, BA, QA / Tester, Ops, Coder ฯลฯ ฯลฯ แต่ไม่ว่าจะเป็นบุคคลหนึ่งหรือหลายคนที่ครอบคลุมสิ่งเหล่านี้

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

ไม่ได้แปลว่าไม่มีผู้ทดสอบ อาจเป็นกรณีที่ทีมการต่อสู้ได้ทำการทดสอบหรือไม่

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

1. มีการประมาณการเดียวในเรื่อง / ข้อบกพร่อง / งาน ไม่มีการประมาณค่า dev และการประเมินผลการทดสอบ
2. ทีมไม่คาดการณ์เรื่องราวใด ๆ
3. หากมีสิ่งใดผิดพลาดก็ไม่ใช่ความผิดของผู้ทดสอบมากกว่าความผิดของผู้พัฒนา มันเป็นความผิดของทีม
4. ทีมไม่จำเป็นต้องยืมร้องขอหรือขอทดสอบ
5. การทดสอบเป็นส่วนหนึ่งของคำนิยามของการทำ งานที่ยังไม่ทดลองนั้นเป็นงานที่ไม่สมบูรณ์
6. นักพัฒนาควรพิจารณาความสามารถในการทดสอบได้ขณะออกแบบรหัส

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

สัญญาณบ่งชี้ว่าคุณไม่อาจถือว่าผู้ทดสอบเป็นส่วนหนึ่งของทีมจัดส่งแม้ว่าคุณคิดว่าคุณทำ:

1. ผู้ทดสอบมี "QA standup" (ใช่ฉันเคยเห็นมาแล้ว)
2. ผู้ทดสอบมีโครงสร้างการจัดการแยกจากกัน
3. คุณมีหัวหน้า QA
4. คุณต้องพึ่งพาการทดสอบแบบครบวงจรเป็นอย่างมาก
5. การทดสอบจะได้รับการเขียนวิ่งต่อไปนี้
6. การทดสอบส่วนใหญ่เกิดขึ้นในวันสุดท้ายของการวิ่ง

สิ่งเหล่านี้เป็นอัตนัยและไม่จำเป็นต้องผิด พวกเขาเป็นธงสีแดง แต่ในความคิดของฉัน

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