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

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

לאחר שקלטנו וכתבנו את התקנון, שלחנו הזמנה לכל הערוצים ב-Slack הארגוני, שלא כללה הגבלות כלשהן:

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

למה?

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

היו לנו כמה מטרות.

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

Реализация

היום שלנו כלל מספר בלוקים:

• תִדרוּך;
• הרצאה קצרה בנושא בדיקות, שבה נגענו רק בנקודות העיקריות (יעדי ועקרונות הבדיקה וכו');
• סעיף בנושא "כללי נימוסים טובים" בעת הצגת באגים (כאן העקרונות מתוארים היטב);
• ארבעה מפגשי בדיקה לפרויקטים עם תרחישים מתוארים ברמה גבוהה; לפני כל מפגש התקיימה הרצאת מבוא קצרה על הפרויקט וחלוקה לצוותים;
• סקר קצר על האירוע;
• תִמצוּת.

(לא שכחנו גם הפסקות בין מפגשים לארוחת צהריים).

כללי יסוד

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

פרטים נוספים

• בתחילה, רציתי לעשות אירוע בדיקה "מתקדם", אבל... לא מעט חבר'ה מצוותים שאינם מוצרים נרשמו (SMM, עורכי דין, יחסי ציבור), היינו צריכים לפשט מאוד את התוכן ולהסיר תיקים מורכבים/פרופילים.
• עקב עבודת יחידות בג'ירה בפרויקטים שונים, לפי הזרימה שלנו, יצרנו במיוחד פרויקט נפרד בו הקמנו תבנית להכנסת באגים.
• כדי לחשב נקודות, הם תכננו להשתמש ב-leaderboard שעודכן באמצעות webhooks, אבל משהו השתבש ובסופו של דבר החישוב היה צריך להתבצע באופן ידני.

כולם נתקלים בבעיות בעת ארגון אירועים, וכדי להקל עליכם מעט, אתאר את הבעיות שלנו שתוכלו להימנע מהן.

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

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

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

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

נקודות ארגוניות שימושיות:

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

ממצאים

במהלך כל היום, החבר'ה הצליחו לבדוק 4 פרויקטים וליצור 192 באגים (מתוכם 134 היו ייחודיים) ו-7 בעיות עם בקשות תכונה. כמובן, בעלי הפרויקט כבר ידעו על חלק מהבאגים הללו. אבל היו גם ממצאים בלתי צפויים.

כל המשתתפים קיבלו פרסים מתוקים.

והמנצחים הם תרמוסים, תגים, סווטשירטים.

מה שיצא מעניין:

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

מה ניתן לשפר:

• לעשות פחות פרויקטים ולהגדיל את זמן הפגישה ל-1,5 שעות;
• להכין מתנות/מזכרות הרבה מראש (לפעמים אישור/תשלום לוקח חודש);
• תירגע וקבל שמשהו לא ילך לפי התוכנית ויהיה כוח עליון.

הערכות

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

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

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

מסקנה

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

כל הכבוד ופחות באגים!

מקור: www.habr.com