อัปเดตเมื่อ August 28, 2019
การทดสอบได้รับการยอมรับอย่างกว้างขวางว่าเป็นส่วนหนึ่งของการพัฒนาซอฟต์แวร์นับตั้งแต่มีการพัฒนาซอฟต์แวร์ อย่างไรก็ตาม Business Intelligence (BI) ใช้การทดสอบเป็นส่วนหนึ่งของการพัฒนาซอฟต์แวร์ BI เช่น IBM Cognos ได้ช้ากว่า มาสำรวจกันว่าทำไม BI จึงนำแนวปฏิบัติการทดสอบมาใช้และผลที่ตามมาของ . ช้าลง ไม่ การทดสอบ
ทำไมองค์กรไม่ทดสอบ BI...
- ข้อจำกัดด้านเวลา. โครงการ BI อยู่ภายใต้แรงกดดันอย่างต่อเนื่องที่จะต้องจัดส่งให้เร็วขึ้น สิ่งที่บางองค์กรอาจไม่ทราบก็คือขั้นตอนที่ง่ายที่สุดในการลดเวลาคือการทดสอบ
- ข้อ จำกัด ด้านงบประมาณ. ความคิดคือการทดสอบมีราคาแพงเกินไปและไม่สามารถอุทิศทีมทดสอบได้
- เร็วกว่าดีกว่า. วิธีนี้ไม่จำเป็นต้องเป็นแนวทางที่ "คล่องตัว" และอาจทำให้คุณไปผิดที่เร็วขึ้นเท่านั้น
- คติประจำใจ "แค่ทำให้ถูกต้องในครั้งแรก". แนวทางที่ไร้เดียงสานี้ยืนยันว่าการควบคุมคุณภาพจะช่วยลดความจำเป็นในการทดสอบลงได้
- ขาดความเป็นเจ้าของ. ซึ่งคล้ายกับสัญลักษณ์แสดงหัวข้อย่อยก่อนหน้า ความคิดก็คือ "ผู้ใช้ของเราจะทดสอบมัน" วิธีการนี้สามารถนำไปสู่ผู้ใช้ที่ไม่พอใจและตั๋วสนับสนุนจำนวนมาก
- ขาดเครื่องมือ. ความเข้าใจผิดว่าไม่มีเทคโนโลยีที่เหมาะสมสำหรับการทดสอบ
- ขาดความเข้าใจในการทดสอบ. ตัวอย่างเช่น,
- การทดสอบควรประเมินความถูกต้องและความถูกต้องของข้อมูล ความสอดคล้องของข้อมูล ความตรงต่อเวลาของข้อมูล ประสิทธิภาพของการจัดส่ง และความง่ายในการใช้กลไกการจัดส่ง
- การทดสอบระหว่างโครงการ BI อาจรวมถึงการทดสอบการถดถอย การทดสอบหน่วย การทดสอบควัน การทดสอบการรวม การทดสอบการยอมรับของผู้ใช้ การทดสอบเฉพาะกิจ การทดสอบความเครียด/ความสามารถในการขยาย การทดสอบประสิทธิภาพของระบบ
ค่าใช้จ่ายของการไม่ทดสอบ BI คืออะไร?
- การออกแบบที่ไม่มีประสิทธิภาพ. สถาปัตยกรรมที่ไม่ดีอาจไม่ถูกค้นพบหากละเลยการทดสอบ ปัญหาด้านการออกแบบอาจส่งผลต่อความสามารถในการใช้งาน ประสิทธิภาพ การนำกลับมาใช้ใหม่ ตลอดจนการบำรุงรักษาและการบำรุงรักษา
- ปัญหาความสมบูรณ์ของข้อมูล. การทุจริตของข้อมูลหรือความท้าทายในสายข้อมูลอาจนำไปสู่การขาดความเชื่อถือในตัวเลข
- ปัญหาการตรวจสอบข้อมูล. การตัดสินใจเกี่ยวกับข้อมูลที่ไม่ดีอาจส่งผลเสียต่อธุรกิจ ไม่มีอะไรเลวร้ายไปกว่าการพยายามจัดการด้วยเมตริกที่อิงจากข้อมูลที่ไม่ถูกต้อง
- การยอมรับของผู้ใช้ลดลง. หากตัวเลขไม่ถูกต้อง หรือหากแอปพลิเคชันไม่เป็นมิตรกับผู้ใช้ ชุมชนผู้ใช้ของคุณจะไม่ใช้ซอฟต์แวร์ BI ระดับองค์กรตัวใหม่ของคุณ
- ต้นทุนเพิ่มขึ้นเนื่องจากขาดมาตรฐาน.
- ค่าใช้จ่ายในการซ่อมแซมข้อบกพร่องในระยะต่อมาของวงจรชีวิตการพัฒนา BI. ปัญหาใดๆ ที่ค้นพบนอกเหนือจากระยะข้อกำหนดจะมีค่าใช้จ่ายเพิ่มขึ้นอย่างทวีคูณมากกว่าที่พบก่อนหน้านี้
ตอนนี้เราได้อธิบายเหตุผลที่องค์กรอาจไม่ทำการทดสอบและข้อผิดพลาดที่เกิดขึ้นเมื่อคุณไม่ทดสอบ BI มาดูการศึกษาเกี่ยวกับการทดสอบในการพัฒนาซอฟต์แวร์กันบ้าง
การศึกษาแสดงการทดสอบแพลตฟอร์ม BI ของคุณประหยัดเงิน!
หนึ่งการศึกษาของบริษัทในอเมริกาเหนือ 139 แห่ง มีพนักงานตั้งแต่ 250 ถึง 10,000 คน รายงานต้นทุนการดีบักประจำปีที่ 5.2 ล้านดอลลาร์ถึง 22 ล้านดอลลาร์ ช่วงค่าใช้จ่ายนี้สะท้อนถึงองค์กรที่ อย่า มีการทดสอบหน่วยอัตโนมัติในสถานที่ แยกจากกัน การวิจัยโดย IBM และ Microsoft พบว่า กับ การทดสอบหน่วยอัตโนมัติในสถานที่ จำนวนข้อบกพร่องสามารถลดลงระหว่าง 62% ถึง 91%. ซึ่งหมายความว่าดอลลาร์ที่ใช้ไปกับการแก้ไขจุดบกพร่องอาจลดลงจากช่วง $5M – $22M เป็น $0.5M ถึง $8.4M นั่นเป็นเงินออมที่มหาศาล!
ค่าใช้จ่ายในการแก้ไขข้อผิดพลาดเพิ่มขึ้นอย่างรวดเร็ว
บทความเกี่ยวกับกลยุทธ์การพัฒนาซอฟต์แวร์ที่ประสบความสำเร็จ แสดงให้เห็นว่าข้อผิดพลาดส่วนใหญ่เกิดขึ้นตั้งแต่เนิ่นๆ ของวงจรการพัฒนา และยิ่งคุณรอตรวจจับและแก้ไขนานเท่าใด ค่าใช้จ่ายในการแก้ไขก็จะสูงขึ้นเท่านั้น ดังนั้นจึงไม่จำเป็นต้องใช้นักวิทยาศาสตร์จรวดเพื่อสรุปที่ชัดเจนว่ายิ่งค้นพบและแก้ไขข้อผิดพลาดได้เร็วเท่าไหร่ก็ยิ่งดีเท่านั้น เมื่อพูดถึงวิทยาศาสตร์จรวด นาซาได้ตีพิมพ์บทความเรื่องนั้น - “ข้อผิดพลาดในการยกระดับต้นทุนผ่านวงจรชีวิตโครงการ”
เป็นเรื่องง่ายที่ค่าใช้จ่ายในการแก้ไขข้อผิดพลาดเพิ่มขึ้นเมื่อวงจรชีวิตการพัฒนาดำเนินไป การศึกษาของ NASA ดำเนินการเพื่อพิจารณาว่าค่าใช้จ่ายในการแก้ไขข้อผิดพลาดที่ค้นพบนั้นคืบหน้าได้เร็วเพียงใด การศึกษานี้ใช้สามวิธีในการพิจารณาต้นทุนสัมพัทธ์ ได้แก่ วิธีต้นทุนจากล่างขึ้นบน วิธีแบ่งต้นทุนทั้งหมด และวิธีการโครงการตามสมมติฐานจากบนลงล่าง แนวทางและผลลัพธ์ที่อธิบายในเอกสารนี้สันนิษฐานว่าการพัฒนาระบบฮาร์ดแวร์/ซอฟต์แวร์ที่มีลักษณะโครงการคล้ายกับที่ใช้ในการพัฒนายานอวกาศขนาดใหญ่ที่ซับซ้อน เครื่องบินทหาร หรือดาวเทียมสื่อสารขนาดเล็ก ผลลัพธ์แสดงระดับที่ต้นทุนบานปลาย เนื่องจากมีการค้นพบข้อผิดพลาดและแก้ไขข้อผิดพลาดในระยะต่อมาและภายหลังในวงจรชีวิตของโครงการ การศึกษานี้เป็นตัวแทนของงานวิจัยอื่นๆ ที่ได้ทำไปแล้ว
จากแผนภูมิด้านบน การวิจัยจาก TRW, IBM, GTE, Bell Labs, TDC และอื่นๆ แสดงค่าใช้จ่ายในการแก้ไขข้อผิดพลาดในระหว่างขั้นตอนการพัฒนาต่างๆ:
- ค่าใช้จ่ายในการแก้ไขข้อผิดพลาดที่พบระหว่างขั้นตอนความต้องการถูกกำหนดเป็น หน่วย 1
- ค่าใช้จ่ายในการแก้ไขข้อผิดพลาดนั้นหากพบในระหว่างขั้นตอนการออกแบบคือ สอง ที่
- ที่โค้ดและเฟสดีบั๊ก ค่าใช้จ่ายในการแก้ไขข้อผิดพลาดคือ หน่วย 3
- ที่ขั้นตอนการทดสอบหน่วยและการรวม ค่าใช้จ่ายในการแก้ไขข้อผิดพลาดจะกลายเป็น 5
- ที่ขั้นตอนการทดสอบระบบ ค่าใช้จ่ายในการแก้ไขข้อผิดพลาดเพิ่มขึ้นเป็น20
- และเมื่อระบบอยู่ในขั้นตอนการทำงาน ค่าใช้จ่ายสัมพัทธ์ในการแก้ไขข้อผิดพลาดเพิ่มขึ้นเป็น 98 เกือบ 100 เท่าของค่าใช้จ่ายในการแก้ไขข้อผิดพลาดหากพบในขั้นตอนความต้องการ!
สิ่งที่สำคัญที่สุดคือการซ่อมแซมข้อบกพร่องนั้นมีราคาแพงกว่ามากหากไม่ถูกจับได้ตั้งแต่เนิ่นๆ
สรุป
มีการวิจัยที่สำคัญซึ่งแสดงให้เห็นถึงคุณค่าของการทดสอบในช่วงต้นและต่อเนื่องในการพัฒนาซอฟต์แวร์ เรา ในชุมชน BI สามารถเรียนรู้จากเพื่อนของเราในการพัฒนาซอฟต์แวร์ แม้ว่าการวิจัยอย่างเป็นทางการส่วนใหญ่เกี่ยวกับการพัฒนาซอฟต์แวร์แล้ว ก็สามารถสรุปผลที่คล้ายกันเกี่ยวกับการพัฒนา BI ได้ คุณค่าของการทดสอบนั้นไม่อาจโต้แย้งได้ แต่องค์กรจำนวนมากได้ช้ากว่าที่จะใช้ประโยชน์จากการทดสอบสภาพแวดล้อม BI อย่างเป็นทางการและรวมการทดสอบเข้ากับกระบวนการพัฒนา BI ของพวกเขา ค่าใช้จ่ายของ ไม่ การทดสอบเป็นจริง ความเสี่ยงที่เกี่ยวข้องกับ ไม่ การทดสอบเป็นจริง
ต้องการดูการทดสอบ Cognos แบบอัตโนมัติในการดำเนินการหรือไม่ ชมวิดีโอในเพลย์ลิสต์ของเราโดย คลิกที่นี่!
