คุณโน้มน้าวผู้จัดการของคุณให้ทดสอบหน่วยได้อย่างไร

โดย "ใช้" ฉันหมายถึงได้รับอนุญาตให้พัฒนาเช็คอินเพื่อควบคุมแหล่งที่มาและรักษาการทดสอบหน่วยในช่วงเวลาอื่น ๆ

การคัดค้านการจัดการทั่วไปคือ:

1. ลูกค้าไม่ได้ชำระเงินสำหรับการทดสอบหน่วย
2. โครงการไม่อนุญาตให้มีเวลาสำหรับการทดสอบหน่วย
3. หนี้ทางเทคนิค? หนี้สินทางเทคนิคคืออะไร

คุณรู้จักคำคัดค้านอื่น ๆ หรือไม่? คุณมีคำตอบอะไร

ขอบคุณล่วงหน้า!

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

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

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

ข้อสรุปของฉันจากประสบการณ์นี้คือ:

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

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

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

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

แสดงผลตอบแทนการลงทุน (ROI)

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

ตัวอย่าง: คุณสมบัติการทดสอบด้วยตนเอง X ใช้เวลา 30 นาที การเขียนการทดสอบอัตโนมัติจะใช้เวลา 1 ชั่วโมง แม้ว่าเราจะไม่มีข้อบกพร่องก็ตามเราจะต้องทดสอบฟีเจอร์ X สิบครั้งในระหว่างการทำโปรเจคเนื่องจากเลเยอร์และส่วนประกอบที่ขึ้นอยู่กับการแก้ไข ดังนั้นการทดสอบฟีเจอร์ X โดยอัตโนมัติจะช่วยเราได้ 4 ชั่วโมงตลอดอายุการใช้งานของโครงการ

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

ธุรกิจเข้าใจประหยัดเวลาและเงิน นั่นคือวิธีขายมัน

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

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

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

1) ลูกค้าไม่ได้ชำระเงินสำหรับการทดสอบหน่วย

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

2) โครงการไม่อนุญาตให้มีเวลาสำหรับ TDD

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

3) หนี้ทางเทคนิค? หนี้สินทางเทคนิคคืออะไร

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

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

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

สำหรับลูกค้าทุกคนที่ประสบปัญหาการผลิต

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

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

3. บอกเขาว่าถ้าเรามีการทดสอบหน่วยนี้แล้วก่อนที่รหัสจะเริ่มผลิตปัญหาการผลิตนี้จะไม่เกิดขึ้น

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