למה ערכנו האקתון לבודקים?

מאמר זה יעניין את מי שכמונו מתמודד עם הבעיה של בחירת מומחה מתאים בתחום הבדיקות.

באופן מוזר, עם הגידול במספר חברות ה-IT ברפובליקה שלנו, רק מספר המתכנתים הראויים גדל, אבל לא הבודקים. אנשים רבים להוטים להיכנס למקצוע זה, אך לא רבים מבינים את משמעותו.

אני לא יכול לדבר בשם כל חברות ה-IT, אבל הטלנו את התפקיד של QA/QC למומחי האיכות שלנו. הם חלק מצוות הפיתוח ומשתתפים בכל שלבי הפיתוח, ממחקר ועד שחרור גרסה חדשה.

בודק בצוות, עוד בשלב התכנון, חייב לחשוב על כל הדרישות הפונקציונליות והלא פונקציונליות לקבלת סיפור משתמש. עליו להבין את המאפיינים התפעוליים של המוצר כמו גם מתכנתים, ואף טוב יותר, ולעזור לצוות לא לקבל החלטות שגויות גם בשלב התכנון. על הבוחן להיות בעל הבנה ברורה כיצד תפעל הפונקציונליות המיושמת ומהם המהמורות שעלולות להיות. הבודקים שלנו יוצרים בעצמם תוכניות בדיקה ומקרי בדיקה, וכן מכינים את כל ספסלי הבדיקה הדרושים. בדיקה לפי מפרט מוכן כמו קליקר של קופים היא לא האופציה שלנו. בעבודה בתוך הצוות, עליו לעזור לשחרר מוצר ראוי ולהשמיע אזעקה בזמן אם משהו ישתבש.

מה נתקלנו כשחיפשנו בודקים

בשלב של לימוד קורות חיים רבים, נראה היה שיש מומחים עם ניסיון מתאים עבורנו ולא יהיו בעיות בבחירת בודק לצוות שלנו. אבל, במהלך פגישות אישיות, נתקלנו יותר ויותר במועמדים שהיו למעשה די רחוקים מעולם טכנולוגיית המידע (למשל, הם לא יכלו לדעת את עקרונות האינטראקציה בין דפדפן לשרת אינטרנט, את יסודות האבטחה, היחסים והלא- מסדי נתונים יחסיים, לא היה להם מושג לגבי וירטואליזציה ומיכליזציה), אך במקביל העריכו את עצמם ברמת QA בכירה. לאחר ביצוע עשרות ראיונות הגענו למסקנה שמספר המומחים המתאימים לנו באזור הוא זניח.

לאחר מכן, אספר לכם אילו צעדים נקטנו ואיזה טעויות דרכנו על מנת למצוא את אותם לוחמים המיוחלים לאיכות.

איך ניסינו לתקן את המצב

לאחר שמיצינו את עצמנו בחיפוש אחר מומחים מוכנים, התחלנו למקד לאזורים סמוכים:

1. ניסינו ליישם שיטות הערכה כדי לזהות בין האנשים הרבים של "עזוב את זה", את אלה שמהם נוכל לפתח מומחים חזקים.

   ביקשנו מקבוצה של מועמדים פוטנציאליים עם אותה רמת ידע לסיים משימות. בהתבוננות בתהליך החשיבה שלהם, ניסינו לזהות את המועמד המבטיח ביותר.

   בפרט, הגענו למשימות לבדיקת תשומת לב, הבנה של יכולות הטכנולוגיה ותכונות הרב-תרבותיות:

   
   

2. קיימנו מפגשי בודקים להרחבת גבולות ההבנה של המקצוע בקרב המשתתפים הקיימים.

   אני אספר לך קצת על כל אחד מהם.

   Ufa Software QA and Testing Meetup #1 הוא הניסיון הראשון שלנו לאסוף את מי שאכפת לו מהמקצוע ובמקביל להבין האם הציבור יתעניין במה שאנחנו רוצים להעביר לו. בעיקרון, הדוחות שלנו היו על היכן עדיף להתחיל אם החלטת להיות בודק. עזרו למתחילים לפקוח את העיניים ולהסתכל על הבדיקה כמו מבוגרים. דיברנו על הצעדים שצריך לנקוט בודקים מתחילים כדי להשתלב במקצוע. על מהי איכות ואיך להשיג אותה בתנאים אמיתיים. וגם, מהי בדיקה אוטומטית ואיפה יותר מתאים להשתמש בה.

   
   
   לאחר מכן, עם מרווח של 1-2 חודשים, ערכנו שני מפגשים נוספים. כבר היו משתתפים כפולים. ב"Ufa Software QA and Testing Meetup #2" צללנו עמוק יותר לתחום הנושא. הם דיברו על מערכות מעקב אחר באגים, בדיקות UI/UX, נגעו ב-Docker, Ansible, וגם דיברו על התנגשויות אפשריות בין מפתח לבוחן ודרכים לפתור אותן.

   הפגישה השלישית שלנו, "Ufa Software QA and Testing Meetup #3", קשורה בעקיפין לעבודתם של בודקים, אך הייתה שימושית להזכיר בזמן למתכנתים את החובות הטכניות והארגוניות שלהם: בדיקות עומס, בדיקות e2e, סלניום בבדיקות אוטומטיות, פגיעויות של יישומי אינטרנט .

   כל הזמן הזה למדנו איך ליצור אור וסאונד רגילים בשידורים מהאירועים שלנו:

   → צעדים ראשונים בבדיקה - Ufa Software QA ו-Testing Meetup #1
   → בדיקות UI/UX - QA של תוכנת Ufa ו-Testing Meetup #2
   → בדיקות אבטחה, בדיקות עומס ובדיקות אוטומטיות - Ufa QA ו-Testing Meetup #3

3. ובסוף החלטנו לנסות לערוך האקתון לטסטרים

איך הכנו וערכנו האקתון לבודקים

מלכתחילה, ניסינו להבין איזו מין "בהמה" זו וכיצד היא מתבצעת בדרך כלל. כפי שהתברר, אירועים מסוג זה לא נערכו פעמים רבות בפדרציה הרוסית, ואין מאיפה לשאול רעיונות. שנית, לא רציתי להשקיע מיד הרבה משאבים באירוע שנראה מפוקפק במבט ראשון. לכן, החלטנו שנעשה מיני-האקתונים קצרים, לא לכל מחזור העבודה של QA, אלא לשלבים בודדים.

כאב הראש העיקרי שלנו הוא חוסר התרגול בקרב בודקים מקומיים ביצירת מפות בדיקה ברורות. הם לא משקיעים זמן במחקר סיפורי משתמשים לפני יישום ויצירת קריטריוני קבלה ברורים למפתחים עבור דרישות פונקציונליות ולא פונקציונליות, ממשק משתמש/UX, אבטחה, עומסי עבודה ועומסי שיא. לכן, החלטנו, לראשונה, לעבור את החלק המעניין והיצירתי ביותר בעבודתם – ניתוח וגיבוש דרישות במהלך מחקר טרום-פרויקט.

הערכנו את מספר המשתתפים הפוטנציאלי והחלטנו שאנחנו צריכים לפחות 5 צבורים לשחרור MVP, 5 מוצרים ו-5 אנשים שיפעלו כבעלי מוצרים, יפענחו צרכים עסקיים ויקבלו החלטות לגבי הגבלות.

הנה מה שקיבלנו: פיגור עבור ההאקתון.

הרעיון המרכזי היה להמציא נושאים רחוקים ככל האפשר מכל עבודתם היומיומית של המשתתפים ולתת להם מרחב דמיון יצירתי.

אילו טעויות עשינו ומה נוכל לעשות טוב יותר?

השימוש בפרקטיקות הערכה, הפופולריות כל כך בתחום גיוס אנשי מכירות ומנהלים בדרגים נמוכים יותר, לקח מאמץ עצום, אך לא אפשר לנו להקדיש תשומת לב מספקת לכל משתתף ולהעריך את יכולותיו. באופן כללי, אפשרות בחירה זו יוצרת תדמית שלילית של החברה, מכיוון שדי הרבה אנשים מקבלים משוב לא מספיק ובעקבות כך יוצרים בעצמם ובאחרים את השפעת העריצות של המעסיק (התקשורת בקהילות IT מפותחת מאוד). כתוצאה מכך, אנחנו נשארים עם שני מועמדים פוטנציאליים, פשוטו כמשמעו, עם עתיד רחוק מאוד.

מפגשים זה דבר טוב. נוצר בסיס נרחב לעיבוד, והרמה הכללית של המשתתפים עולה. החברה הופכת יותר ויותר מוכרת בשוק. אבל עוצמת העבודה של התחייבויות כאלה אינה קטנה. אתה צריך להבין בבירור שקיום מפגשים ייקח בערך 700-800 שעות עבודה בשנה.

באשר להאקתון הבדיקות. אירועים מסוג זה עדיין לא הפכו למשעממים, מכיוון שבניגוד להאקתונים למפתחים, הם מתקיימים בתדירות נמוכה בהרבה. היתרון ברעיון זה הוא שבצורה נינוחה ניתן להחליף כמות גדולה של ידע מעשי ולקבוע בצורה די מדויקת את הרמה של כל משתתף.

לאחר ניתוח תוצאות האירוע, הבנו שעשינו הרבה טעויות:

1. הטעות הכי בלתי נסלחת הייתה להאמין ש-4-5 שעות יספיקו לנו. כתוצאה מכך, רק ההיכרות וההיכרות עם העומס ארכו כמעט שעתיים.
   העבודה עם בעלי המוצרים בשלב הראשוני והזמן לצלילה לתחום הנושא ארכה אותה פרק זמן. אז ברור שהזמן שנותר לא הספיק לפיתוח מקיף של מפות הבדיקה.
2. לא היה מספיק זמן ואנרגיה למשוב מפורט על כל מפה, מכיוון שכבר היה לילה. לכן, ברור שנכשלנו בחלק הזה, אבל בהתחלה נועדנו להיות היקרים ביותר בהאקתון.
3. החלטנו להעריך את איכות הפיתוח בהצבעה פשוטה של ​​כל המשתתפים, תוך הקצאת 3 קולות לכל צוות, שיוכלו לתת עבור העבודה האיכותית ביותר. אולי עדיף לארגן חבר מושבעים.

מה השגת?

פתרנו חלקית את הבעיה שלנו ועכשיו יש לנו 4 גברים אמיצים ויפים שעובדים בשבילנו, המכסים את החלק האחורי של 4 צוותי פיתוח. עדיין לא הבחינו במאגר משמעותי של מועמדים חזקים פוטנציאליים ושינויים מוחשיים ברמת קהילת ה-QA בעיר. אבל יש קצת התקדמות וזה לא יכול אלא לשמוח.

מקור: www.habr.com