תארו לעצמכם שהתוכנה החשובה ביותר של החברה שלכם קורסת פתאום – מה היה קורה? אתם עלולים לאבד הזמנות ופספסת מועדים אחרונים, אבל ברור ללקוחות שהם מתלוננים.
אפשר להימנע מתרחיש הסיוט הזה: תהליך בדיקה רציף וקפדני, שפותח את הבעיות לפני שהן גורמות לכאוס. אבל קל יותר לומר שקל יותר ליישם תהליך כזה בארגון.
במאמר הזה נסביר את כל מה שצריך לחשוב כשמתחילים לבצע בדיקות בחברה, ואיך להפיק תועלת מבדיקות בטווח הארוך.
בדיקת שיטות מומלצות לצוותי מוצרים
בחלק הראשון של המאמר מוסבר איך מתחילים להטמיע בדיקות בתהליך העבודה.
להטמיע תרבות בדיקות בצוות
כדי להוסיף בדיקות בהצלחה לצוות, כולם צריכים לחלוק את הלך הרוח שלהם ולהראות שהאיכות היא לא נטל, אלא כהשקעה. זה תהליך שכמו כל שינוי תרבותי אחר, דורש זמן ועקביות.
אחד הדברים שיכולים לעזור לעצב את התרבות הזו הוא פגישות קבועות שבהן נדון בתקלות, בהשפעה שלהן, מאיפה הן הגיעו ומה נדרש כדי לתקן אותן. כך אפשר להגביר את המוּדעוּת למה כדאי למנוע פגמים כאלה מלכתחילה.
הוספת אדם מסור לצוות שמפקח על המאמצים ומובילה אותם יכולה להגדיל משמעותית את הסיכויים להצלחה. מישהו שמגדיר הנחיות לצוותים או אפילו ברמת הארגון, אוסף שיטות מומלצות, משתף אותן ותומך במאמצים שאתם משקיעים ברמות השונות.
עוד כלי שימושי הוא רוטציה של תפקיד התמיכה של המוצר. קבלת תובנות ישירות מהלקוחות, בלי סינון, ולמידה על הבעיות היומיומיות שאיתם הן מתמודדים עם המוצר יכולות להיות חוויה רבת-ערך למנהלי מוצרים, למעצבים ולמפתחים.
המטרה היא שכל חברי הצוות יבינו שאיכות היא תכונה, וחשובה כמו כל פונקציונליות אחרת שאתם מפתחים למוצר. ברגע שכולם אימצו את הלך הרוח הזה, טבעי שהם יבינו שגם בדיקות הן תכונה. כי בדיקות הן אלה שמבטיחות את איכות המשלוח.
תהליך בדיקה שלב אחר שלב
ברגע שתהיה התאמה בין הצוותים השונים שמעורבים בפיתוח המוצרים, תוכלו להמשיך להגדיר את קיום הבדיקות ואת השימוש בהן.
להפוך את הבדיקות לחלק מ'הגדרת הסיום'
כשמוסיפים בדיקות כדרישה לתכונה, מצהירים שתכונה לא מוכנה לשליחה עד שהיא נבדקת כראוי ונבדקת באופן אוטומטי
הרצת בדיקות באופן קבוע
אחרי ההטמעה של הבדיקות האוטומטיות, תוכלו להגן עליכם בכל שלב בתהליך הפיתוח. אין צורך בהתערבות אנושית, ואפשר להריץ אותם בכל שלב קריטי בצינור עיבוד הנתונים. למשל:
- בכל התחייבות.
- על כל בקשת משיכה.
- אחרי כל גרסה מלאה או שינוי בסביבה.
אם אתם מסתמכים על שירותים של צד שלישי בסביבת הייצור, כדאי אפילו להריץ בדיקות מול סביבת ייצור כדי לוודא שממשקי API של צד שלישי יפעלו כצפוי.
הגדרה ואיסוף של מדדים
כדי למדוד את היעילות של הבדיקות ואת ההשפעה של תהליכי העבודה של בדיקות על העסק, חשוב להגדיר קבוצת מדדים. הנה כמה דוגמאות למדדים שבהם תוכל להשתמש:
- גרסאות בחודש: מספר גבוה יותר של גרסאות בחודש יכול להצביע על תהליך פיתוח גמיש יותר. לבדיקות אוטומטיות יש תפקיד חשוב בכך שמוודאים שגרסאות יכולות להמשיך בבטחה.
- דוחות על באגים: ירידה בדוחות על באגים יכולה להיות סימן חיובי לכך שהבדיקות (ותהליכי הפיתוח) יעילים.
- כיסוי בדיקה: אמנם אף פעם לא מדד מדויק, אבל הכיסוי יכול להצביע על מידת העומק של הבדיקה של תרחישים קריטיים לדוגמה.
חשוב לציין שהמדדים האלה מושפעים גם מגורמים אחרים שעשויים להטות אותם. לדוגמה, מספר הגרסאות עשוי לרדת בתקופת החגים, ובאותו הזמן יש עלייה בדוחות הבאגים. לכן, לא כדאי להסתמך רק על כמה מהם, ולמפות אותן בהתאם לנתונים אחרים שזמינים לצוות שלכם.
אם תטמיעו את השלבים האלה בהצלחה עם הצוות, תקינות המוצר תועיל בהחלט בטווח הארוך. אבל עדיין יש עוד הרבה מה לעשות.
בדיקת שיטות מומלצות למנהלי מערכות
צוותי המוצרים לא יכולים לעבוד בעצמם. הם מסתמכים על החומרה, הכלים והתשתית שמנהלי המערכת מנהלים. למרות שאדמינים של מערכות בדרך כלל לא תורמים ישירות לפיתוח המוצר, הם עדיין יכולים להשפיע לטובה על תהליך הפיתוח. לדוגמה, על ידי ניהול פעיל של גרסת הדפדפן שבה משתמשים קבוצות מסוימות של משתמשים בחברה.
החלק השני של המאמר מסביר איך זה עובד, באמצעות הערוצים ומדיניות הארגון של Chrome.
ערוצי ההפצה של Chrome
כברירת מחדל, Chrome מתעדכן אוטומטית כדי להבטיח שכל משתמש יפעיל את הגרסה האחרונה, היציבה והמאובטחת ביותר של Chrome, כולל כל התכונות החדשות – גרסת Chrome שפורסמה בערוץ היציב.
כחברה שמפתחת מוצר מבוסס-אינטרנט, ייתכן שתרצו להשתמש בדפדפן לפני הערוץ היציב, כדי לתת לצוותי המוצר שלכם זמן להתאים את המוצר לשינויים בפלטפורמת האינטרנט.
בתרחיש לדוגמה הזה, ב-Chrome יש ארבעה ערוצי הפצה שמיועדים לקבוצות שונות של משתמשים.
ב-Chrome יש ערוצי הפצה שונים שבהם אפשר להשתמש כדי לצפות שינויים עתידיים בדפדפן ולבדוק את התכונות החדשות לפני שהן זמינות לכולם:
- הערוץ היציב: זה המקום שבו נמצאים רוב המשתמשים. הערוץ היציב מתעדכן באופן אוטומטי כשיש גרסה חדשה של Chrome, שמתרחשת מדי חודש.
- ערוץ הבטא: הגרסה הזו תשתפר תוך ארבעה עד שישה שבועות, ותספק לכם הזדמנות לקבל תצוגה מקדימה ולבדוק את הגרסה היציבה הבאה ולהתכונן לקראתה.
- ערוץ הפיתוח: הערוץ מקבל גרסה חדשה של Chrome פעם בשבוע, והוא כולל את כל התיקונים האחרונים שיעברו בסופו של דבר לגרסת בטא. כפי שמרמז שם הערוץ, הוא נמצא בפיתוח ולכן הוא עלול לקרוס לא צפוי – אבל הוא כולל גם את התכונות החדשות ביותר, לפעמים זמן רב לפני שהן הופכות ליציבות. לכן ערוץ הפיתוח הוא כלי נהדר ליצירת אב טיפוס ולפיתוח חדשני.
- Canary channel (ערוץ Canary): הערוץ הניסיוני ביותר, שמכיל את כל התכונות החדשות, אבל בלי לבצע הרבה בדיקות. לפחות מדי יום.
למידע נוסף על הערוצים של Chrome, תוכלו לקרוא את הפרק הרלוונטי של Chrome Concepts.
שימוש בערוצים בארגון למופת
המבנה של צוותי המוצרים משתנה בין ארגונים, כי אין גישה אחת שמתאימה לכולם לפיתוח תוכנה. לדוגמה, ניקח צוות עם התפקידים הבאים: ניהול מוצר, חוויית משתמש וממשק משתמש, הנדסה, תפעול ותמיכה.
לארגון כזה, כדאי לחשוב על פיצול הערוצים הבא:
- ניהול מוצר: מנהלי מוצר יכולים להיות בדרך כלל בערוץ היציב, על מנת להשתמש באותה גרסה כמו רוב המשתמשים. מדי פעם הם יכולים להשתמש בערוץ בטא או dev אם הם עובדים על תכונה שדורשת API שעדיין לא הושק.
- הנדסה וחוויית המשתמש: חלקים מהצוותים האלה יכולים להיות בערוץ dev כדי לתת להם גישה לתכונות העדכניות ביותר, כמו View מעברים, עוד לפני שהם יציבים.
- פעולות: יכול להיות בבטא, כדי לחזות שההפסקה תשפיע על המשתמשים בהמשך.
- תמיכה: יכולים להישאר בערוץ היציב, כדי לוודא שהם מקיימים אינטראקציה עם המוצר באמצעות אותו דפדפן כמו רוב הלקוחות שלכם.
שימוש במדיניות ארגונית לניהול ערוצים
במקום לתת הנחיות והחלטה באיזה ערוץ להשתמש, Chrome מציע גם כלים לארגון ולניהול שמאפשרים לנהל באופן פעיל את הערוץ שבו כל משתמש ישתמש. זו שיטה שימושית כי היא מגדילה באופן מיידי את שטח הבדיקה ממספר אנשים פרטיים לקבוצת משתמשים דטרמיניסטית, ועוזרת לזהות תקלות מוקדם ככל האפשר ובצורה שבה אפשר לעקוב.
אם אתם רוצים להשתמש ברמה כזו של שליטה, אנחנו ממליצים להשתמש בהגדרות הבאות:
- עובדים (משתמשי האפליקציה): כדי למזער את הסיכון לשיבושים, רוב העובדים צריכים להיות בערוץ היציב, שנבדק באופן מלא על ידי צוות הבדיקה של Chrome. בנוסף, אחוז קטן מהמשתמשים (מ-5 עד 10%) יכול להיות בערוץ בטא. לערוץ הזה יש גרסת טרום-השקה יציבה של 4-6 שבועות, ויכול לעזור לאדמינים לגלות בעיות אפשריות בגרסה, וכך לתת יותר זמן לטפל בבעיות לפני השקת הגרסה.
- מחלקת IT: חברים במחלקת ה-IT, כולל מנהלי מערכת בעצמם, יכולים להיות בערוץ בטא או בערוץ dev, כדי לקבל תצוגה מקדימה של 4-6 או 9-12 שבועות לקראת הגרסה היציבה של Chrome.
ערוצי הפצה לטווח ארוך
יכול להיות שפיתוח המוצר לא יתקדם בקצב המתוכנן, וקצב ההפצה של Chrome בחודש עשוי להיות גבוה מדי. בתרחיש לדוגמה הזה, Chrome מספק ערוץ יציב מורחב שמאפשר לקבל עדכוני תכונות בתדירות נמוכה יותר, אבל עדיין לקבל תיקוני אבטחה. ערוץ זה מתעדכן מדי שמונה שבועות.
בתרשים הבא מוצג האופן שבו אבני דרך שונות ממשיכות דרך ערוצי ההפצה השונים של Chrome:
- גם הגרסה היציבה וגם היציבה המורחבת שולחת את אותן הגרסאות במהלך ארבעת השבועות הראשונים, ולאחר מכן שתי הגרסאות מתפצלות.
- אין ערוץ בטא מורחב. במקום זאת, מחזור הבטא הסטנדרטי של ארבעה שבועות משמש כדי לייצב גם את היציב וגם את היציבות המורחבת. ארגונים שיבחרו להצטרף ליציבות המורחבת של שמונה שבועות צריכים להמשיך להפעיל את ערוץ הבטא כפי שהם עושים היום, כדי לזהות באופן יזום בעיות שעלולות להשפיע על הסביבות שלהם.
סיכום
בדיקות הן חלק חיוני בחברות לפיתוח תוכנות כדי להבטיח את איכות המוצרים שלהן, וגם הוא שלב חשוב מבחינת מנהלי המערכת – כדי לתת לעובדים בארגון גישה לתוכנות באיכות גבוהה ולמנוע שיבושים בתהליכים עסקיים.
כדי להצליח ביישום תהליך עבודה של בדיקות בארגון, חשוב שכולם יהיו חולקים את הלך הרוח המשותף, ולכן גם הבדיקה היא תכונה.
במאמר הזה, סקרנו דרכים שונות לשילוב שיטות מומלצות לביצוע בדיקות בארגון שלכם. כדי להכיר לעומק את כלי הבדיקה הקיימים, כדאי לקרוא את המאמר כלים מ-Chrome לבדיקות אוטומטיות וחלקות.
לקבלת הדרכה מעשית לביצוע בדיקות, מההתחלה ועד הסוף, אפשר לעיין גם בקורס 'לימודי בדיקה' שקיימנו לאחרונה ובשיטות המומלצות לאוטומציה של בדיקות ב-web.dev.