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