סייר בבדיקות Shift-Left
בדיקה בניהול מחזור החיים של אפליקציות היא חיונית להגדלת איכות הקוד ולהפחתת הסיכון התפעולי המשויך לפריסה ולעדכון של תוכנות. המונח שמאלה בהקשר זה מעביר את הרעיון של העברת פעילויות בדיקה בהקדם האפשרי בשלב הפיתוח. הארגון בתרחיש המדגם שלנו צריך לשקול לשלב גישה זו באסטרטגיית DevOps שלה כדי למזער את בעיות האבטחה והיציבות הנוכחיות. ביחידה זו, בדקו סוגים שונים של בדיקות שניתן ליישם באופן זה ולאחר מכן בדקו את שיטות היישום שלהם.
אילו בדיקות צריכות להיות חלק מבדיקות הסט-שמאלה?
פיתוח תוכנה משלב מגוון רחב של סוגי בדיקה, אך אלה בעלי עניין מסוים כוללים:
היחידה: בדיקות אלה מתמקדות בחלקים קטן ביותר הניתנים לבדיקה של קוד יישום, כגון פונקציות או פעולות שירות בודדות. המטרה היא לקבוע אם כל יחידת קוד יכולה לבצע בהצלחה את הפעולה המיועדת שלה בבידוד משאר בסיס הקוד ומשאר יחסי התלות החיצוניים. בדיקות אלה צריכות להיות אוטומטיות באופן מלא, מהירות (הושלמו בתוך 30 שניות) ולספק כיסוי קוד מלא (כלומר, כל בדיקות היחידות צריכות לבדוק במשותף את בסיס הקוד כולו). בדיקת יחידות מתאימה לגישה משמאל למשמרת. אנו ממליצים ליישם אותו על כל הקודים בהקדם האפשרי במחזור הפיתוח, רצוי בתחילת שלב התיכנות.
בדיקותעשן: בדיקות אלה נועדו להעריך את פונקציונליות הליבה של אפליקציה בסביבה לבדיקה. למרות שהם בודקים את היישום בפועל (ולא את הרכיבים הבודדים שלו, כפי שמבחנים ליחידות בודקים), מטרתם היא לקבוע אם גירסת ה- Build או הפריסה של היישום יציבה מספיק כדי להוות בדיקות מעמיקות יותר. עם זאת, הם אינם מאמתים יכולת פעולה הדדית בין יישומים. בדומה לבדיקות יחידות, הן צריכות להיות אוטומטיות לחלוטין ומהירות יחסית (ניתן לדמות אינטראקציה עם המשתמש באמצעות כלי אוטומציה של דפדפן ומסגרות אוטומציה של ממשק משתמש). המונח עשן כדי להעביר את הרעיון של עשן המציין בעיה משמעותית (אש) שיש לטפל בה בהקדם האפשרי. יש ליישם גם בדיקות עשן בתחילת מחזור הפיתוח, רצוי ברגע שגירסה של התוכנה המספקת את הפונקציונליות הבסיסית שלה תהיה זמינה. הדבר חל הן על ה- Build של היישום והן על שלבי הפריסה.
שילוב: בדיקות אלה מאמתות אינטראקציה בין רכיבי יישום שונים. בניגוד לבדיקות יחידות, השלמתן עשויה להימשך זמן רב. משך הזמן המורחב של בדיקות אלה משמש בדרך כלל כארגומנט להפעלתן בתחילת מחזור החיים של פיתוח התוכנה. באופן כללי, מומלץ לשקול בדיקות שילוב בתרחישים שעבורם בדיקות היחידות או העשן אינן מתאימות. עם זאת, ההמלצה היא לתזמן אותם לביצוע במרווחי זמן קבועים. גישה זו מציעה פשרה סבירה בין עיכוב פוטנציאלי בזיהוי בעיות שילוב וזמן המתנה נוסף הנדרש להשלמתן.
בדיקות: בדיקות אלה קובעות אם מוצר תוכנה עומד בדרישות העסקיות ומוכן למסירה לצרכנים שלו. בדיקות הקבלה אינן מתאימות לאסטרטגיה של Shift-Left, אך ייתכן שניתן יהיה לשלב חלק מהרכיבים שלה בתחילת מחזור החיים של פיתוח התוכנה. לדוגמה, יש להציג קריטריוני קבלה וסיפורים של משתמשים, שהם רכיבים חיוניים של בדיקת קבלה, בתחילת תהליך הפיתוח. הדבר מאפשר שיתוף פעולה בין צוותי פיתוח, בעלי מוצרים ולבעלי עניין בפרוייקט. בנוסף, צרכני תוכנה ובעלי עניין בפרוייקט צריכים להיות עוסקים בשלבי הבדיקה הקודמת כדי לשתף את המשוב שלהם. הדבר עשוי לכלול שימוש בשיטות כגון בדיקות אלפא או ביתא, בדיקת שימושיות או מהדורות קודמות, לפני בדיקת הקבלה הרשמית.