โปรแกรมเมอร์ควรมีความพอเพียงหรือไม่?

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

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

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

บันทึก

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

คำตอบที่ยอดเยี่ยมมาให้พวกเขามาหากคุณมีสิ่งที่จะเพิ่มหรือประสบการณ์ส่วนตัวที่จะแบ่งปัน!

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

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

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

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

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

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

คุณมีคำถามอื่นอีกมากมาย ฉันจะตอบเพียงหนึ่ง:

โปรแกรมเมอร์ควรจะต้องปรับแต่งข้อกำหนดหรือไม่

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

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

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

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

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

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

ยุติธรรมพอสมควร

งานประเภทนี้ควรเป็นความรับผิดชอบของฉันหรือไม่?

ในที่สุดมันก็ขึ้นอยู่กับการตัดสินใจของคุณ

ฉันเห็นตัวเองเป็นโปรแกรมเมอร์อย่างเคร่งครัดและไม่มีอะไรอื่น

บางทีคุณอาจทำงานผิด ผู้คนจำนวนมากชอบที่จะได้รับความรับผิดชอบพิเศษ

และถ้าสิ่งเหล่านี้เป็นความรับผิดชอบของฉันในระดับใด?

ถ้าผู้บริหารพูดอย่างนั้นใช่

โครงการขนาดใหญ่ที่ต้องใช้ผู้ทดสอบเมื่อใด

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

มีข้อได้เปรียบแน่นอนในการมีผู้ทดสอบโดยเฉพาะ แต่มีข้อเสียเช่นกัน ... นอกเหนือจากค่าใช้จ่ายในการจ้างพนักงานพิเศษ

หากโปรแกรมเมอร์ต้องปรับแต่งสเปค

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

กังวลเกี่ยวกับการจัดการโครงการ

ถ้าจำเป็นใช่

หรือแม้แต่ให้การสนับสนุนลูกค้า?

ถ้าจำเป็นใช่

มันฟังดูราวกับว่าคุณทำงานหนักเกินไปและทำปฏิกิริยากับแรงกดดัน นี่คือปัญหา. แต่การรับตำแหน่งว่า "ไม่ใช่หน้าที่ของคุณในการทำ X, Y, Z" จะไม่ช่วย แผนการที่ดีกว่าคือการทำให้ชัดเจนว่ามีเพียงสิ่งเดียวที่คุณสามารถทำได้และชี้ให้เห็นว่าสิ่งนี้มีแนวโน้มที่จะทำให้วันครบกำหนดที่จะพลาดคุณภาพการเลื่อนการสนับสนุนลูกค้าที่ไม่ดีเป็นต้น แต่ทำอย่างดีที่สุดแล้ว ... โดยไม่ทำลายสุขภาพความสัมพันธ์ ฯลฯ ในกระบวนการ

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

1. พวกเขามีทักษะสูงและมีทักษะที่แตกต่างกับโปรแกรมเมอร์
   1. พวกเขามีประสบการณ์และความรู้มากมายเกี่ยวกับวิธีการทดสอบ QA และวิธีการตรวจสอบว่ารหัสที่ผลิตนั้นตรงกับความคาดหวังของผู้ใช้และพฤติกรรมที่แท้จริงของผู้ใช้จริงหรือไม่
   2. พวกเขามีข้อบกพร่องมากมายและสามารถคิดถึงสถานการณ์ที่อาจทำให้ซอฟต์แวร์เสียหายได้
   3. พวกเขามักจะเหยียดหยามและเป็นระบบ ฉันสังเกตว่าโปรแกรมเมอร์มักจะมองโลกในแง่ดีกว่านี้มาก
2. พวกเขาให้ข้อเสนอแนะก่อนมีคุณค่าในการใช้งาน ตัวอย่างเช่นเมื่อสร้าง REST API เมื่อเร็ว ๆ นี้พื้นที่ที่ผู้ทดสอบ QA ไม่สามารถเข้าใจได้ง่ายถือเป็นตัวบ่งชี้ที่ดีของพื้นที่ที่ผู้ใช้จะพึงพอใจด้วย
3. พวกเขาทดสอบเกี่ยวกับสภาพแวดล้อมจริงในความเป็นจริงการกำหนดค่าจำนวนมากของฮาร์ดแวร์จริงระบบปฏิบัติการ ฯลฯ
4. พวกเขารู้วิธีสร้างขนาดใหญ่เป็นจริงมีเตียงทดสอบและทำการทดสอบโหลดและความเครียด
5. พวกเขามุ่งเน้นไปที่การป้องกันการเผยแพร่ที่ไม่ดีออกไป โปรแกรมเมอร์มักจะให้ความสำคัญกับการปล่อยรหัส เกือบจะเหมือนโปรแกรมเมอร์จะปล่อยรหัสโดยค่าเริ่มต้น แต่ผู้ทดสอบ QA จะต้องมีเหตุผลที่จะปล่อยมัน (มันแสดงให้เห็นว่าทำงาน!)

"ถ้าเรามีผู้ทดสอบคุณจะไม่ทดสอบรหัสของคุณเลย"

" ถ้ารถของคุณมีเข็มขัดนิรภัยคุณจะชนมันตลอดเวลา! "

งานประเภทนี้ควรเป็นความรับผิดชอบของฉันหรือไม่? [... ] และถ้าสิ่งเหล่านี้เป็นความรับผิดชอบของฉันในระดับใด?

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

โครงการขนาดใหญ่ที่ต้องใช้ผู้ทดสอบเมื่อใด

นั่นไม่ใช่คำถามที่ถูกต้องที่จะถาม คุณควรถามว่า "คุณภาพของผลิตภัณฑ์ / ภาพลักษณ์ของ บริษัท เมื่อใดจึงสำคัญที่ต้องใช้ผู้ทดสอบ"

หากโปรแกรมเมอร์ต้องปรับแต่งสเปค [... ]

ใช่อย่างแน่นอน. เวลาส่วนใหญ่มีความแตกต่างขนาดใหญ่ระหว่างสิ่งที่ผู้พัฒนา / ผู้ดำเนินการต้องการและสิ่งที่ลูกค้าให้ [เป็นข้อมูลจำเพาะ]

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

[... ] กังวลเกี่ยวกับการจัดการโครงการหรือแม้แต่ให้การสนับสนุนลูกค้า?

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

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

1. รายละเอียดผลิตภัณฑ์ + กรณีการใช้งาน
   แม้ว่าทุกคนจะรู้ (หรือคิดว่าพวกเขาทำ) สิ่งที่ฟังก์ชั่นผลิตภัณฑ์มันจะต้องถูกเขียนลง คุณไม่สามารถทดสอบแอปพลิเคชันโดยไม่มีข้อกำหนดที่ชัดเจน ข้อมูลจำเพาะจะกำหนดพฤติกรรมที่ถูกต้องและข้อผิดพลาดคืออะไร
2. การทดสอบหน่วยการรวมการทดสอบการ
   ทดสอบของ internals ซึ่งยากต่อการทดสอบผ่าน UI สถานะแอปพลิเคชันพิเศษ นี่คือสิ่งที่จำเป็นสำหรับทุกระบบที่ใหญ่กว่า การทดสอบทั้งสองประเภทมีคุณสมบัติที่น่าสนใจอีกประการหนึ่ง - พวกเขาบังคับให้คุณผ่านส่วนต่าง ๆ ของรหัสอีกครั้งและคุณจะพบปัญหาข้อบกพร่อง / สถาปัตยกรรมที่คุณไม่เคยเห็นมาก่อน
3. มาตรฐานคุณภาพรหัสและการเข้ารหัส
   หนึ่งในภารกิจที่ QA ควรทำคือการวัดความซับซ้อนของรหัส รหัสความซับซ้อนต่ำช่วยลดโอกาสในการเกิดข้อผิดพลาด (ป้องกันข้อบกพร่อง)
4. การตรวจสอบโค้ด
   เมื่อโครงการถึงขนาดที่กำหนดหรือมีผู้ใช้จำนวนมากต้องใช้การตรวจสอบโค้ด โปรแกรมเมอร์คนอื่นมักพบปัญหารหัส / ข้อบกพร่องที่คุณพลาดไป โปรแกรมเมอร์บางครั้งตาบอดเพื่อบั๊กที่เห็นได้ชัดในรหัสของตัวเอง
5. เอกสาร
   เอกสารรหัสและสถาปัตยกรรมของคุณมันจะช่วยให้คุณตระหนักถึงข้อบกพร่องที่เป็นไปได้ (ประสบการณ์ของตัวเอง)
6. ผู้ทดสอบเครื่อง
   ทดสอบไม่ใช่ลิงที่เพิ่งคลิกผ่าน UI ผู้ทดสอบใช้ข้อกำหนด & ใช้เคสและสร้างเคสทดสอบ จากนั้นเขา / เธอทดสอบพวกเขาทีละคน หากมีการรายงานข้อบกพร่องโดยผู้ใช้จะต้องเพิ่มกรณีทดสอบสำหรับกรณีนั้น

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

สิ่งที่โปรแกรมเมอร์สามารถทำได้คือ 2, 3 และ 5

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

หากคุณมีเวลาไม่มากพอที่จะสร้างกรณีทดสอบ (5) มักจะมีคนที่อุทิศตนเพราะต้องใช้เวลานาน หากไม่มีกรณีทดสอบการทดสอบเป็นเรื่องตลก