เราเขียนข้อกำหนดคุณสมบัติการทำงานที่สมบูรณ์สำหรับทีมพัฒนาของเราสองคน เราไม่มีผู้ทดสอบมืออาชีพ แต่เราได้ร่างโดยความช่วยเหลือจากเจ้าหน้าที่ช่วยเหลือของเราที่มีอยู่เพื่อทำการทดสอบ QA
เราเคยมีปัญหาในอดีตที่ฟังก์ชั่นการทำงานที่สมบูรณ์ไม่ทำงานหรือโค้ดที่ส่งมอบนั้นไม่ตรงตามข้อกำหนด
คำถามของฉันคือนักพัฒนาควรหยุดการเขียนโค้ดที่ใกล้เคียงกับทีมงาน QA ในขั้นตอนใด มันมากเกินไปหรือไม่ที่จะให้นักพัฒนาตรวจสอบโค้ดของพวกเขาเทียบกับข้อมูลจำเพาะก่อนส่งมอบให้กับทีมงาน QA?
คำตอบ:
ไม่ควร!
มันยากมากที่จะทำงานทั้งหมดหยุดและแก้ไขปัญหาทั้งหมด เมื่อคุณไปแก้ไขปัญหาที่คุณพบในระหว่างกระบวนการ QA คุณอาจเรียนรู้ว่ามันจะเป็นการดีกว่าถ้าคุณทำสิ่งที่แตกต่างออกไป
แทนที่จะคิดว่าทุกอย่างเป็นกระบวนการล็อคลองทำให้มันเป็นวัฏจักรมากขึ้น กำหนดรหัสฟังก์ชั่นและทดสอบ เขียนโค้ดเพิ่มเติมและทดสอบ (และสิ่งเก่ายังคงใช้ได้) กระบวนการที่ลื่นไหลมากขึ้นนี้ช่วยลดความลำบากในการพยายามโหลดทุกอย่าง คุณยังสามารถมีแนวคิดของการตรึงโค้ด (เพียงแก้ไขข้อบกพร่อง) เมื่อคุณเข้าใกล้เส้นตาย แต่ประเด็นคือการทดสอบเร็วและบ่อยครั้ง
ถ้ารหัสทั้งหมดถูกส่งมอบให้กับ QA ในสถานะไม่ทำงานคุณอาจพิจารณาเพิ่มการทดสอบหน่วย / การรวมเข้ากับกระบวนการของคุณ อย่าทำผิดกฎเกี่ยวกับการควบคุมคุณภาพคนโดยทำให้พวกเขาพบว่าคุณไม่สามารถทำการทดสอบหน่วยหรือการรวมระบบได้
มันเป็นเรื่องที่ดีเพราะถ้ารหัสถูกส่งไปตามสเป็คแล้วสำหรับฉันนั่นหมายความว่าไม่มีข้อบกพร่อง (และไม่จำเป็นต้องมี QA!) ความจริงที่ว่ารหัสไม่ได้ถูกส่งไปยังสเป็คเป็นประจำคือเหตุผลที่เราทำ QA ตั้งแต่แรก
แต่ฉันไม่คิดว่านั่นคือสิ่งที่คุณกำลังพูดถึง สิ่งที่คุณหมายถึงคือทีม dev ดูเหมือนขี้เกียจเกินไปกับการเขียนโค้ดและมีสิ่งที่ชัดเจนขนาดใหญ่ที่ดูเหมือนจะไม่ทำงาน การวางโครงร่างก่อนถึงมือนั้นจำเป็นต้องมีการทดสอบหน่วยสำหรับแต่ละคุณสมบัติ A, B และ C (ในข้อมูลจำเพาะ) จากนั้นให้มีการตรวจสอบรหัสและการทดสอบอย่างอิสระ (โดยทีมงานหรือผู้จัดการ) จะช่วยบรรเทาปัญหาประเภทนี้ .
ฉันขอยืนยันว่าอย่างน้อยที่สุดนักพัฒนาควรทดสอบ "เส้นทางแห่งความสุข" หากพวกเขาป้อนข้อมูลที่คาดหวังก็จะทำในสิ่งที่ spec บอกว่าควรทำ นักพัฒนาที่ไม่ทำสิ่งนั้นมากนักควรถูกสอบสวน
ฉันก็ผิดหวังเช่นกันหากนักพัฒนาไม่ได้ทดสอบกรณีขอบชัดเจน: สตริงยาวเกินไปสำหรับฐานข้อมูลข้อความที่ไม่ถูกต้องชัดเจนถ้าคุณป้อนตัวอักษรที่ควรเป็นตัวเลข ฯลฯ หากเกิดขึ้นบ่อยครั้งควรถามคำถามอีกครั้ง .
อย่างไรก็ตามสมมติว่ามันไม่ได้กล่าวถึงโดยเฉพาะในข้อมูลจำเพาะหากนักพัฒนา จำกัด ชื่อเพียงตัวอักษรพิมพ์ใหญ่และตัวพิมพ์เล็ก แต่ลืมว่าชื่อบางชื่อมีเครื่องหมายอะโพสโทรฟีหรืออนุญาตให้มีวันที่ 29 กุมภาพันธ์ 2011 . นอกเสียจากว่าพวกเขากำลังทำผิดพลาดครั้งแล้วครั้งเล่า
ทีมงานควบคุมคุณภาพควรจะยกกรณีที่รุนแรง ฉันชอบให้ QA เป็นผู้ทดสอบลิง: เพียงแค่ป้อนขยะแบบสุ่มดูว่าพวกเขาสามารถทำลายแอพได้หรือไม่
ในการพัฒนาเว็บไซต์ QA ควรลองใช้เบราว์เซอร์ที่แตกต่างกันและลองค้นหาปลั๊กอินที่อาจมีผลกับรหัส พวกเขาควรจะปิด Javascript และ CSS และดูว่าพวกเขาสามารถไปได้ไกลแค่ไหน สิ่งนั้น หากคุณคาดหวังว่านักพัฒนาจะทำเช่นนั้นคุณจะใช้เงินกับมันมากเกินไป
หากมีการส่งมอบฟังก์ชันการทำงานที่ใช้งานไม่ได้แสดงว่าปัญหาไม่ได้อยู่ระหว่างการพัฒนาและ QA แต่เป็นการพัฒนาและการเป็นเจ้าของผลิตภัณฑ์
เจ้าของผลิตภัณฑ์และนักพัฒนาควรเป็นส่วนหนึ่งของทีมเดียวกันและควรทำงานร่วมกันเพื่อกำหนดสิ่งที่ต้องใช้เพื่อพิจารณาคุณสมบัติ "เสร็จสิ้น" และเพื่อให้แน่ใจว่ารหัสตรงตามความต้องการ
เมื่อมีการส่งมอบรหัสการทดสอบควรเป็นทางการเพียงเพราะเจ้าของผลิตภัณฑ์ควรทำงานร่วมกับนักพัฒนาตามวิธีการเพื่อให้แน่ใจว่าครอบคลุมทุกกรณีการใช้งาน
(หากคุณมีผู้ทดสอบมืออาชีพพวกเขาควรเป็นส่วนหนึ่งของทีมและควรมีส่วนร่วมในทุกขั้นตอน)
เรามีกระบวนการคัดกรองโครงการที่เราขอให้นักพัฒนาให้คำแนะนำแบบย่อ / สาธิตรหัสก่อนที่จะเข้าสู่การควบคุมคุณภาพ เรารวมถึงผู้ทดสอบ QA เท่านั้น แต่ยังรวมถึงเจ้าของธุรกิจของรหัสบริการลูกค้าและการตลาด / การออกแบบ สิ่งนี้มีแนวโน้มที่จะมุ่งเน้นไปที่นักพัฒนาอย่างน้อยกรณีที่ใช้งานง่ายและบางครั้งการสนทนาที่เกิดขึ้นระหว่างทีมต่าง ๆ ส่งผลให้เกิดการเปลี่ยนแปลงรายละเอียดและความล่าช้าในการเข้าสู่ QA เมื่อใดที่เราสามารถทำได้เราจะต้องเกี่ยวข้องกับ QA ก่อนหน้านี้มากในกระบวนการซึ่งจะช่วยแก้ไขข้อผิดพลาดในขณะที่รหัสยังอุ่นอยู่ - แต่เรายังคงทำคำแนะนำก่อนเริ่ม QA อย่างเป็นทางการ
บางครั้งฉันบอกว่าไม่ควรส่งรหัสไปยัง QA หากคุณรู้สึกไม่ดีหากมันไปผลิตแทนโดยไม่ตั้งใจ รหัสที่มีความผิดปกติที่สำคัญไม่ได้อยู่ใน QA (ยกเว้นในบางสถานการณ์)