เราใช้เวลาในการทดสอบการใช้งานมากกว่าการใช้ระบบเองนี่เป็นเรื่องปกติหรือไม่?

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

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

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

ดังนั้นสิ่งที่มีค่าในการใช้เวลาเขียนทดสอบฟังก์ชั่นมากกว่าการเขียนรหัสระบบทดสอบหน่วยและแก้ไข Tikets QA? เป็นเรื่องปกติหรือไม่ เราไม่ควรเขียนการทดสอบการใช้งานเฉพาะสำหรับการทำงานที่สำคัญและให้ QA ทำการทดสอบการถดถอยโดยไม่มีการทำงานที่สำคัญ

หมายเหตุ: เราไม่ได้พัฒนาซอฟต์แวร์ทางการแพทย์หรือซอฟต์แวร์ NASA หรือไม่สำคัญอะไร

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

มีเหตุผลที่ดีเล็กน้อยในการทำการทดสอบการใช้งานอัตโนมัติในแอปพลิเคชัน

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

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

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

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

มากกว่า 2 เท่า ... ดูเหมือนจะมากสำหรับฉัน คุณอาจต้องการวิเคราะห์สาเหตุของสิ่งนี้ซึ่งอาจรวมถึง:

• การสนับสนุนเครื่องมือที่ไม่ดีสำหรับการสร้างและการบำรุงรักษาการทดสอบ

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

พูดคุยกับนักพัฒนาของคุณ

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

การใช้เวลามากขึ้นในการใช้การทดสอบการทำงานมากกว่าการใช้ระบบปกติหรือไม่

อย่างแน่นอน การเขียนแบบทดสอบที่ดีจริง ๆ น่าจะใช้เวลาส่วนใหญ่ในร้านค้า (ดี) จำนวนมาก
ดังนั้นอัตราส่วน 2-1 ก็โอเค นักพัฒนาที่มีประสบการณ์น้อยกว่ามักไม่ต้องใช้เวลาในการทดสอบทั้งหมด

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

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

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

นี่คือคุณภาพ

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

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

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

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

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