เครื่องมือสื่อสารสำหรับผู้พัฒนา

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

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

คำแนะนำหรือการศึกษาเกี่ยวกับวิธีทดสอบควรสื่อสารกับนักพัฒนา?

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

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

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

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

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

ฉันเป็นผู้เชื่อมั่นในการสื่อสารประเภทใดก็ได้ระหว่าง dev และ test

มีหลายครั้งที่ฉันเคยเห็นมวยต่อสู้กันระหว่างทีมเล็ก ๆ น้อย ๆ กลับไปกลับมา ("ปิดโดยการออกแบบ" ตามด้วย "เปิดใหม่" ฯลฯ )

ฉันมักจะบอกผู้ทดสอบที่ฉันทำงานด้วยเพื่อมาและพูดกับฉันหากพวกเขามีข้อสงสัยใด ๆ

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

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

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

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

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

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

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

ฉันชอบที่จะเห็นผู้ทดสอบเป็นส่วนหนึ่งของทีมเดียวกัน ในเรื่องที่ไม่มีปัญหาในการสื่อสาร

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

อย่างไรก็ตามทั้งสองฝ่ายต้องเคารพซึ่งกันและกันและปฏิบัติหน้าที่อย่างเหมาะสม

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

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

ทัศนคติแบบมืออาชีพคือทั้งหมดที่ใช้

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

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

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

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

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