ทำไมต้องให้ / ไม่ให้นักพัฒนาทำการทดสอบงานของตนเอง

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

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

ดังที่คนอื่น ๆ (และตัวคุณเอง) ตั้งข้อสังเกตไว้ผู้พัฒนาควรทดสอบโค้ดของตนเอง อย่างไรก็ตามหลังจากนั้นผลิตภัณฑ์ที่ไม่น่าสนใจใด ๆ ควรได้รับการทดสอบโดยบุคคลอิสระ (แผนก QA และ / หรือลูกค้าของตัวเอง)

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

นักพัฒนาซอฟต์แวร์ทราบวิธีการทำงานของรหัสและจะตกอยู่ในนิสัยทดสอบรหัสตามความรู้นี้

ผู้พัฒนาจะพบว่าเป็นการยากที่จะลบตัวเองออกจากความคิดของ 'วิธีการทำงาน' ซึ่งต่างจาก "วิธีการทำงาน"

ด้วยเหตุนี้จึงเป็นการดีกว่าที่จะรับคนที่มีระดับความเป็นกลางสูงเพื่อทดสอบโปรแกรมเช่น QA หรือ Test Engineers

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

นักพัฒนาจะต้องทดสอบการทำงานของพวกเขา มันเป็นความรับผิดชอบโดยนัย

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

นักพัฒนามักใช้อวนที่มีรูขนาดใหญ่สำหรับดักจับแมลง เป็นผลให้ข้อผิดพลาดที่มีขนาดเล็กหลบหนี

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

มีเหตุผลที่ดีบางประการในการมีทีมงานทดสอบเฉพาะด้าน อันดับแรกตามที่กล่าวไว้ข้างต้นผู้พัฒนาทำการทดสอบได้ดีมากว่ารหัสทำงานได้ดี แต่ไม่ทำลาย

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

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

เมื่อได้ทำงานกับทีมงาน QA และไม่ใช้งานฉันสามารถบอกคุณได้ว่าฉันพอใจ 100% กับงานที่ทำและจะบอกว่าพวกเขาเป็นส่วนหนึ่งที่มีค่าของทีมซอฟต์แวร์ เมื่อคุณมีทีมงาน QA มันทำให้การปล่อยรหัสของคุณง่ายขึ้นมาก b / c คุณรู้ว่ามันได้รับการทดสอบอย่างละเอียดและนั่นหมายความว่าคุณจะได้รับการโทรน้อยกว่า 3am

ผู้พัฒนาควรทดสอบโค้ดของตนเอง

ผู้ทดสอบอิสระไม่เพียง แต่ทดสอบว่าจะพังเท่านั้นพวกเขาจะทดสอบสมมติฐานที่ไม่ได้กำหนดและไม่ได้กำหนดซึ่งนักพัฒนาซอฟต์แวร์ทำขึ้นขณะทำการเข้ารหัส

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

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

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

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

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

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

ในฐานะนักพัฒนาที่คุณต้องรับผิดชอบต่อรหัสของคุณเองคุณควรทดสอบ Does the feature work as expected?หากคำตอบคือใช่คุณก็ทำเสร็จแล้ว

ทำไมคุณไม่ควรทำกรณีทดสอบ?

1. คุณเป็นอัตนัยเป็นข้อบกพร่องที่พบนั้นเขียนขึ้นโดยคุณ (หรือเพื่อนร่วมงานของคุณ)
2. คุณแพงเกินไปสำหรับ บริษัท ที่จะทำการทดสอบเคส (ฉันหวังว่า).

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

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

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

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

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

เทคนิคและทักษะสำหรับการทดสอบนั้นแตกต่างกันมากเช่นกัน

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

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

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

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

ขั้นตอนต่อไปคืองานของ QAs เพื่อค้นหาสิ่งที่นักพัฒนาไม่เห็นเมื่อเราเขียนรหัส นักพัฒนาคิดในระดับที่สูงขึ้น แต่ผู้ใช้อาจไม่คิดในระดับเดียวกัน เมื่อนักพัฒนากำลังทดสอบชิ้นส่วนของเขาและต้องป้อนข้อความบางส่วนในกล่องข้อความเขาอาจป้อนสตริงที่ผู้ใช้คิดอย่างเต็มรูปแบบและจะทำเช่นนั้นเสมอ อาจเป็นผู้ใช้ก็อาจทำเช่นนั้น แต่สุ่มเมื่อเขาป้อนอักขระพิเศษเช่น% & $ ^ ในข้อความและการแบ่งแอปพลิเคชันจะดูไม่ดีสำหรับผู้ใช้ปลายทาง ผู้พัฒนาไม่สามารถและจะไม่คิดถึงความเป็นไปได้ทั้งหมดที่อาจเกิดขึ้นเพราะเขาไม่ได้รับการฝึกฝนให้คิดเช่นนั้น เมื่อพูดถึง QA (ผู้ทดสอบ) พวกเขามักจะคิดถึงสิ่งที่ผู้ใช้อาจทำเพื่อทำลายแอปพลิเคชันนี้และลองทุกสิ่งที่โง่ในหนังสือไม่ใช่ผู้ใช้ที่โง่ แต่เราไม่ควรปล่อยให้โอกาส

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

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

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

ความคิดเห็นข้างต้นทำให้ได้คะแนนที่ดี

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

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

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

เมื่อกิจกรรมการทดสอบทำแยกต่างหากจากกิจกรรมการพัฒนาและผลลัพธ์ของ "ตกลง" ทั้งสองจะให้การยืนยันเพิ่มเติมว่าระบบนั้นถูกต้องและตรงกับความตั้งใจดั้งเดิมของข้อกำหนดอย่างแท้จริง

โปรแกรมเมอร์เมื่อทำการทดสอบจะเห็นกล่องข้อความชื่อ "ปริมาณ" และป้อน "1" โปรแกรมเมอร์ที่มีประสบการณ์สูงจะทำการทดสอบติดตามด้วยค่า "2"

ผู้ใช้จะเห็นกล่องข้อความชื่อ "ปริมาณ" และป้อน "~~ ยูนิคอร์น ROX !!! ~~" ผู้ใช้ที่มีประสบการณ์จะลอง "-12 1/2"

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

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

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

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

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

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

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

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

เหตุผลที่ผู้พัฒนาอาจทำการทดสอบขั้นสุดท้ายอาจไม่เป็นไร

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

เหตุผลที่นักพัฒนาซอฟต์แวร์ไม่ควรทำการทดสอบ

• สิ่งอื่นใด

โดยทั่วไปดูเหมือนว่าคุณกำลังอยู่บนเส้นทางที่ถูกต้องในการโจมตีโซลูชันจริง - ให้ผู้เชี่ยวชาญ SQA สร้างกรณีทดสอบ ...

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

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

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

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

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

• Eeveryone ควรทดสอบ - รหัสทดสอบ Develpers, ฟังก์ชั่นการทดสอบ QA'ers, การส่งข้อความทดสอบการตลาด ด้วยวิธีนี้ทุกคนมีปรัชญาและภาษาเดียวกันกับการทดสอบซึ่งเป็นการต่อสู้ครึ่งหนึ่ง

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

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

• เมื่อมีสิ่งใดเกิดขึ้นระหว่างการผลิตให้ทำสองสิ่ง:

  1. พูดว่า "อืมเรามีแบบทดสอบสำหรับเรื่องนี้ " เป็นความคิดเห็นแรกแล้วหรือยัง
  2. ทำการแก้ไขใด ๆรวมถึงการทดสอบปัญหาก่อนที่จะทำซ้ำกว่าการแก้ไข

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

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

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