บทความนี้จะเป็นประโยชน์สำหรับผู้ที่ประสบปัญหาในการเลือกผู้เชี่ยวชาญที่เหมาะสมในด้านการทดสอบเช่นเดียวกับเรา
น่าแปลกที่เมื่อจำนวน บริษัท ไอทีในสาธารณรัฐของเราเพิ่มขึ้น มีเพียงโปรแกรมเมอร์ที่มีค่าควรเท่านั้นที่เพิ่มขึ้น แต่ไม่ใช่ผู้ทดสอบ หลายคนกระตือรือร้นที่จะเข้าสู่อาชีพนี้ แต่มีน้อยคนที่เข้าใจความหมายของอาชีพนี้
ฉันไม่สามารถพูดแทนบริษัทไอทีได้ทั้งหมด แต่เราได้มอบหมายบทบาทของ QA/QC ให้กับผู้เชี่ยวชาญด้านคุณภาพของเราแล้ว พวกเขาเป็นส่วนหนึ่งของทีมพัฒนาและมีส่วนร่วมในการพัฒนาทุกขั้นตอน ตั้งแต่การวิจัยไปจนถึงการเปิดตัวเวอร์ชันใหม่
ผู้ทดสอบในทีม แม้จะอยู่ในขั้นตอนการวางแผน จะต้องคิดให้ถี่ถ้วนถึงข้อกำหนดเชิงฟังก์ชันและไม่ใช่ฟังก์ชันทั้งหมดในการยอมรับเรื่องราวของผู้ใช้ เขาต้องเข้าใจลักษณะการทำงานของผลิตภัณฑ์ตลอดจนโปรแกรมเมอร์และดียิ่งขึ้น และช่วยให้ทีมไม่ตัดสินใจผิดพลาดแม้ในขั้นตอนการวางแผน ผู้ทดสอบต้องมีความเข้าใจที่ชัดเจนว่าฟังก์ชันที่นำไปใช้งานจะทำงานอย่างไรและอาจมีข้อผิดพลาดอะไรบ้าง ผู้ทดสอบของเราสร้างแผนการทดสอบและกรณีทดสอบด้วยตนเอง รวมทั้งเตรียมม้านั่งทดสอบที่จำเป็นทั้งหมด การทดสอบตามข้อกำหนดสำเร็จรูปเช่นลิงคลิกเกอร์ไม่ใช่ทางเลือกของเรา การทำงานเป็นทีมเขาจะต้องช่วยปล่อยผลิตภัณฑ์ที่คุ้มค่าและส่งเสียงเตือนทันเวลาหากมีสิ่งผิดปกติเกิดขึ้น
สิ่งที่เราพบเมื่อมองหาผู้ทดสอบ
ในขั้นตอนของการศึกษาเรซูเม่หลายๆ ตัว ดูเหมือนว่ามีผู้เชี่ยวชาญที่มีประสบการณ์เหมาะสมกับเรา และการเลือกผู้ทดสอบให้กับทีมของเราก็คงไม่มีปัญหา แต่ในระหว่างการประชุมส่วนตัว เราพบผู้สมัครที่อยู่ห่างไกลจากโลกแห่งเทคโนโลยีสารสนเทศมากขึ้นเรื่อยๆ (เช่น พวกเขาไม่สามารถบอกหลักการของการโต้ตอบระหว่างเบราว์เซอร์และเว็บเซิร์ฟเวอร์ พื้นฐานของความปลอดภัย เชิงสัมพันธ์และไม่ใช่- ฐานข้อมูลเชิงสัมพันธ์ พวกเขาไม่มีแนวคิดเกี่ยวกับการจำลองเสมือนและคอนเทนเนอร์) แต่ในขณะเดียวกันก็ประเมินตนเองในระดับ QA อาวุโส หลังจากสัมภาษณ์หลายสิบครั้ง เราก็ได้ข้อสรุปว่าจำนวนผู้เชี่ยวชาญที่เหมาะสมสำหรับเราในภูมิภาคนั้นมีน้อยมาก
ต่อไป ฉันจะบอกคุณว่าเราทำอะไรไปบ้างและเราทำผิดพลาดอะไรบ้างเพื่อค้นหานักสู้เพื่อคุณภาพที่รอคอยมานาน
เราพยายามแก้ไขสถานการณ์อย่างไร
หลังจากเหน็ดเหนื่อยกับการจัดหาผู้เชี่ยวชาญสำเร็จรูปแล้ว เราจึงเริ่มกำหนดเป้าหมายพื้นที่ใกล้เคียง:
- เราพยายามใช้แนวทางปฏิบัติในการประเมินเพื่อระบุกลุ่มคนที่ "ปล่อยวาง" จำนวนมาก ซึ่งเป็นกลุ่มที่เราสามารถพัฒนาผู้เชี่ยวชาญที่แข็งแกร่งได้
เราขอให้กลุ่มผู้มีโอกาสเป็นผู้สมัครที่มีความรู้ระดับเดียวกันโดยประมาณทำงานให้เสร็จสิ้น จากการสังเกตกระบวนการคิดของพวกเขา เราพยายามระบุผู้สมัครที่มีแนวโน้มมากที่สุด
โดยเฉพาะอย่างยิ่ง เราได้งานมาเพื่อทดสอบความเอาใจใส่ ความเข้าใจในความสามารถของเทคโนโลยี และคุณลักษณะของพหุวัฒนธรรม:
- เราจัดให้มีการพบปะสำหรับผู้ทดสอบเพื่อขยายขอบเขตความเข้าใจในวิชาชีพในกลุ่มผู้ทดสอบที่มีอยู่
ฉันจะบอกคุณเล็กน้อยเกี่ยวกับแต่ละคน
Ufa Software QA และการทดสอบ Meetup #1 เป็นความพยายามครั้งแรกของเราในการรวบรวมผู้ที่ใส่ใจในวิชาชีพนี้ และในขณะเดียวกันก็เข้าใจว่าสาธารณชนจะสนใจในสิ่งที่เราต้องการสื่อถึงพวกเขาหรือไม่ โดยพื้นฐานแล้ว รายงานของเราเกี่ยวกับจุดเริ่มต้นที่ดีกว่าหากคุณตัดสินใจเป็นผู้ทดสอบ ช่วยให้ผู้เริ่มต้นลืมตาและมองการทดสอบเหมือนผู้ใหญ่ เราได้พูดคุยเกี่ยวกับขั้นตอนที่ผู้ทดสอบมือใหม่ต้องทำเพื่อเข้าร่วมอาชีพนี้ เกี่ยวกับคุณภาพและวิธีการบรรลุผลในสภาวะจริง และการทดสอบอัตโนมัติคืออะไร และที่ใดที่เหมาะสมกว่าในการใช้งาน
จากนั้นด้วยช่วงเวลา 1-2 เดือน เราก็ได้จัดมีตติ้งอีกสองครั้ง มีผู้เข้าร่วมมากกว่าสองเท่าแล้ว ที่ “Ufa Software QA และการทดสอบ Meetup #2” เราได้เจาะลึกเนื้อหามากขึ้น พวกเขาพูดคุยเกี่ยวกับระบบติดตามจุดบกพร่อง การทดสอบ UI/UX กล่าวถึง Docker, Ansible และยังพูดคุยเกี่ยวกับข้อขัดแย้งที่อาจเกิดขึ้นระหว่างนักพัฒนาและผู้ทดสอบ ตลอดจนวิธีแก้ไขการประชุมครั้งที่สามของเรา “Ufa Software QA และ Testing Meetup #3” เกี่ยวข้องทางอ้อมกับงานของผู้ทดสอบ แต่มีประโยชน์ในการเตือนโปรแกรมเมอร์ถึงหน้าที่ด้านเทคนิคและองค์กรของพวกเขาอย่างทันท่วงที: การทดสอบโหลด การทดสอบ e2e ซีลีเนียมในการทดสอบอัตโนมัติ ช่องโหว่ของแอปพลิเคชันบนเว็บ .
ตลอดเวลานี้ เราได้เรียนรู้วิธีสร้างแสงและเสียงตามปกติในการออกอากาศจากกิจกรรมของเรา:
→
ขั้นตอนแรกในการทดสอบ – Ufa Software QA และการทดสอบ Meetup #1
→การทดสอบ UI/UX – Ufa Software QA และการทดสอบ Meetup #2
→การทดสอบความปลอดภัย การทดสอบโหลด และการทดสอบอัตโนมัติ – Ufa QA และการทดสอบ Meetup #3 - และในท้ายที่สุด เราก็ตัดสินใจที่จะพยายามจัดแฮ็กกาธอนสำหรับผู้ทดสอบ
วิธีที่เราเตรียมและดำเนินการแฮ็กกาธอนสำหรับผู้ทดสอบ
ขั้นแรกเราพยายามทำความเข้าใจว่านี่คือ "สัตว์ร้าย" แบบไหนและโดยปกติแล้วจะปฏิบัติอย่างไร ปรากฎว่ากิจกรรมประเภทนี้ไม่ได้จัดขึ้นหลายครั้งในสหพันธรัฐรัสเซีย และไม่มีที่ไหนให้ยืมแนวคิด ประการที่สอง ฉันไม่ต้องการลงทุนทรัพยากรจำนวนมากในทันทีกับเหตุการณ์ที่ดูน่าสงสัยเมื่อมองแวบแรก ดังนั้นเราจึงตัดสินใจว่าจะทำมินิแฮ็กกาธอนสั้นๆ ไม่ใช่สำหรับวงจรงาน QA ทั้งหมด แต่สำหรับแต่ละขั้นตอน
อาการปวดหัวหลักของเราคือการขาดแนวทางปฏิบัติในหมู่ผู้ทดสอบในพื้นที่ในการสร้างแผนที่การทดสอบที่ชัดเจน พวกเขาไม่ใช้เวลาค้นคว้าเรื่องราวของผู้ใช้ก่อนการใช้งาน และสร้างเกณฑ์การยอมรับที่ชัดเจนสำหรับนักพัฒนาสำหรับข้อกำหนดด้านการทำงานและที่ไม่เกี่ยวกับฟังก์ชัน, UI/UX, ความปลอดภัย, ปริมาณงาน และโหลดสูงสุด ดังนั้นเราจึงตัดสินใจเป็นครั้งแรกที่จะผ่านส่วนที่น่าสนใจและสร้างสรรค์ที่สุดในงานของพวกเขา - การวิเคราะห์และการสร้างข้อกำหนดระหว่างการวิจัยก่อนโครงการ
เราประเมินจำนวนผู้เข้าร่วมที่เป็นไปได้และตัดสินใจว่าเราต้องการรายการค้างอย่างน้อย 5 รายการสำหรับการเปิดตัว MVP ผลิตภัณฑ์ 5 รายการ และบุคคล 5 คนที่จะทำหน้าที่เป็นเจ้าของผลิตภัณฑ์ ถอดรหัสความต้องการทางธุรกิจ และตัดสินใจเกี่ยวกับข้อจำกัด
นี่คือสิ่งที่เราได้รับ:
แนวคิดหลักคือการสร้างหัวข้อที่ห่างไกลจากงานประจำวันของผู้เข้าร่วมทั้งหมดมากที่สุดเท่าที่จะเป็นไปได้ และเพื่อให้พวกเขามีขอบเขตในการสร้างสรรค์จินตนาการ
เราทำผิดพลาดอะไรและเราจะทำอะไรได้ดีขึ้น?
การใช้แนวทางปฏิบัติในการประเมินซึ่งได้รับความนิยมอย่างมากในด้านการจ้างพนักงานขายและผู้จัดการระดับล่างนั้นต้องใช้ความพยายามอย่างมาก แต่ไม่ได้ทำให้เราให้ความสนใจเพียงพอกับผู้เข้าร่วมแต่ละคนและประเมินความสามารถของเขา โดยทั่วไปตัวเลือกการเลือกนี้จะสร้างภาพลักษณ์เชิงลบของ บริษัท เนื่องจากผู้คนจำนวนมากได้รับการตอบรับไม่เพียงพอและต่อมาก็สร้างผลกระทบจากการกดขี่ของนายจ้างในตัวเองและผู้อื่น (การสื่อสารในชุมชนไอทีได้รับการพัฒนาอย่างมาก) เป็นผลให้เราเหลือผู้สมัครที่มีศักยภาพสองคนซึ่งมีอนาคตอันไกลโพ้นมาก
การพบปะเป็นสิ่งที่ดี มีการสร้างพื้นฐานที่ครอบคลุมสำหรับการทำอย่างละเอียด และระดับทั่วไปของผู้เข้าร่วมจะเพิ่มขึ้น บริษัทเริ่มเป็นที่รู้จักในตลาดมากขึ้นเรื่อยๆ แต่ความเข้มข้นของแรงงานในการดำเนินการดังกล่าวมีไม่น้อย คุณต้องเข้าใจให้ชัดเจนว่าการจัดมีตติ้งจะใช้เวลาประมาณ 700-800 ชั่วโมงคนต่อปี
ในส่วนของการทดสอบ Hackathon กิจกรรมประเภทนี้ยังไม่น่าเบื่อ เนื่องจากกิจกรรมเหล่านี้ไม่เหมือนกับแฮ็กกาธอนสำหรับนักพัฒนาตรงตรงที่จัดขึ้นน้อยกว่ามาก ข้อดีของแนวคิดนี้คือคุณสามารถแลกเปลี่ยนความรู้เชิงปฏิบัติจำนวนมากได้อย่างผ่อนคลาย และกำหนดระดับของผู้เข้าร่วมแต่ละคนได้อย่างแม่นยำ
หลังจากวิเคราะห์ผลลัพธ์ของกิจกรรม เราพบว่าเราทำผิดพลาดมากมาย:
- ความผิดพลาดที่ไม่อาจให้อภัยได้มากที่สุดคือการเชื่อว่า 4-5 ชั่วโมงก็เพียงพอสำหรับเรา เป็นผลให้เพียงการแนะนำและทำความคุ้นเคยกับ Backlogs ใช้เวลาเกือบ 2 ชั่วโมง
การทำงานร่วมกับเจ้าของผลิตภัณฑ์ในระยะเริ่มแรกและเวลาในการเจาะลึกในพื้นที่นั้นใช้เวลาเท่ากัน ดังนั้นเวลาที่เหลือจึงไม่เพียงพอสำหรับการพัฒนาแผนที่ทดสอบอย่างครอบคลุม - มีเวลาและพลังงานไม่เพียงพอสำหรับข้อเสนอแนะโดยละเอียดในแต่ละแผนที่ เนื่องจากเป็นเวลากลางคืนแล้ว ดังนั้นเราจึงล้มเหลวอย่างชัดเจนในส่วนนี้ แต่ในตอนแรกตั้งใจว่าจะให้มีคุณค่ามากที่สุดในแฮ็กกาธอน
- เราตัดสินใจประเมินคุณภาพการพัฒนาด้วยการโหวตง่ายๆ ของผู้เข้าร่วมทั้งหมด โดยจัดสรร 3 คะแนนสำหรับแต่ละทีม ซึ่งพวกเขาสามารถให้คะแนนได้สำหรับงานที่มีคุณภาพสูงสุด บางทีอาจเป็นการดีกว่าถ้าจัดคณะลูกขุน
คุณประสบความสำเร็จอะไร?
เราได้แก้ไขปัญหาของเราไปแล้วบางส่วน และตอนนี้เรามีผู้ชายหล่อผู้กล้าหาญ 4 คนที่ทำงานให้กับเรา ซึ่งอยู่ด้านหลังทีมพัฒนา 4 คน ยังไม่มีใครสังเกตเห็นกลุ่มผู้สมัครที่แข็งแกร่งที่มีศักยภาพและการเปลี่ยนแปลงที่จับต้องได้ในระดับชุมชน QA ของเมือง แต่มีความคืบหน้าอยู่บ้างและสิ่งนี้ก็อดไม่ได้ที่จะชื่นชมยินดี
ที่มา: will.com