คุณเชื่อหรือไม่ว่าเป็นความคิดที่ดีที่วิศวกรซอฟต์แวร์จะต้องทำงานเป็นวิศวกรประกันคุณภาพเป็นระยะเวลาหนึ่งหรือไม่? [ปิด]

ฉันเชื่อว่ามันเป็น ทำไม?

1. ฉันพบวิศวกรซอฟต์แวร์หลายคนที่เชื่อว่าพวกเขาเหนือกว่าวิศวกร QA ฉันคิดว่ามันอาจช่วยระงับความเชื่อนี้ได้หากพวกเขาทำงานของวิศวกรควบคุมคุณภาพในบางครั้งและตระหนักว่ามันเป็นชุดทักษะที่เป็นเอกลักษณ์และมีค่าของตัวเอง

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

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

4. คำนิยาม "สมบูรณ์" ของ Software Engineer นั้นน่าสนใจอยู่เสมอ ... หากพวกเขาใช้เวลาเป็นวิศวกร QA บางทีนิยามนี้จะตรงกับผู้ออกแบบซอฟต์แวร์มากขึ้น

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

คุณคิดอย่างไร?

1. ฉันได้พบกับวิศวกรซอฟต์แวร์หลายคนที่เชื่อว่าพวกเขาเหนือกว่าวิศวกร QA ฉันคิดว่ามันอาจช่วยระงับความเชื่อนี้ได้หากพวกเขาทำงานของวิศวกรควบคุมคุณภาพในบางครั้งและตระหนักว่ามันเป็นชุดทักษะที่เป็นเอกลักษณ์และมีค่าของตัวเอง

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

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

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

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

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

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

4. คำจำกัดความ "สมบูรณ์" ของ Software Engineer นั้นน่าสนใจอยู่เสมอ ... หากพวกเขาใช้เวลาเป็นวิศวกร QA บางทีนิยามนี้จะตรงกับผู้ออกแบบซอฟต์แวร์มากขึ้น

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

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

ไม่ใช่ว่าประสบการณ์นี้จะไม่ช่วย แต่คุณสามารถใช้ความคิดนี้ได้ไกลแค่ไหน? ฝ่ายสนับสนุนด้านเทคนิค, การขาย, ผู้ใช้เบต้าขัดผิวส้วม

"... ต้องทำงานเป็นวิศวกรควบคุมคุณภาพ ... "? คุณทำให้เป็นปฏิปักษ์หรือการลงโทษ

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

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

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

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

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

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

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

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

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

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

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

นี่คือปัญหาที่อาจเกิดขึ้นที่ฉันเห็นด้วยข้อเสนอของคุณ:

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

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

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

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

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

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

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

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