תארו לעצמכם שהתוכנה הכי חשובה בחברה שלכם פתאום מפסיקה לפעול – מה יקרה? יכול להיות שהזמנות יאבדו או שלא תעמדו בלוחות זמנים, אבל בטוח שהלקוחות יתלוננו.
אפשר להימנע מהסיוט הזה: צריך להטמיע תהליך בדיקה רציף וקפדני, שיזהה בעיות לפני שהן יגרמו לבלגן. אבל קשה ליישם תהליך כזה בארגון.
במאמר הזה נסביר מה צריך לקחת בחשבון כשמתחילים לבצע בדיקות בחברה, ואיך אפשר להפיק תועלת מבדיקות בטווח הארוך.
שיטות מומלצות לבדיקות לצוותי מוצרים
בחלק הראשון של המאמר הזה נסביר איך להתחיל להטמיע בדיקות בתהליך העבודה.
איך מטמיעים תרבות של בדיקות בצוות
כדי להטמיע בהצלחה בדיקות בצוות, כולם צריכים לחשוב באותו אופן ולראות באיכות השקעה ולא נטל. זהו תהליך שדורש זמן ועקביות, כמו כל שינוי תרבותי אחר.
אחת הדרכים לעצב את התרבות הזו היא לקיים פגישות קבועות כדי לדון בפגמים, בהשפעה שלהם, במקור שלהם ובמה שנדרש כדי לתקן אותם. כך אפשר להעלות את המודעות לחשיבות של מניעת פגמים כאלה מלכתחילה.
אם יהיה בצוות אדם ייעודי שיפקח על המאמץ ויקדם אותו, הסיכוי להצלחה יגדל משמעותית. מישהו שמגדיר הנחיות לצוות – או אפילו לארגון כולו – אוסף שיטות מומלצות ומשתף אותן, ופועל לקידום המאמץ בכל הרמות.
כלי שימושי נוסף הוא שינוי תפקיד התמיכה של המוצר. קבלת תובנות ישירות ולא מסוננות מהלקוחות ולמידה על הבעיות היומיומיות שהם נתקלים בהן במוצר שלכם יכולה להיות חוויה חשובה למנהלי מוצרים, למעצבים ולמפתחים.
המטרה היא שכל אחד בצוות יבין שאיכות היא תכונה, חשובה לא פחות מכל פונקציונליות אחרת שאתם מפתחים למוצר. אחרי שכולם אימצו את הגישה הזו, זה היה טבעי להבין שגם בדיקות הן תכונה. כי הבדיקות הן אלה שמבטיחות את האיכות של המוצר שנשלח.
תהליך בדיקה מפורט
אחרי שכל הצוותים שמעורבים בפיתוח המוצר יגיעו להסכמה, תוכלו להגדיר את קיומם של הבדיקות ואת השימוש בהן באופן רשמי יותר.
הוספת בדיקות ל-Definition of Done
כשמוסיפים בדיקות כדרישה לתכונה, מציינים שהתכונה לא מוכנה להשקה עד שהיא נבדקת בצורה נכונה ואוטומטית.
הרצת בדיקות באופן קבוע
אחרי ההטמעה, בדיקות אוטומטיות יכולות לשמש כהגנה בכל שלב בתהליך הפיתוח. הם לא דורשים התערבות אנושית, ואפשר להפעיל אותם בכל שלב קריטי בצינור הפיתוח. לדוגמה:
- בכל קומיט.
- בכל בקשת משיכה.
- אחרי כל גרסה מלאה או שינוי בסביבה.
אם אתם מסתמכים על שירותי צד שלישי בסביבת הייצור, יכול להיות שיהיה הגיוני להריץ את הבדיקות מול סביבת הייצור כדי לוודא שממשקי ה-API של הצד השלישי פועלים כמצופה.
הגדרה ואיסוף של מדדים
חשוב להגדיר קבוצה של מדדים כדי למדוד את האפקטיביות של הבדיקות ואת ההשפעה של תהליכי העבודה של הבדיקות על העסק. הנה כמה דוגמאות למדדים שאפשר להשתמש בהם:
- גרסאות חדשות בחודש: מספר גבוה יותר של גרסאות חדשות בחודש יכול להעיד על תהליך פיתוח גמיש יותר. במקרה הזה, בדיקות אוטומטיות ממלאות תפקיד חשוב, כי הן מבטיחות שאפשר להמשיך בתהליך ההפצה בביטחון.
- דוחות איתור באגים: מגמת ירידה בדוחות איתור באגים יכולה להיות סימן חיובי לכך שהבדיקות (ותהליכי הפיתוח) שלכם יעילים.
- כיסוי הבדיקות: זהו לא מדד מדויק, אבל הוא יכול להצביע על עומק הבדיקות של תרחישי שימוש קריטיים.
חשוב לזכור שהמדדים האלה מושפעים גם מגורמים אחרים, ולכן יכול להיות שהם לא מדויקים. לדוגמה, יכול להיות שמספר הגרסאות שלכם יירד בתקופת החגים, ומספר דוחות הבאגים יעלה. לכן, אל תסתמכו רק על כמה נתונים, והקפידו למפות אותם עם נתונים אחרים שזמינים לצוות שלכם.
אם תיישמו את השלבים האלה עם הצוות שלכם, אין ספק שבריאות המוצר תשתפר בטווח הארוך. אבל יש עוד דברים שאפשר לעשות!
שיטות מומלצות לבדיקה לאדמינים של מערכות
צוותי מוצר לא יכולים לעבוד לבד. הם מסתמכים על החומרה, הכלים והתשתית שמתוחזקים על ידי אדמינים של המערכת. אדמינים של מערכות בדרך כלל לא תורמים ישירות לפיתוח המוצר, אבל הם עדיין יכולים להשפיע לטובה על תהליך העבודה של הפיתוח. לדוגמה, על ידי ניהול פעיל של גרסת הדפדפן שבה משתמשות קבוצות משתמשים מסוימות בחברה.
בחלק השני של המאמר מוסבר איך זה עובד באמצעות הערוצים ומדיניות הארגון של Chrome.
ערוצי הפצה של Chrome
כברירת מחדל, Chrome מתעדכן אוטומטית כדי להבטיח שכל משתמש יפעיל את הגרסה העדכנית, היציבה והמאובטחת ביותר של Chrome, כולל כל התכונות החדשות – הגרסה של Chrome שפורסמה בערוץ היציב.
אם אתם חברה שמפתחת מוצר מבוסס-אינטרנט, יכול להיות שתרצו להשתמש בדפדפן לפני שהוא מגיע לערוץ היציב, כדי לתת לצוותי המוצר שלכם זמן להתאים את המוצר לשינויים בפלטפורמת האינטרנט.
בתרחיש לדוגמה הזה, Chrome מציע ארבעה ערוצי הפצה שנועדו לקבוצות משתמשים שונות.
במקרה של Chrome, יש ערוצי הפצה שונים שבהם אפשר להשתמש כדי לצפות מראש שינויים עתידיים בדפדפן ולבדוק את התכונות החדשות לפני שהן זמינות לכולם:
- ערוץ יציב: רוב המשתמשים נמצאים כאן. העדכונים בערוץ היציב מתבצעים אוטומטית כשיש גרסה חדשה של Chrome, וזה קורה מדי חודש.
- ערוץ בטא: הגרסה הזו תהפוך ליציבה תוך ארבעה עד שישה שבועות. תוכלו לראות תצוגה מקדימה של גרסה יציבה עתידית ולבדוק אותה, ולהתכונן לקראת השימוש בה.
- Dev channel: בערוץ הזה מתפרסמת גרסה חדשה של Chrome פעם בשבוע, והיא כוללת את כל התיקונים האחרונים שיועברו בסופו של דבר לגרסת בטא. כפי שאפשר להבין משם הערוץ, הוא נמצא בפיתוח ולכן יכול להיות שהוא יפסיק לפעול באופן בלתי צפוי. עם זאת, הוא כולל גם את התכונות החדשות ביותר, לפעמים הרבה לפני שהן מגיעות לגרסה היציבה. לכן, ערוץ הפיתוח הוא כלי מצוין ליצירת אב טיפוס ולפיתוח מתקדם.
- ערוץ קנרי: הערוץ הניסיוני ביותר, שמכיל את כל התכונות העדכניות ביותר אבל לא נבדק הרבה. לפחות פעם ביום.
אם אתם רוצים לקבל מידע נוסף על הערוצים של Chrome, כדאי לצפות בפרק הרלוונטי של Chrome Concepts.
שימוש בערוצים בארגון לדוגמה
המבנה של צוותי המוצר משתנה בין ארגונים, כי אין גישה אחת שמתאימה לכולם בפיתוח תוכנה. לדוגמה, נניח שיש צוות עם התפקידים הבאים: ניהול מוצר, UX ו-UI, הנדסה, תפעול ותמיכה.
בארגון כזה, אפשר לחלק את הערוצים באופן הבא:
- ניהול מוצרים: מנהלי מוצרים יכולים בדרך כלל להשתמש בערוץ היציב, כדי להשתמש באותה גרסה כמו רוב המשתמשים. לפעמים הם יכולים להשתמש בערוץ beta או dev אם הם עובדים על תכונה שנדרש בשבילה API שלא הושק עדיין.
- הנדסה וחוויית משתמש: חלק מהצוותים האלה יכולים להשתמש בערוץ dev כדי לקבל גישה לתכונות החדשות ביותר, כמו View Transitions, עוד לפני שהן מגיעות לגרסה יציבה.
- פעולות: יכול להיות שיהיה בבטא, כדי לחזות שיבושים שישפיעו על המשתמשים בהמשך.
- תמיכה: יכולים להישאר בערוץ היציב כדי לוודא שהם משתמשים במוצר באותו דפדפן שבו משתמשים רוב הלקוחות שלכם.
שימוש בכללי מדיניות ארגונית לניהול ערוצים
במקום לתת הנחיות ולהשאיר את ההחלטה לגבי הערוץ לשימוש, Chrome מציע גם כלים לארגונים ולניהול כדי לנהל באופן פעיל את הערוץ שבו כל משתמש משתמש. השימוש בשיטה הזו מועיל כי הוא מגדיל באופן מיידי את היקף הבדיקה מכמה משתמשים בודדים לקבוצה דטרמיניסטית של משתמשים. כך אפשר לזהות בעיות בשלב מוקדם ככל האפשר ובאופן שניתן למעקב.
אם אתם רוצים להשתמש ברמת השליטה הזו, הנה ההגדרה המומלצת:
- עובדים (משתמשי האפליקציה): כדי למזער את הסיכון לשיבושים, רוב העובדים צריכים להשתמש בערוץ היציב, שנבדק באופן מלא על ידי צוות הבדיקות של Chrome. בנוסף, אחוז קטן מהמשתמשים (בין 5% ל-10%) יכולים להיות בערוץ בטא. בערוץ הזה מקבלים תצוגה מקדימה של גרסת Stable למשך 4 עד 6 שבועות, והוא יכול לעזור לאדמינים לגלות בעיות אפשריות בגרסה. כך יש יותר זמן לטפל בבעיות לפני שהגרסה מושקת לכל שאר המשתמשים.
- מחלקת ה-IT: חברי מחלקת ה-IT, כולל מנהלי המערכת עצמם, יכולים להשתמש בערוץ בטא או בערוץ פיתוח כדי לקבל גרסת טרום-השקה (Preview) ל-6-4 שבועות או ל-12-9 שבועות של החידושים הצפויים בגרסה היציבה של Chrome.
ערוצי הפצה לטווח ארוך
יכול להיות שפיתוח המוצר לא יתבצע מהר כמו שתכננתם, וקצב ההפצה של Chrome, שהוא חודשי, יהיה מהיר מדי. למקרה השימוש הזה, Chrome מספק ערוץ יציב מורחב שמאפשר לקבל עדכוני תכונות בתדירות נמוכה יותר, אבל עדיין לקבל תיקוני אבטחה. העדכונים בערוץ הזה מתבצעים כל שמונה שבועות.
בתרשים הבא אפשר לראות איך אבני דרך שונות מתקדמות דרך ערוצי ההפצה השונים של Chrome:
- גם בגרסה היציבה וגם בגרסה היציבה המורחבת, אותן גרסאות נשלחות במשך ארבעת השבועות הראשונים, ולאחר מכן הן מתפצלות.
- אין ערוץ בטא מורחב. במקום זאת, נעשה שימוש במחזור בטא רגיל של ארבעה שבועות כדי לייצב גם את הגרסה היציבה וגם את הגרסה היציבה המורחבת. ארגונים שבוחרים להצטרף לגרסה היציבה המורחבת למשך שמונה שבועות צריכים להמשיך להפעיל את ערוץ הבטא כמו שהם עושים היום, כדי לזהות באופן יזום בעיות שעשויות להשפיע על הסביבות שלהם.
החשיבות המתמשכת של ערוצי הפיתוח והבטא למשתמשים בגרסה יציבה מורחבת
בעוד שהערוץ היציב מתקדם למחזור הפצה של שבועיים, והארגון שלכם מאמץ את המחזור היציב המורחב של שמונה שבועות כדי להרוויח יותר זמן לבדיקות, עדיין חשוב להשתמש בערוצי הפיתוח והבטא. אין ערוצי 'פיתוח או בטא מורחבים' נפרדים. נעשה שימוש בערוצי הפיתוח והבטא הרגילים כדי לייצב את הגרסאות היציבות והגרסאות היציבות המורחבות.
אם ארגונים ימשיכו להשתמש בערוצי הפיתוח והבטא, הם יוכלו לזהות באופן יזום בעיות שעלולות להשפיע על הסביבות שלהם. ערוצי הפיתוח והבטא מספקים תצוגה מקדימה של ארבעה שבועות של הגרסה היציבה הבאה. למשתמשים בגרסה יציבה מורחבת, חלון התצוגה המקדימה הזה חיוני כדי לגלות בעיות פוטנציאליות ולטפל בהן הרבה לפני עדכון התכונות שמתבצע כל שמונה שבועות.
ערוצי הפיתוח והבטא משמשים למעשה כמערכת האזהרה המוקדמת העיקרית לכל שינוי שצפוי להגיע לסביבה היציבה המורחבת שלכם למשך שמונה שבועות, וכך מבטיחים שהאפליקציות הארגוניות שלכם יישארו תואמות. אדמינים של המערכת יכולים להמשיך להקצות קבוצה קטנה ודטרמיניסטית של משתמשים (לדוגמה, 5-10% מהמשתמשים באפליקציה) לערוצי הפיתוח והבטא כדי למקסם את היתרון הזה.
סיכום
הבדיקות הן חלק חשוב בפיתוח תוכנה בחברות, כדי להבטיח את איכות המוצרים שלהן. הן גם שלב חשוב לאדמינים של מערכות, כדי לתת לעובדים בארגון גישה לתוכנה איכותית ולמנוע שיבושים בתהליכים העסקיים.
כדי להצליח בהטמעת תהליך עבודה לבדיקות בארגון, חשוב שכולם יאמצו את הגישה המשותפת שלפיה איכות, ולכן גם בדיקות, היא תכונה.
במאמר הזה סקרנו דרכים שונות לשילוב שיטות מומלצות לבדיקות בארגון. כדי לקבל סקירה מעמיקה של כלי הבדיקה הקיימים, אפשר לעיין במאמר כלים מ-Chrome לבדיקות אוטומטיות חלקות.
כדי לקבל הדרכה מעשית לבדיקות, מההתחלה ועד הסוף, אפשר לעיין גם בקורס Learn Testing ובשיטות המומלצות לאוטומציה של בדיקות באתר web.dev.