תארו לעצמכם שהתוכנה הכי חשובה בחברה שלכם פתאום מפסיקה לפעול – מה יקרה? יכול להיות שהזמנות יאבדו או שלא תעמדו בלוחות זמנים, אבל בטוח שהלקוחות יתלוננו.
אפשר להימנע מהסיוט הזה: צריך להטמיע תהליך בדיקה רציף וקפדני, שיזהה בעיות לפני שהן יגרמו לבלגן. אבל קשה ליישם תהליך כזה בארגון.
במאמר הזה נסביר מה צריך לקחת בחשבון כשמתחילים לבצע בדיקות בחברה, ואיך אפשר להפיק תועלת מבדיקות בטווח הארוך.
שיטות מומלצות לבדיקות לצוותי מוצרים
החלק הראשון של המסמך הזה מתאר את תהליך ההטמעה של בדיקות בתהליך העבודה.
הטמעת תרבות של בדיקות בצוות
כדי להטמיע בהצלחה בדיקות בצוות, כולם צריכים לחשוב באותו אופן ולראות באיכות השקעה ולא נטל. זהו תהליך שדורש זמן ועקביות, כמו כל שינוי תרבותי אחר.
אחת הדרכים לעצב את התרבות הזו היא לקיים פגישות קבועות כדי לדון בפגמים, בהשפעה שלהם, במקור שלהם ובמה שנדרש כדי לתקן אותם. כך אפשר להעלות את המודעות לחשיבות של מניעת פגמים כאלה מלכתחילה.
כדי להגדיל את סיכויי ההצלחה, מומלץ למנות בצוות אדם ייעודי שיפקח על המאמץ ויקדם אותו. מישהו שמגדיר הנחיות לצוות – או אפילו לארגון כולו – אוסף שיטות מומלצות ומשתף אותן, ותומך במאמץ בכל הרמות.
כלי שימושי נוסף הוא שינוי תפקיד התמיכה של המוצר. קבלת תובנות ישירות ולא מסוננות מהלקוחות ולמידה על הבעיות היומיומיות שהם נתקלים בהן במוצר יכולה להיות חוויה חשובה למנהלי מוצרים, למעצבים ולמפתחים.
המטרה היא שכל אחד בצוות יבין שאיכות היא תכונה, חשובה לא פחות מכל פונקציונליות אחרת שאתם מפתחים למוצר. אחרי שכולם אימצו את הגישה הזו, זה היה טבעי להבין שגם בדיקות הן תכונה. כי הבדיקות הן אלה שמבטיחות את האיכות של המוצר שנשלח.
תהליך בדיקה מפורט
אחרי שכל הצוותים שמעורבים בפיתוח המוצר יגיעו להסכמה, תוכלו להגדיר את קיומם של הבדיקות ואת השימוש בהן באופן רשמי יותר.
הוספת בדיקות ל-Definition of Done
כשמוסיפים בדיקות כדרישה לתכונה, מציינים שהתכונה לא מוכנה להשקה עד שהיא נבדקת בצורה נכונה ואוטומטית.
הרצת בדיקות באופן קבוע
אחרי ההטמעה, בדיקות אוטומטיות יכולות לשמש כהגנה בכל שלב בתהליך הפיתוח. הם לא דורשים התערבות אנושית, ואפשר להפעיל אותם בכל שלב קריטי בצינור הפיתוח. לדוגמה:
- בכל קומיט.
- בכל בקשת משיכה.
- אחרי כל מהדורה מלאה או שינוי בסביבה.
אם אתם מסתמכים על שירותי צד שלישי בסביבת הייצור, יכול להיות שיהיה הגיוני להריץ את הבדיקות מול סביבת הייצור כדי לוודא שממשקי ה-API של הצד השלישי פועלים כמצופה.
הגדרת מדדים ואיסוף שלהם
חשוב להגדיר קבוצה של מדדים כדי למדוד את האפקטיביות של הבדיקות ואת ההשפעה של תהליכי העבודה של הבדיקות על העסק. הנה כמה דוגמאות למדדים שאפשר להשתמש בהם:
- גרסאות בחודש: מספר גבוה יותר של גרסאות בחודש יכול להעיד על תהליך פיתוח גמיש יותר. במקרה הזה, בדיקות אוטומטיות ממלאות תפקיד חשוב, כי הן מאפשרות להמשיך את תהליך הפרסום בביטחון.
- דוחות איתור באגים: מגמת ירידה בדוחות איתור באגים יכולה להיות סימן חיובי לכך שהבדיקות (ותהליכי הפיתוח) שלכם יעילים.
- כיסוי הבדיקות: זהו לא מדד מדויק, אבל הוא יכול להצביע על עומק הבדיקות של תרחישי שימוש קריטיים.
חשוב לזכור שהמדדים האלה מושפעים גם מגורמים אחרים, ולכן יכול להיות שהם לא מדויקים. לדוגמה, יכול להיות שמספר הגרסאות שלכם יירד בתקופת החגים, ומספר דוחות הבאגים יעלה. לכן, אל תסתמכו רק על כמה נתונים, והקפידו למפות אותם עם נתונים אחרים שזמינים לצוות שלכם.
אם תיישמו את השלבים האלה עם הצוות שלכם, מצב המוצר ישתפר בוודאות בטווח הארוך. אבל יש עוד דברים שאפשר לעשות!
שיטות מומלצות לבדיקה לאדמינים של מערכות
צוותי מוצרים לא יכולים לעבוד לבד. הם מסתמכים על החומרה, הכלים והתשתית שמתוחזקים על ידי אדמינים של המערכת. אדמינים של מערכות בדרך כלל לא תורמים ישירות לפיתוח המוצר, אבל הם עדיין יכולים להשפיע לטובה על תהליך העבודה של הפיתוח. לדוגמה, על ידי ניהול פעיל של גרסת הדפדפן שבה משתמשות קבוצות משתמשים מסוימות בחברה.
בחלק השני של המאמר מוסבר איך זה עובד, באמצעות ערוצי ההפצה של Chrome ומדיניות ארגונית.
ערוצי הפצה של Chrome
יש ארבעה ערוצי הפצה: יציב, בטא, Dev ו-Canary.
מידע נוסף זמין במאמר בנושא ערוצי ההפצה של Chrome.
שימוש בערוצים בארגון לדוגמה
המבנה של צוותי מוצר משתנה בין ארגונים, כי אין גישה אחת לפיתוח תוכנה שמתאימה לכולם. לדוגמה, נניח שיש צוות עם התפקידים הבאים: ניהול מוצר, UX ו-UI, הנדסה, תפעול ותמיכה.
בארגון כזה, אפשר לחלק את הערוצים באופן הבא:
- ניהול מוצרים: מנהלי מוצרים יכולים בדרך כלל להשתמש בערוץ היציב, כדי להשתמש באותה גרסה כמו רוב המשתמשים. לפעמים הם יכולים להשתמש בערוץ beta או dev אם הם עובדים על תכונה שנדרש בשבילה API שלא הושק עדיין.
- הנדסה וחוויית משתמש: חלק מהצוותים האלה יכולים להיות ב-dev channel, כדי לקבל גישה לתכונות החדשות ביותר, כמו 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.