การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ - ใครควรเขียนการทดสอบ

เดิมทีมันเป็นหน้าที่ของนักพัฒนาในการเขียนการทดสอบ แต่ฉันสังเกตเห็นว่าในหลายกรณี / นักพัฒนา e-mature กรณีเหล่านั้นจะไม่ให้ความคุ้มครองถึง 80%
ฉันมีคน QA ที่ทุ่มเทให้กับการเขียนการทดสอบทั้งหมดสำหรับโครงการที่กำหนดแทนที่จะเป็นนักพัฒนาได้อย่างไร
มีข้อเสียใด ๆ หรือไม่?

ในการพัฒนาทดสอบขับเคลื่อนการทดสอบจะต้องเขียนโดยนักพัฒนา มิฉะนั้นคนอื่นที่ไม่ใช่นักพัฒนากำลังผลักดันการพัฒนา

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

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

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

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

สุดท้าย แต่ไม่ท้ายสุดใน 'บริสุทธิ์' TTD ไม่ควรมีการเปิดเผยรหัสเลย (เนื่องจากคุณเขียนการทดสอบก่อน) อย่างไรก็ตามมีหลายกรณี (แม้ว่าผู้คนจะโต้แย้งกัน) ซึ่งการยอมรับโค้ดที่ต่ำกว่านั้นเป็นที่ยอมรับ บางคนโต้แย้งว่าการเขียนแบบทดสอบสำหรับผู้ได้รับ / setters ของ POJO นั้นเสียเวลา

กรณีเหล่านี้ไม่ได้ให้ความคุ้มครองถึง 80%

นั่นอาจเป็นปัญหาการจัดการ

หรืออาจไม่เกี่ยวข้อง

ก่อนอื่นความแตกต่างระหว่าง 80% และ 100% ความคุ้มครองน่าจะคุ้มค่ามากสำหรับผลประโยชน์ที่น้อยมาก

"ความคุ้มครอง" อาจหมายถึงอะไรก็ได้ บรรทัดของรหัสเส้นทางตรรกะ ฯลฯ ฉันเดาคุณหมายถึงบรรทัดของรหัส (ไม่ใช่เส้นทางตรรกะ)

เส้นทางตรรกะบางแห่งผ่านการทดสอบอย่างดี "โดยการตรวจสอบ" รหัสนั้นชัดเจนไม่มีคำสั่งใด ๆ มีความซับซ้อนต่ำมากและอาจไม่ต้องการการทดสอบเพิ่มเติม

การทดสอบเพิ่มขึ้น 20% นั้นไม่ใช่การเพิ่มคุณภาพอีก 20% เสมอไป

ที่สอง มันเป็นปัญหาการจัดการ หากฝ่ายบริหารต้องการความคุ้มครอง 100% พวกเขาจะต้องวางระบบการให้รางวัลแทนการให้ความคุ้มครอง 100% แทนที่จะ "ดีพอที่จะปล่อย" ความคุ้มครอง 80%

การเพิ่มผู้ควบคุมคุณภาพเพื่อเขียนการทดสอบเพิ่มเติมจะไม่ช่วยอะไร

การเพิ่มนักพัฒนาเพื่อเขียนการทดสอบเพิ่มเติมคือสิ่งที่จำเป็นสำหรับการครอบคลุมการทดสอบถึง 100%

IMHO การทดสอบหน่วยไม่ใช่กระบวนการ QA มันเพิ่มเติมเกี่ยวกับการเร่งการพัฒนา (โดยการลดขนาดวนการย้อนกลับของฟีดสำหรับนักพัฒนา) มันควรจะทำโดยคนที่เขียนส่วนประกอบ (หน่วย aka) โดยมุ่งเน้นที่การใช้ส่วนประกอบ (โดยนักพัฒนาอื่น)

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

ทั้งสองสามารถทำได้ในรูปแบบ TDD

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

คุณควรทราบด้วยว่าความครอบคลุมจะไม่บอกคุณเกี่ยวกับคุณภาพของรหัสและจะไม่บอกคุณว่าจะครอบคลุมกฎของโดเมนหรือไม่

หากคุณต้องการความคุ้มครองอย่างน้อย 80% คุณต้องทำสองสิ่ง:

• ให้เครื่องมือที่พวกเขาต้องการเพื่อพัฒนาระดับการครอบคลุมที่พวกเขามี - และตรวจสอบให้แน่ใจว่าแอปเปิ้ลเป็นแอปเปิ้ล มีวิธีการวัดความครอบคลุมมากกว่าหนึ่งวิธี
• ให้รางวัล / สิ่งจูงใจเพื่อให้บรรลุเป้าหมายนั้น โปรแกรมเมอร์เท่านั้นที่จะทำสิ่งที่พวกเขารู้สึกว่าจะจ่าย หากความคุ้มครอง 50% นั้นดีพอที่จะรับประกันคุณภาพและทำงานให้เสร็จนั่นคือสิ่งที่พวกเขาจะทำ

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

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