การใช้การทดสอบหน่วยใน บริษัท ที่ไม่ได้ทำ

หัวหน้าฝ่ายพัฒนาซอฟต์แวร์ของ บริษัท ของฉันเพิ่ง "ลาออก" (ถูกไล่ออก) และตอนนี้เรากำลังมองหาวิธีปรับปรุงการพัฒนาที่ บริษัท ของเรา เราต้องการนำการทดสอบหน่วยในซอฟต์แวร์ทั้งหมดที่สร้างจากที่นี่ออก

ข้อเสนอแนะจากนักพัฒนาคือ:

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

คำติชมจากประธานเจ้าหน้าที่บริหารคือ:

• ฉันต้องการให้ บริษัท ของเรามีการทดสอบอัตโนมัติ แต่ฉันไม่รู้ว่าจะทำให้มันเกิดขึ้นได้อย่างไร
• เราไม่มีเวลาเขียนเอกสารขนาดใหญ่

นักพัฒนาจะได้รับรายละเอียดในขณะนี้ได้อย่างไร เลื่อนคำจากปากหรือ PowerPoint เห็นได้ชัดว่าเป็นปัญหาใหญ่ คำแนะนำของฉันคือ:

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

ถ้าคุณเคยอยู่ใน บริษัท ที่อยู่ในสถานการณ์เช่นนี้คุณจะแก้ปัญหาอย่างไร วิธีนี้ดูสมเหตุสมผลหรือไม่?

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

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

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

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

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

ประสบการณ์ของฉันกับการเปลี่ยนแปลง

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

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

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

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

เปรียบเทียบและเปรียบเทียบสถานีทดลองสองแห่งที่ฉันสนับสนุน หนึ่งได้รับรอบในขณะที่และมีรหัสมรดกในขณะที่อื่น ๆ ค่อนข้างใหม่

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

ในห้องแล็บที่ใหม่กว่าฉันมักจะสามารถเพิ่มฟังก์ชั่นการใช้งานโดยการพัฒนาแบบออฟไลน์ที่โต๊ะทำงานของฉันเยาะเย้ยเฉพาะสิ่งที่จำเป็นต้องใช้ในทันทีและจากนั้นใช้เวลาสั้น ๆ ในห้องแล็บ -ไลน์.

คำแนะนำของฉัน

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

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

ฉันขอแนะนำให้เริ่มต้นเล็ก ๆ และใช้กฎลูกเสือ :

ออกจากที่ตั้งแคมป์สะอาดกว่าที่คุณพบ

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

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

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

สรุป

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

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

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

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

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

ฉันไม่คิดว่าสิ่งนี้จะเปลี่ยนไปในชั่วข้ามคืนหากคุณคุ้นเคยกับรายละเอียด 'คำพูดจากปาก' การต่อสู้จะเปลี่ยนพฤติกรรมนี้เกือบทั้งหมด - และคุณจะต้องต่อต้านสิ่งนี้ ผู้ใช้ (หรือ BA หรือ PM หรือใครก็ตาม) ที่ใช้ในการพูดว่า "เพียงแค่ทำให้ x" และตอนนี้ต้องเขียนมันทั้งหมดจะไม่ตอบสนองดีมีโอกาสที่พวกเขาจะเขียนเอกสารข้อมูลที่คลุมเครือและชี้แจงพวกเขา ด้วยการอัปเดตคำพูดจากปาก ดังนั้นลืมทดสอบหน่วยและเริ่มต้นปัญหาใหญ่ที่คุณมีกับวงจรการพัฒนา

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

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