ความมีชีวิตของทีมพัฒนาที่ไม่มีหน้าที่ทดสอบ * เฉพาะ [ปิด]

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

จนถึงตอนนี้ฉันกำหนดทีมแบบลีนดังต่อไปนี้:

• เล็ก ๆ น้อย ๆ
• จัดการตนเอง;
• สมาชิกทุกคนจะต้องมีการควบคุมคุณภาพในใจ;
• สมาชิกจะต้องสามารถดำเนินการได้หลายบทบาท

จุดสุดท้ายคือที่ที่ฉันกังวลเล็กน้อยเพราะเมื่อมนต์ไป ...

นักพัฒนาทำการทดสอบที่ไม่ดี

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

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

โมเดลของฉันต้องการ:

• บ้านซอฟต์แวร์ขนาดเล็กที่มี 2+ โครงการ
• วิธี Agile (ซ้ำ) เพื่อการพัฒนาและการส่งมอบ
• 1 ทีมต่อโครงการ
• สมาชิกในทีมทั้งหมดจะเป็นนักพัฒนาซอฟต์แวร์
  • รายละเอียดงานของพวกเขาจะระบุอย่างชัดเจนการพัฒนา , การประกันคุณภาพ , การทดสอบและการจัดส่งสินค้าเป็นความรับผิดชอบ

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

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

จากที่กล่าวมาฉันเห็นข้อดีและข้อเสียดังต่อไปนี้:

ข้อดี

• กระจายความรู้โครงการทั่วทั้ง บริษัท
• มั่นใจว่าสมาชิกในทีมไม่ได้ทดสอบโค้ดที่พวกเขาช่วยเขียน
• รอบบทบาทนอกเฟสหมายความว่าโครงการจะไม่มีสวิตช์สมาชิก 100%
• บทบาทสลับแบ่งความน่าเบื่อของโครงการที่น่าเบื่อ

จุดด้อย

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

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

ดังนั้นคำถามของฉันคือ: แบบจำลองดังกล่าวสามารถใช้งานได้จริงหรือไม่? ถ้าไม่มันจะถูกดัดแปลงเป็นรูปแบบการทำงานหรือไม่?

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

ฉันไม่เห็นด้วย

นักพัฒนาทำการทดสอบที่ไม่ดี

ทีมส่วนใหญ่ที่ฉันทำงานในอาชีพของฉันไม่ได้รับการสนับสนุน QA ใด ๆ ซึ่งรวมถึง บริษัท ขนาดใหญ่ระดับโลกที่เกี่ยวข้องกับผลิตภัณฑ์เช่นระบบเข้าสู่ระบบทั่วโลกและระบบการลงทะเบียน ในอีกกรณีหนึ่งฉันมีรายได้ 30% ของ บริษัท วิ่งผ่านกล่องบนโต๊ะทำงาน (การปฏิบัติเหล่านี้ไม่แนะนำให้ใช้ BTW;) บริษัท เหล่านี้พึ่งพาวิศวกรเพื่อให้แน่ใจว่ารหัสของพวกเขาทำงานอย่างถูกต้อง และเราที่มุ่งเน้นในรายละเอียดเป็นเรื่องที่ต้องทำและภูมิใจในงานของเราจะต้องใช้ความพยายามอย่างมากเพื่อให้แน่ใจว่าซอฟต์แวร์ของเราทำงานได้อย่างถูกต้อง

นอกจากนี้ยังเป็นนักพัฒนาฉันมากมากขึ้นกว่าการทดสอบทดสอบ ฉันมักจะทดสอบโค้ดเป็น 90% หรือ 100% ถ้าฉันไม่ได้ทำงานกับ Java

ฉันชอบทำงานกับผู้ทดสอบเพราะพวกเขามาจากมุมมองที่แตกต่างและจับสิ่งที่ฉันไม่ได้คิด แต่ฉันไม่ได้หวังที่จะให้การทดสอบมากกว่า 30-50% ในขณะที่ฉันรับผิดชอบตัวเอง 100% (BTW นั่นไม่ใช่สแลมสำหรับพวกเขา - พวกเขามักจะกระจายทั่วโครงการ)

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

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

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

แต่ทีมส่วนใหญ่ที่ฉันทำงานโดยเฉพาะอย่างยิ่งสำหรับ บริษัท ขนาดเล็กยังไม่มีองค์ประกอบ QA ที่เป็นทางการ

ฉันเห็นด้วยกับคำตอบของ @Rob Y และต้องการเพิ่มบางจุด:

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

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

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

• การยั่วยุ: ใครบอกว่า QA นั้นดีกว่านักพัฒนาที่ QA-ing? มันเป็นสิ่งที่ผู้คนพูด แต่ ... [อ้างจำเป็น] ความคิด "แฮ็กเกอร์" ที่จำเป็นของ QA คือความคิดของนักพัฒนา ในความเป็นจริงแฮ็กเกอร์ทุกคนเป็นหรือเป็นนักพัฒนาไม่ใช่ QA ...

• การยั่วยุที่ 2: 99% ของงานควบคุมคุณภาพสามารถเป็น (และกล้าที่ฉันจะบอกว่าควร ) โดยอัตโนมัติผ่านสคริปต์ ทีมที่ดีจะทำสิ่งนี้และทำสิ่งนี้อย่างถูกต้องคุณต้อง ... นักพัฒนา

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

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

หากคุณเข้มงวดเกี่ยวกับมันสามารถทำงานได้ดีมาก มันทำเพื่อเรา - เรามีเวลาทำงานที่ยอดเยี่ยมและมีข้อบกพร่องน้อยในบริการเว็บอีคอมเมิร์ซตลอดเวลา

ข้อแรกข้อแรก - ฉันทำงานอย่างมืออาชีพทั้งในฐานะวิศวกรควบคุมคุณภาพและวิศวกรซอฟต์แวร์

แบบจำลองดังกล่าวสามารถใช้งานได้จริงหรือไม่?

อะไรก็เกิดขึ้นได้.

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

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

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

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

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

บางทีคุณอาจจะเจ๋งในแบบที่ฉันยังไม่เคยเจอ - แต่ฉันสงสัยมัน

ฉันคิดว่ามันสามารถใช้งานได้ แต่มีสองสิ่งที่ฉันจะทำให้แน่ใจว่าคุณทำ

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

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

แผนนี้ไม่อนุญาตให้ทีมจัดระเบียบตัวเองได้มากพอ กลยุทธ์หนึ่งอาจไม่เหมาะกับทุกทีมและทุกโครงการ