นักพัฒนาซอฟต์แวร์ควรทำหน้าที่เป็นผู้ทดสอบหรือไม่ [ปิด]


60

เราเป็นทีมการต่อสู้ของนักพัฒนา 3 คนนักออกแบบ 1 คนต้นแบบการต่อสู้และเจ้าของผลิตภัณฑ์ อย่างไรก็ตามเราไม่มีผู้ทดสอบอย่างเป็นทางการในทีมของเรา ปัญหาที่เกิดขึ้นกับเราเสมอคือการทดสอบแอปพลิเคชันและผ่านการทดสอบและการลบข้อบกพร่องนั้นได้ถูกกำหนดเป็นหนึ่งในเกณฑ์ในการพิจารณา PBI (Product Backlog Item) เช่นเดียวกับที่ทำ

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

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

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

ถูกต้องหรือไม่ เราควรพัฒนา (หรือผู้ออกแบบ) ด้วยเช่นกัน?


1
มีความเป็นไปได้ที่ซ้ำกันของprogrammers.stackexchange.com/questions/100637/…แม้ว่าคน ๆ นั้นจะถามจากมุมมองตรงกันข้าม
อดัมเลียร์

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

นักเขียนต้องการเครื่องมือแก้ไข
JeffO

คำตอบ:


59

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

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

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

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

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

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

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


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

5
@maple_shaft: ฉันไม่มีข้อแก้ตัวที่ไม่มีผู้ทดสอบ โครงการใด ๆ ที่จะให้คุณภาพที่สูงขึ้นด้วยเครื่องมือทดสอบเฉพาะและนักพัฒนาสามารถมุ่งเน้นและพัฒนาได้ดีหากมี การมีนักพัฒนาทดสอบรหัสของแต่ละคนนั้นเป็นวิธีการแก้ปัญหาชั่วคราวแม้สำหรับทีมเล็ก ๆ คุณควรอ่านบทความของ Joelด้วยเช่นกัน
Falcon

3
นักพัฒนาสามารถเป็นผู้ทดสอบได้ - และนักพัฒนาที่ดีจะรู้จักสถานที่ต่าง ๆ ที่รหัสอาจอ่อนแอและอาจมีการแตกหัก ไม่เคยมีคนทดสอบรหัสที่พวกเขาออกแบบหรือเขียน - ที่ไร้ประโยชน์ รหัสของคนอื่นอาจไม่เป็นไร
StasM

4
@Dadalnix: จริง ๆ แล้วฉันปริศนาว่าทำไมผู้คนลงคะแนนโดยไม่ต้องอ่านและเข้าใจคำตอบของฉัน ในการอ้างอิงตนเอง: "ซอฟต์แวร์ควรสำรองข้อมูลโดยการทดสอบหน่วยและข้อผิดพลาดทางเทคนิคควรลดลงให้น้อยที่สุดก่อนมอบซอฟต์แวร์ให้ผู้ทดสอบ"
เหยี่ยว

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

42

นักพัฒนาสามารถทดสอบ - รหัสของนักพัฒนาอื่น ๆ

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

มักจะมีนักพัฒนาซอฟต์แวร์ที่คิดว่าพวกเขาทำได้ดี แต่โดยปกติแล้วพวกเขาจะทำไม่ได้ (และฉันรู้ว่าฉันมีจุดบอดมากมาย)

หากคุณต้องการว่าจ้างผู้ทดสอบจริงๆแล้วให้ผู้พัฒนาทำการทดสอบข้ามซึ่งกันและกัน - นั่นคือถ้า A เขียนโค้ดและทำการทดสอบหน่วยให้รับ B เพื่อดูการทดสอบหน่วยเหล่านั้นและดูว่ามีสิ่งอื่น ๆ ที่สามารถเพิ่มได้หรือไม่ . และรับ B เพื่อลองและทดสอบรหัส (ในฐานะผู้ใช้) และรายงานข้อบกพร่อง

สิ่งนี้ไม่สมบูรณ์แบบ แต่ดีกว่านักพัฒนาเดียวที่พยายามทำทุกอย่าง

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


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

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

5
+1 เป็นไปไม่ได้ที่จะทดสอบรหัสของคุณอย่างถูกต้อง มันยอดเยี่ยมมากที่กลลวงจิตใจสามารถเล่นกับคุณได้ - คุณจะมั่นใจได้ 100% ว่าคุณเขียนและทดสอบฟังก์ชั่นบางอย่างและจะพาคนอื่นมาแสดงให้คุณเห็นว่ามันใช้งานไม่ได้จริงยกเว้นในกรณีที่แคบมาก ๆ ชัดเจนสำหรับคุณเมื่อปรากฏ - แต่คุณจะไม่เห็นด้วยตนเอง จิตใจใช้ทางลัดความรู้ความเข้าใจและในการทดสอบสิ่งเหล่านั้นทำให้เป็นไปไม่ได้สำหรับผู้ที่ออกแบบและพัฒนารหัสเพื่อทดสอบอย่างถูกต้อง
StasM

2
@StasM - เห็นด้วยกับคุณสมบัติเล็ก ๆ น้อย ๆ หนึ่ง: ฉันได้พบว่าการกลับมาที่รหัสของฉันเองในเดือนต่อมาฉันสามารถเห็นความผิดพลาดและสามารถทำการทดสอบได้ดีขึ้น แต่ทดสอบด้วยตัวเองหลังจากเขียนยากมากแน่นอน
quick_now

1
@Ben Aston: นักพัฒนายังควรทำการทดสอบหน่วยการทดสอบการรวมระบบและอื่น ๆ ไม่เพียง แต่เฉพาะ จุดบอดจะไม่หายไปเพียงเพราะคุณต้องการ
quick_now

11

นักข่าวควรเขียนอย่างถูกต้องหรือไม่? ฉันหมายถึงมันเป็นงานแก้ไขและแก้ไขเพื่อค้นหาข้อผิดพลาดทางไวยากรณ์ทั้งหมด

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

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

ถ้าหากนอกเหนือจากการพัฒนาแล้วยังทำงานอย่างต่อเนื่องมันก็หมายถึงข้อเท็จจริงอย่างง่าย ๆ - เขาเป็นผู้ทดสอบนอกเวลา


10

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

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

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

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


... เราแนะนำให้ บริษัท จ้างผู้ทดสอบรายใหม่ ใครบางคนที่ทำหน้าที่ทดสอบและทดสอบเท่านั้น ผู้ทดสอบมืออาชีพอย่างเป็นทางการ

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

ต้องยอมรับการจัดการของ บริษัท ของคุณดูค่อนข้างอ่อนแอสำหรับฉัน ฉันหมายถึง - โอเคมันอาจจะยากที่จะรู้ว่ามีผู้ทดสอบกี่คนที่ดีที่สุดสำหรับโครงการ

แต่การที่จะมีอย่างน้อยหนึ่งเครื่องทดสอบเป็นเพียงเดิมพันที่ปลอดภัย - ตลกจริงๆว่าพวกเขาลังเลที่จะให้มันลองในขณะที่อ้างว่าตัวเองต่อสู้ /เปรียว


9

เรามีผู้พัฒนาสองคนทำการทดสอบข้ามหลังจากคนแรกทำการเปลี่ยนแปลงบางอย่างในหน้าจอเริ่มต้น นี่คือเมื่อผู้ทดสอบตามปกติของเราปิดการลาคลอด

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

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

ปรากฎว่าผู้พัฒนานำกล่องกาเครื่องหมายออก (สำหรับการเลือก) และปุ่มแก้ไขและเนื่องจากนักพัฒนาได้ดับเบิลคลิกเพื่อเลือกรายการอยู่เสมอไม่มีใครพบว่ามีอะไรผิดปกติกับมัน ......

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


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

4

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


2

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


2

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

ยิ่งไปกว่านั้นปัญหาที่จิตใต้สำนึกนักพัฒนาซอฟต์แวร์ไม่ต้องการที่จะหาข้อบกพร่อง


1

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

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.