ทำไมผู้ทดสอบและโปรแกรมเมอร์ไม่เหมือนกัน [ปิด]

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

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

ฉันคิดว่านั่นเป็นสิ่งที่แย่เกินความคาดหมายและทำให้เข้าใจง่าย

ตอนนี้ฉันเป็นผู้ทดสอบฉันเขียนโค้ดเกือบเท่าที่ฉันเขียนในฐานะ dev (ขึ้นอยู่กับขั้นตอนการทดสอบ) และเพื่อนที่ดีที่สุดของฉันใน บริษัท คือ dev และพวกเราทุกคนเข้ากันได้ดี

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

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

แก้ไข

โปรดทราบด้วยว่าฉันคิดว่าความรับผิดชอบอยู่บนผู้ทดสอบมากกว่าผู้พัฒนาเพื่อสนับสนุนความสัมพันธ์ระหว่างทั้งสอง

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

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

ทำไมปัญหาเกิดขึ้น?

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

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

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

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

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

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

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

ผู้ทดสอบที่สามารถแสดงปัญหาได้อย่างชัดเจนและผู้เขียนที่ใช้งานโซลูชั่นอย่างชัดเจนเป็นทีมที่ยอดเยี่ยม

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

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

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

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

เมื่อโปรแกรมเมอร์และผู้ทดสอบไม่ชอบซึ่งกันและกันบ่อยครั้งเป็นเพราะพวกเขาคิดผิดพลาดว่าเป้าหมายของพวกเขาขัดแย้งกัน

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

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

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

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

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

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

นักพัฒนาบางคนดูถูก QA ฉันยังคงค่อนข้าง QA ค้นหาข้อบกพร่องมากกว่าลูกค้า ....

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

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

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

ในฐานะนักพัฒนาฉันได้สัมผัสกับความตึงเครียดกับผู้ทดสอบ

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

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

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

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

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

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

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

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

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

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

juju ไม่ดี

สิ่งนี้มักจะเกิดขึ้นจากปัจจัยสามประการ -

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

ฉันชอบผู้ทดสอบ แต่มีสองกรณีที่ฉันพบข้อขัดแย้ง

1. เมื่อผู้บริหารเล่นผู้ทดสอบและพัฒนาผู้อื่น

2. เมื่อมีการส่งปัญหาอย่างต่อเนื่องโดยไม่มีรายละเอียดเช่น "หน้าจอ x ไม่ทำงาน"

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

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