การทดสอบอัตโนมัติ: การอธิบายคุณค่าทางธุรกิจ

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

ต่อไปนี้เป็นรายการที่ฉันระบุฉันกำลังมองหาคำตอบที่ช่วยขยายหรือปรับแต่ง:

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

ความคิดของฉัน:

1. ซื่อสัตย์ที่การเขียนการทดสอบอัตโนมัติจะใช้เวลามากขึ้น หากคุณกำลังทำระดับหน่วย TDD (ซึ่งฉันอยากจะแนะนำให้เป็นจุดเริ่มต้นถ้าคุณจะลงทุนในการทดสอบอัตโนมัติ) คุณสามารถคาดหวังเวลาเพิ่มอีกประมาณ 30% ที่จำเป็นในการเขียนโค้ดฟีเจอร์ กุญแจสำคัญในที่นี้คือการอธิบายว่าพิเศษนี้ 30% (ซึ่งอาจสูงกว่า 30% ในตอนเริ่มต้นเนื่องจากทีมของคุณเรียนรู้วิธีการเขียนการทดสอบที่ดี) เป็นการลงทุนที่สร้างขึ้นเพื่อประหยัดค่าใช้จ่ายเมื่อเวลาผ่านไป อย่างน้อยที่สุดกับระดับหน่วย TDD การออกแบบระบบของคุณนั้นมีการเชื่อมโยงอย่างแน่นหนาและเหนียวแน่นซึ่งทำให้ระบบของคุณสามารถปรับเปลี่ยนได้ตลอดเวลา ข้อกำหนดใหม่และข้อบกพร่องที่ไม่คาดคิดต้องการการเปลี่ยนแปลงระบบของคุณเสมอ
2. มีการถกเถียงกันมากมายเกี่ยวกับค่าของระดับการยอมรับและการทดสอบระดับ UI ที่กำหนดเวลาที่ใช้ในการเขียนการทดสอบเหล่านี้ใช้เวลานานแค่ไหนในการรันและการบำรุงรักษาที่ต้องการ ฉันขอแนะนำให้อ่านบทความนี้โดย James Shore เกี่ยวกับเรื่องนี้
3. ในโลกของการทดสอบอัตโนมัติมีวิธีที่ดีและวิธีที่ไม่ดีที่จะทำ หากคุณทอยการทดสอบอัตโนมัติกับผู้บริหารของคุณฉันจะลองดูว่าคุณวางแผนให้ทีมของคุณฝึกฝนการเขียนการทดสอบที่ดีอย่างไร ศิลปะการทดสอบหน่วยโดย Roy Osherove การทำงานอย่างมีประสิทธิภาพด้วยรหัสมรดกโดย Michael Feathers และศิลปะการพัฒนา Agile โดย James Shore เป็นหนังสือที่ยอดเยี่ยมทั้งหมดที่จัดการกับหัวข้อเหล่านี้โดยตรงหรือโดยอ้อม คุณควรพิจารณาโค้ชหรือการฝึกซ้อมอย่างเป็นทางการด้วยเช่นกัน มันเป็นการเปลี่ยนแปลงครั้งใหญ่
4. ในแง่ของมูลค่าทางธุรกิจจุดที่ 2 และ # 3 ของคุณด้านบนให้บริการจุดแรกของคุณดังนั้นฉันจะทุบจุดที่ # 1 และพูดคุยเกี่ยวกับวิธีที่ # 2 และ # 3 ให้บริการจุดที่ยิ่งใหญ่กว่านั้น เอกสารทำให้ระบบของคุณเข้าใจได้มากขึ้นซึ่งทำให้ทีมของคุณทำงานได้เร็วขึ้น คุณภาพรหัสทำให้ระบบของคุณสามารถปรับเปลี่ยนได้ซึ่งทำให้ทีมของคุณทำงานได้เร็วขึ้น สำหรับนักธุรกิจทุกอย่างจะเกี่ยวกับการเพิ่มการไหลเวียนของมูลค่าจากเวลาที่ความคิดถูกส่งไปยังเวลาที่ความคิดถูกส่งเป็นซอฟต์แวร์ที่ใช้งานได้

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

ค่าใช้จ่ายในการทดสอบ

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

ทดสอบความน่าเชื่อถือ

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

โหมดการทดสอบความล้มเหลวของคอมพิวเตอร์นั้นปรากฏชัดเจนมากขึ้นด้วย - มันล้มเหลว (รายงานทดสอบหยุดปรากฏ) มีข้อผิดพลาดเล็กน้อยที่ทำให้เกิดผลการทดสอบที่ผิดพลาด (รันการทดสอบที่กำหนดอีกครั้งและผลลัพธ์จะแตกต่างกัน) หากมนุษย์พลาดขั้นตอนและตรวจสอบ "ตกลง" เราจะบอกได้อย่างไร

ทดสอบความทนทาน

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

ค่าทดสอบ

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

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

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

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

นอกจากนี้ยังมีจุดของบูรณาการอย่างต่อเนื่อง

อีกอย่างหนึ่งต้องมุ่งมั่นที่คุณภาพของรหัสนำไปสู่คุณภาพของผลิตภัณฑ์มูลค่าทางธุรกิจและการบำรุงรักษา - มิฉะนั้นจะไม่มีประโยชน์ในการทำ

ฉันคิดว่าคุณควรเป็นผู้นำด้วยคะแนนมหัศจรรย์ของ "ต้นทุนที่ต่ำ" และ "คุณสมบัติเพิ่มเติม / หน่วยเวลา" / รอบเวลาที่สั้นลง

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

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

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

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

พื้นที่ที่ฉันคิดว่าอาจจะมีโชคขาย

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

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

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

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

5. การสร้างอัตโนมัติมักจะเน้นเมื่อมีคนลืมรหัสเช็คอิน

6. การทดสอบช่วยให้คุณหลีกเลี่ยงข้อผิดพลาดที่ปรากฏขึ้นอีก

7. การทดสอบหน่วยและการเยาะเย้ยที่เหมาะสมจะหมายถึงรหัสที่เชื่อมโยงกันน้อยลงและจะแก้ไขได้ง่ายขึ้น

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

บางคนต้องเชื่อว่ามีปัญหาก่อนที่พวกเขาจะยอมรับวิธีแก้ไขปัญหาที่เสนอ

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

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

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

หากมีโครงการดั้งเดิมการทดสอบอัตโนมัติทำให้สามารถปรับโครงสร้างได้ง่ายขึ้น จะต้องชำระหนี้ทางเทคนิคในบางช่วง

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

"สิ่งที่ฉันต้องการความช่วยเหลือคือการสื่อสารถึงคุณค่าของทีมโปรแกรมเมอร์นักวิเคราะห์ผู้จัดการและผู้ทดสอบโดยการทดสอบอัตโนมัติฉันไม่คิดว่าฉันต้องแยกความแตกต่างระหว่างการทดสอบหน่วย (เช่น JUnit), BDD ( เช่น JBehave, Fitness) และ UI (Selenium, Watir) เพราะฉันคิดว่าพวกเขาทุกคนให้คุณค่าที่คล้ายกัน (แต่อย่าลังเลที่จะเขียนคำตอบที่ไม่เห็นด้วย :)) "

ตกลงฉันจะใช้ความท้าทายนั้น)

ฉันส่วนใหญ่ทำงานกับโปรแกรมเมอร์และควบคุมคุณภาพและเครื่องมือของฉันคือ ruby, rails, testunit, rspec, jasmine และ selenium

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

GUI / UI / จัสมิน / ซีลีเนียม เหล่านี้แตกต่างกัน ฉันทำสิ่งเหล่านี้โดย QA folks ที่มีภูมิหลังโปรแกรมเมอร์ เราตรวจสอบให้แน่ใจว่าการทดสอบถูกเขียนให้มีความแข็งแกร่งเท่าที่จะเป็นไปได้และขึ้นอยู่กับเนื้อหาที่ไม่ได้ออกแบบ ค่าใช้จ่าย (อาจจะใหม่) นี้ควรได้รับการอธิบายว่าเป็นค่าใช้จ่ายขยับ แทนที่จะจ่ายด้วยซอฟต์แวร์ที่ใช้งานไม่ได้ลูกค้าหายไปและการแก้ไขที่มีราคาแพงในภายหลังคุณต้องจ่ายน้อยลง (ค่อนข้างมาก) ด้วยวิธีปฏิบัติง่ายๆสองสามข้อ

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

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

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

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

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