สวัสดีทุกคน! ฉันชื่อจูเลีย และฉันเป็นผู้ทดสอบ ปีที่แล้วฉันบอกคุณเกี่ยวกับ - กิจกรรมที่จัดขึ้นในบริษัทของเราเพื่อกำจัดข้อผิดพลาดที่ค้างอยู่ นี่เป็นตัวเลือกที่เป็นไปได้อย่างสมบูรณ์ในการลดสิ่งนี้ลงอย่างมาก (จาก 10 เป็น 50% ในทีมต่างๆ) ในเวลาเพียงวันเดียว
วันนี้ฉันอยากจะบอกคุณเกี่ยวกับรูปแบบ Bagodelny ฤดูใบไม้ผลิของเรา - BUgHunting (BUH) ครั้งนี้เราไม่ได้แก้ไขข้อบกพร่องเก่า แต่มองหาข้อบกพร่องใหม่และเสนอแนวคิดเกี่ยวกับคุณสมบัติต่างๆ ด้านล่างมีรายละเอียดมากมายเกี่ยวกับการจัดกิจกรรมดังกล่าว ผลลัพธ์ของเรา และข้อเสนอแนะจากผู้เข้าร่วม
เมื่อพิจารณาและเขียนกฎเกณฑ์อย่างละเอียดแล้ว เราได้ส่งคำเชิญไปยังทุกช่องทางใน Slack ขององค์กร ซึ่งไม่มีข้อจำกัดใดๆ:
เป็นผลให้มีผู้ลงทะเบียนประมาณ 30 คน - ทั้งนักพัฒนาและผู้เชี่ยวชาญที่ไม่ใช่ด้านเทคนิค เราจัดสรรเวลาทำงานทั้งวันเพื่อจัดงาน จองห้องประชุมขนาดใหญ่ และจัดอาหารกลางวันในโรงอาหารของสำนักงาน
ทำไม?
ดูเหมือนว่าแต่ละทีมจะทดสอบการทำงานของตน ผู้ใช้รายงานข้อบกพร่องให้เราทราบ ทำไมถึงจัดงานแบบนี้ด้วย?
เรามีเป้าหมายหลายประการ
- แนะนำหนุ่มๆ ให้ใกล้ชิดกับโครงการ/ผลิตภัณฑ์ที่เกี่ยวข้องมากขึ้น.
ขณะนี้ในบริษัทของเรา ทุกคนทำงานในทีมแยกกัน - หน่วยงาน เหล่านี้เป็นทีมงานโครงการที่ทำงานในส่วนของตนเองและไม่ได้ตระหนักถึงสิ่งที่เกิดขึ้นในโครงการอื่นเสมอไป - เพียงแนะนำเพื่อนร่วมงานของคุณให้รู้จักกัน.
เรามีพนักงานเกือบ 800 คนในสำนักงานในมอสโก ไม่ใช่เพื่อนร่วมงานทุกคนที่รู้จักกันด้วยสายตา - ปรับปรุงความสามารถของนักพัฒนาในการค้นหาจุดบกพร่องในผลิตภัณฑ์ของตน.
ตอนนี้เรากำลังส่งเสริม Agile Testing และฝึกอบรมคนในทิศทางนี้ - มีส่วนร่วมมากกว่าผู้เชี่ยวชาญด้านเทคนิคในการทดสอบ.
นอกจากแผนกเทคนิคแล้ว เรายังมีเพื่อนร่วมงานจากสาขาอื่นๆ ที่ต้องการพูดคุยเพิ่มเติมเกี่ยวกับการทดสอบ เกี่ยวกับวิธีการรายงานจุดบกพร่องอย่างเหมาะสม เพื่อให้เราได้รับข้อความน้อยลงในรูปแบบ “อ๊ะ... ไม่มีอะไรทำงาน” - และแน่นอนว่าพบข้อบกพร่องที่ยุ่งยากและไม่ชัดเจน.
ฉันต้องการช่วยทีมทดสอบคุณสมบัติใหม่และให้โอกาสพวกเขาดูฟังก์ชันการใช้งานจากมุมที่ต่างออกไป
การดำเนินงาน
วันของเราประกอบด้วยหลายช่วงตึก:
- การบรรยายสรุป;
- การบรรยายสั้นๆ เกี่ยวกับการทดสอบ ซึ่งเราได้กล่าวถึงเฉพาะประเด็นหลักเท่านั้น (เป้าหมายและหลักการทดสอบ ฯลฯ)
- หัวข้อ “กฎมารยาทที่ดี” เมื่อแนะนำจุดบกพร่อง ( มีการอธิบายหลักการไว้เป็นอย่างดี)
- เซสชันการทดสอบสี่เซสชันสำหรับโครงการที่มีสถานการณ์จำลองระดับสูง ก่อนแต่ละเซสชั่นจะมีการบรรยายเบื้องต้นสั้น ๆ เกี่ยวกับโครงการและแบ่งเป็นทีม
- แบบสำรวจสั้นๆ เกี่ยวกับงาน;
- การสรุป
(เราไม่ลืมเรื่องการพักระหว่างเซสชั่นและมื้อเที่ยงด้วย)
กฎพื้นฐาน
- การลงทะเบียนสำหรับกิจกรรมเป็นรายบุคคลซึ่งช่วยแก้ปัญหาการหมดแรงทั้งทีมเนื่องจากความเฉื่อยหากคนใดคนหนึ่งตัดสินใจที่จะไม่ไป
- ผู้เข้าร่วมเปลี่ยนทีมทุกเซสชั่น. ซึ่งช่วยให้ผู้เข้าร่วมเข้าออกได้ตลอดเวลา และคุณยังสามารถพบปะผู้คนได้มากขึ้นอีกด้วย
- Команды สองคนก่อนแต่ละเซสชั่น ถูกสร้างขึ้นแบบสุ่มทำให้มีความไดนามิกและรวดเร็วยิ่งขึ้น
- สำหรับข้อบกพร่องที่แนะนำ คุณจะได้รับรางวัล คะแนน (จาก 3 ถึง 10) ขึ้นอยู่กับความสำคัญ.
- จะไม่มีการให้คะแนนสำหรับรายการที่ซ้ำกัน
- สมาชิกในทีมจะต้องยื่นจุดบกพร่องตามมาตรฐานภายในทั้งหมด
- คำขอคุณลักษณะจะถูกสร้างขึ้นในงานแยกต่างหากและมีส่วนร่วมในการเสนอชื่อแยกต่างหาก
- ทีมตรวจสอบจะติดตามการปฏิบัติตามกฎเกณฑ์ทั้งหมด
รายละเอียดอื่น ๆ
- ในตอนแรกฉันต้องการจัดกิจกรรมทดสอบ "ขั้นสูง" แต่... มีคนจำนวนมากจากทีมที่ไม่ใช่ผลิตภัณฑ์ลงทะเบียน (SMM, ทนายความ, ประชาสัมพันธ์) เราต้องทำให้เนื้อหาง่ายขึ้นอย่างมากและลบกรณีที่ซับซ้อน/โปรไฟล์ออก
- เนื่องจากการทำงานของหน่วยงานใน Jira ในโครงการต่างๆ ตามโฟลว์ของเรา เราจึงสร้างโปรเจ็กต์แยกต่างหากเป็นพิเศษโดยเราได้ตั้งค่าเทมเพลตสำหรับแนะนำจุดบกพร่อง
- ในการคำนวณคะแนน พวกเขาวางแผนที่จะใช้ลีดเดอร์บอร์ดที่อัปเดตผ่านเว็บฮุค แต่มีบางอย่างผิดพลาด และสุดท้ายการคำนวณก็ต้องดำเนินการด้วยตนเอง
ทุกคนประสบปัญหาในการจัดกิจกรรม และเพื่อให้ง่ายขึ้นสำหรับคุณ ฉันจะอธิบายปัญหาของเราที่คุณสามารถหลีกเลี่ยงได้
จู่ๆ วิทยากรคนหนึ่งก็ล้มป่วยและต้องหาลำโพงใหม่.
ฉันโชคดีมากที่ได้พบตัวแทนจากทีมเดิมเมื่อเวลา 9 น.) แต่อย่าพึ่งโชคแล้วมีสำรองจะดีกว่า หรือเตรียมรายงานที่จำเป็นด้วยตนเอง
เราไม่มีเวลาเปิดตัวฟังก์ชันนี้ เราต้องสลับบล็อก.
เพื่อหลีกเลี่ยงไม่ให้ทิ้งทั้งบล็อก ควรมีแผนสำรองจะดีกว่า
ผู้ใช้ทดสอบบางรายลดลง เราต้องสร้างผู้ใช้ใหม่อย่างรวดเร็ว.
ตรวจสอบผู้ใช้ทดสอบล่วงหน้าหรือสามารถทำได้อย่างรวดเร็ว
แทบจะไม่มีใครที่มีรูปแบบที่เรียบง่ายเข้ามาเลย.
ไม่จำเป็นต้องลากใครด้วยกำลัง ถ่อมใจตัวเอง
มีตัวเลือกในการกำหนดรูปแบบของกิจกรรมอย่างเคร่งครัด: "มือสมัครเล่น"/"ขั้นสูง" หรือเตรียมสองตัวเลือกในคราวเดียวและตัดสินใจว่าจะเลือกอันไหนหลังจากข้อเท็จจริง
ประเด็นที่เป็นประโยชน์ขององค์กร:
- จองการประชุมล่วงหน้า
- จัดโต๊ะ อย่าลืมสายไฟต่อและอุปกรณ์ป้องกันไฟกระชาก (การชาร์จแล็ปท็อป/โทรศัพท์อาจไม่เพียงพอตลอดทั้งวัน)
- ทำให้กระบวนการให้คะแนนเป็นไปโดยอัตโนมัติ
- จัดทำตารางอันดับ
- ทำเอกสารประกอบคำบรรยายพร้อมข้อมูลเข้าสู่ระบบและรหัสผ่านของผู้ใช้ทดสอบคำแนะนำในการทำงานกับ Jira สคริปต์
- อย่าลืมส่งการแจ้งเตือนหนึ่งสัปดาห์ก่อนงาน และระบุสิ่งที่คุณต้องนำติดตัวไปด้วย (แล็ปท็อป/อุปกรณ์)
- บอกเพื่อนร่วมงานของคุณเกี่ยวกับกิจกรรมนี้ในการสาธิต มื้อกลางวัน หรือดื่มกาแฟสักแก้ว
- เห็นด้วยกับผู้พัฒนาที่จะไม่อัปเดตหรือเปิดตัวสิ่งใดในวันนี้
- เตรียมวิทยากร
- เจรจากับเจ้าของฟีเจอร์และเขียนสถานการณ์เพิ่มเติมสำหรับการทดสอบ
- สั่งขนม (คุกกี้/ลูกอม) เป็นของว่าง
- อย่าลืมบอกเราเกี่ยวกับผลการจัดงาน
ผลการวิจัย
ตลอดทั้งวัน พวกเขาสามารถทดสอบ 4 โปรเจ็กต์และสร้างข้อบกพร่อง 192 รายการ (ไม่ซ้ำกัน 134 รายการ) และ 7 ปัญหาเกี่ยวกับการร้องขอฟีเจอร์ แน่นอนว่าเจ้าของโปรเจ็กต์ทราบเกี่ยวกับข้อบกพร่องเหล่านี้แล้ว แต่ก็มีการค้นพบที่ไม่คาดคิดเช่นกัน
ผู้เข้าร่วมทุกคนได้รับรางวัลอันแสนหวาน
และผู้ชนะ ได้แก่ กระติกน้ำ, ตรา, เสื้อสเวตเตอร์
สิ่งที่น่าสนใจ:
- ผู้เข้าร่วมพบว่ารูปแบบของเซสชันที่ยากลำบากนั้นไม่คาดคิด เมื่อเวลามีจำกัดและคุณไม่สามารถใช้เวลาคิดมากได้
- จัดการเพื่อทดสอบเดสก์ท็อป เวอร์ชันมือถือ และแอปพลิเคชัน
- เราดูหลายโครงการพร้อมกันไม่มีเวลาเบื่อ
- พบกับเพื่อนร่วมงานหลายคน ดูแนวทางของพวกเขาในการแนะนำจุดบกพร่อง
- รู้สึกถึงความเจ็บปวดของผู้ทดสอบ
สิ่งที่สามารถปรับปรุงได้:
- ทำโปรเจ็กต์น้อยลงและเพิ่มเวลาเซสชันเป็น 1,5 ชั่วโมง
- เตรียมของขวัญ/ของที่ระลึกล่วงหน้ามาก (บางครั้งการอนุมัติ/การชำระเงินใช้เวลาหนึ่งเดือน)
- ผ่อนคลายและยอมรับว่าบางอย่างไม่เป็นไปตามแผนและจะเกิดเหตุสุดวิสัย
ความคิดเห็น
Anna Bystrikova ผู้ดูแลระบบ: “โรงทานให้ความรู้แก่ฉันมาก ฉันได้เรียนรู้ขั้นตอนการทดสอบและรู้สึกถึง “ความเจ็บปวด” ของผู้ทดสอบทั้งหมด
ในตอนแรก ในระหว่างกระบวนการทดสอบ ในฐานะผู้ใช้ที่เป็นแบบอย่าง คุณจะตรวจสอบประเด็นหลักๆ ว่ามีการคลิกปุ่มหรือไม่ จะไปที่หน้าหรือไม่ เค้าโครงได้ย้ายออกไปแล้วหรือไม่ แต่ต่อมาคุณตระหนักได้ว่าคุณต้องคิดนอกกรอบให้มากขึ้น และพยายาม "ทำลาย" แอปพลิเคชัน ผู้ทดสอบมีงานที่ยากลำบาก การ "กระตุ้น" ทั่วทั้งอินเทอร์เฟซนั้นไม่เพียงพอ คุณต้องพยายามคิดนอกกรอบและเอาใจใส่อย่างยิ่ง
การแสดงผลเป็นบวกเท่านั้น แม้ว่าตอนนี้ หลังจากเหตุการณ์ผ่านไประยะหนึ่ง ฉันก็เห็นว่าการทำงานกับข้อบกพร่องที่ฉันพบนั้นเป็นอย่างไร รู้สึกดีมากที่ได้มีส่วนร่วมในการปรับปรุงผลิตภัณฑ์ ^_^”
Dmitry Seleznev ผู้พัฒนาส่วนหน้า: “การทดสอบในโหมดการแข่งขันเป็นแรงบันดาลใจอย่างมากให้เราค้นหาจุดบกพร่องเพิ่มเติม) สำหรับฉันดูเหมือนว่าทุกคนควรพยายามมีส่วนร่วมใน Baghunting การทดสอบเชิงสำรวจช่วยให้คุณค้นหากรณีต่างๆ ที่ไม่ได้อธิบายไว้ในแผนการทดสอบ นอกจากนี้ผู้ที่ไม่ทราบโครงการก็สามารถให้ข้อเสนอแนะเกี่ยวกับความสะดวกในการให้บริการได้”
อันโตนินา ทัทชุก บรรณาธิการอาวุโส: “ฉันชอบลองตัวเองในฐานะผู้ทดสอบ นี่เป็นรูปแบบการทำงานที่แตกต่างไปจากเดิมอย่างสิ้นเชิง คุณกำลังพยายามทำลายระบบ ไม่ใช่ผูกมิตรกับมัน เรามีโอกาสถามเพื่อนร่วมงานเกี่ยวกับการทดสอบอยู่เสมอ ฉันเรียนรู้เพิ่มเติมเกี่ยวกับการจัดลำดับความสำคัญของข้อบกพร่อง (เช่น ฉันคุ้นเคยกับการค้นหาข้อผิดพลาดทางไวยากรณ์ในข้อความ แต่ "น้ำหนัก" ของข้อบกพร่องดังกล่าวมีขนาดเล็กมาก และในทางกลับกัน สิ่งที่ดูเหมือนจะไม่สำคัญสำหรับฉันมากนักกลับกลายเป็นว่า ข้อบกพร่องร้ายแรง ซึ่งได้รับการแก้ไขทันที )
ในงานหนุ่มๆ ได้ให้สรุปทฤษฎีการทดสอบ สิ่งนี้มีประโยชน์สำหรับผู้ที่ไม่มีความรู้ทางเทคนิค และไม่กี่วันต่อมา ฉันก็พบว่าตัวเองกำลังคิดว่าฉันกำลังเขียนเพื่อสนับสนุนไซต์อื่นโดยใช้สูตร "อะไร-ที่ไหน-เมื่อไหร่" และอธิบายรายละเอียดความคาดหวังของฉันจากไซต์และความเป็นจริง"
ข้อสรุป
หากคุณต้องการกระจายชีวิตในทีมของคุณ ลองดูฟังก์ชันการทำงานแบบใหม่ และจัดเตรียมมินิ "กินอาหารสุนัขของคุณเอง"จากนั้นคุณสามารถลองจัดงานดังกล่าวแล้วเราจะหารือร่วมกัน
ข้อบกพร่องที่ดีที่สุดและน้อยลง!
ที่มา: will.com