ค่าใช้จ่ายของความล่าช้าอีกต่อไประหว่างการพัฒนาและ QA

ที่ตำแหน่งปัจจุบันของฉัน QA ได้กลายเป็นคอขวด เรามีการเกิดขึ้นของคุณสมบัติที่โชคร้ายจากการสร้างปัจจุบันเพื่อให้ QA สามารถทำการทดสอบให้เสร็จสิ้นได้ ซึ่งหมายความว่าฟีเจอร์ที่ได้รับการพัฒนาแล้วอาจไม่ได้รับการทดสอบเป็นเวลา 2-3 สัปดาห์หลังจากที่นักพัฒนาซอฟต์แวร์ได้ทำการพัฒนาต่อไป เมื่อ dev เคลื่อนที่ได้เร็วขึ้นและมีคุณภาพ QA ช่องว่างในเวลานี้จะยิ่งใหญ่ขึ้นเท่านั้น

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

คุณไม่ต้องการการอ้างอิงใด ๆ IMHO นี่คือสิ่งที่คุณสามารถทำได้ ( ควร ):

ปริมาณค่าใช้จ่ายของความล่าช้า! สมมติว่าใช้เวลา 1 สัปดาห์ในการทดสอบคุณสมบัติ การล่าช้า 2-3 สัปดาห์หมายความว่าคุณลักษณะนั้นจะไม่สามารถใช้งานได้จนถึงอย่างน้อยสัปดาห์ที่ 4 และนั่นก็คือความสำเร็จ 100% เพิ่มเวลาแก้ไขอีกหนึ่งสัปดาห์เพื่อให้ล่าช้าประมาณ 5 สัปดาห์

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

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

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

สิ่งที่คุณสะดุดสามารถวัดได้อย่างสะดวกโดยใช้ "Cost of Delay" - สนับสนุนโดย Don Reinerstein ในหลักการของกระบวนการพัฒนาผลิตภัณฑ์และโดย Dean Leffingwell ในข้อกำหนดซอฟต์แวร์ Agile คุณควรจะสามารถคืนการเรียกร้องทุกอย่างจากปัจจัยทางเศรษฐกิจเพื่อโน้มน้าวให้ 'ผู้มีอำนาจสูงกว่า' ซึ่งภาษาหลักคือ $$ - คุณต้องพูดภาษาเพื่อโน้มน้าวพวกเขา :)

โชคของสัตว์ร้าย! (ปุนตั้งใจ :)

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

หากส่วนหนึ่งของกระบวนการของคุณอ่อนแอเป็นพิเศษก็ถึงเวลาที่คุณจะต้องเลิกใช้ทฤษฎีข้อ จำกัด :

1. ระบุข้อ จำกัด

   ซึ่งหมายถึงการค้นหาส่วนที่ช้าที่สุดหรือไม่มีประสิทธิภาพที่สุดของกระบวนการโดยรวม ในกรณีของคุณมันคือการทดสอบ แต่ส่วนใดของการทดสอบ ใช่ไหม:

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

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

2. ใช้ประโยชน์จากข้อ จำกัด

   กล่าวอีกนัยหนึ่งปรับให้เหมาะสมรอบกระบวนการที่มีข้อ จำกัด อย่าปล่อยให้ผู้ทดสอบอยู่เฉยๆ จำนวนนี้เป็นหลัก:

   • วางผู้ทดสอบไว้ในทีมพัฒนาหากยังไม่ได้ดำเนินการดังนั้นจึงมีข้อเสนอแนะอย่างต่อเนื่องกับนักพัฒนา
   • มีการปรับใช้การทดสอบบ่อยครั้งดังนั้นจึงมีสิ่งใหม่ / คงที่เพื่อทดสอบเสมอ
   • ทำให้การสื่อสารเร็วขึ้นและบ่อยขึ้น ตัวอย่างเช่นชอบการส่งข้อความโต้ตอบแบบทันทีผ่านทางอีเมล
   • ตรวจสอบให้แน่ใจว่าผู้ทดสอบมีเครื่องมือที่ดีที่สุด (เครื่องเร็ว, จอภาพหลายจอ, การติดตามบั๊กที่มีประสิทธิภาพ ฯลฯ )

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

3. กิจกรรมอื่น ๆ ที่อยู่ภายใต้ข้อ จำกัด

   ณ จุดนี้ผู้ทดสอบมีประสิทธิผลเท่าที่จะเป็นไปได้ด้วยตัวเองดังนั้นเราจึงต้องเริ่มต้นการยืมผลิตผลจากพื้นที่อื่น:

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

4. ยกระดับข้อ จำกัด

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

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

5. กลับไปที่ขั้นตอนที่ 1

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

และถ้าไม่มีสิ่งใดที่ใช้งานได้ ... บางทีคุณอาจอยู่ใน บริษัท ที่ผิดปกติออกไปก่อนที่มันจะสายเกินไป!

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

หน้า 29 และ 30 อาจมีข้อมูลที่คุณกำลังค้นหาแม้ว่าอาจจำเป็นต้องมีการติดตาม

ฉันจะดูการวิจัยที่กล่าวถึงในประโยคนี้ในหน้า 30:

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

BTW มันเป็นคำถามของคุณที่ทำให้ฉันหยิบหนังสือขึ้นมาอีกครั้งเพื่อรีเฟรช :-)

สิ่งที่คุณกำลังอธิบายคือคอขวดในกระบวนการ ทฤษฎีลีนระบุว่าจะมีคอขวดในกระบวนการอยู่เสมอ แต่ความรุนแรงของมันอาจแตกต่างกันอย่างกว้างขวาง หากการประกันคุณภาพจ้างหนึ่งพิเศษแล้วการพัฒนาอาจกลายเป็นคอขวด

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

ในสถานการณ์สมมตินั้นค่าใช้จ่ายของความล่าช้าคือค่าใช้จ่ายของเงินเดือนของนักพัฒนาเนื่องจากงานของเขาจะสูญเปล่า

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

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

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

Software Development Stage         | Cost
-----------------------------------+------
Requirements and Design            | 1X
Code and Unit Testing              | 5X
Integration and System Testing     | 10X
Beta Testing                       | 15X
Post Release                       | 30X

( ตารางที่นี่จากที่นี่ )

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

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

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

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

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

ระวังวิธีที่คุณเข้าหาสิ่งนี้ หากคุณไม่มีวิธีแก้ไขปัญหาคุณมีแนวโน้มว่าจะดีที่สุดเป็นอันดับสอง