האנציקלופדיה לבדיקות | קובי יונסי

מידי פעם אני מוצא בודקי תוכנה ששואלים אותי לגבי המושג Shift Left שעולה מעת לעת בשיחות, בישיבות צוות או באופן מקרי כשמדברים על מיקומו של הבודק בשלב הפיתוח.

הפעם החלטתי להאיר את המבט על מה זה אומר Shift Left ואיך זה קשור לאחד משבעת עקרונות הבדיקות.

המושג Shift Left  מתייחס לגישה בתחום בדיקות התוכנה שמצביעה על תזוזה של תהליכי הבדיקות מהשלב המאוחר שמגיע אחרי סיום הפיתוח אל שלבים מקדימים יותר בתהליך כמו שלבי האפיון והגדרת המוצר.

המטרה העיקרית היא לזהות ולתקן את הבעיות של המוצר כמה שיותר מוקדם בתהליך פיתוח התוכנה ובדיקתה בכדי לשפר את איכות התוכנה.

גישה זאת מתכתבת להפליא עם אחד העקרונות החשובים בבדיקות עליהם גם הרחבנו בעבר במגזין זה.

העיקרון נקרא בשם: Early Testing  

והפרשנות בעברית תהיה: בדיקות מוקדמות חוסכות זמן וכסף.

משמעותו של כלל זה,

בדיקות מוקדמות עשויות לזהות בעיות עוד בשלבים הראשונים של הפיתוח, כאשר עשוי להיות יחסית פשוט וזול לתקן אותם. כאשר נמצאים פגמים בשלבי פיתוח מוקדמים, ניתן למנוע התפשטותם ולחסוך בכך מאמץ רב בשלבים מאוחרים.

העיקרון הזה מדגיש את החשיבות של הרצת בדיקות ובדיקות יחידה מוקדמות, שימוש בכלים אוטומטיים לבדיקה וסימולציה, כדי לזהות ולתקן פגמים בשלבים הראשוניים יותר של הפיתוח. זה מפחית את הצורך בתיקון בגרסאות המתקדמות של התוכנה ומקנה גם יכולת לזהות ולתקן פגמים לפני שהם מצטברים וגורמים לבעיות גדולות יותר.

בעבר היינו רגילים לכך ששלבי הפיתוח בוצעו בצד שמאל של מודל V והבדיקות חיכו בסבלנות בצידו הימני.

עם השנים צוותי תוכנה הגיעו למסקנה שבאופן זה קשה מאוד להתמודד עם ציפיות ודרישות משתנות, אלו מובילים לחוסר תקשורת, הבנה שגויה ומשם לתקלות בלתי צפויות.

המשמעות העסקית היא שהוצאות הטיפול והמניעה של תקלות הן גבוהות מה שמייקר את עלות התוכנה ומאריך את זמן היציאה לשוק שחשוב לבעלי העניין (Time to the market)

גישת Shift Left מבליטה בין היתר את חשיבותו של בודק התוכנה במתן פידבק והעלאת חוסרים או טעויות במסמכי הדרישות. 

פעילות חשובה שמסוגלת למנוע כניסת תקלות לתוך הקוד וגם מביאה לידי ביטוי את הניסיון של בודק התוכנה בהסתכלות על צרכי הלקוח וההתאמה לדרישותיו.

העקרונות המרכזיים של גישת Shift Left:

תודעה מוקדמת לבדיקה:
עיקרון זה מדגיש את הצורך להעביר את פעולות הבדיקה מהשלב המאוחר בתהליך הפיתוח אל השלב המוקדם יותר. צוותי הבדיקה צריכים להשתלב בפעילות בדיקות אשר תתחיל שלבים מוקדמים בתהליך הפיתוח ולבדוק כבר בשלב המוקדם ביותר ככל שמתאפשר.

1. אוטומציה של הבדיקות:

עיקרון זה דורש שימוש בכלים אוטומטיים לביצוע בדיקות. בדיקות אוטומטיות יכולות להיות יעילות ולהבטיח כיסוי נרחב של הקוד בזמן קצר.

2. שילוב של הבדיקות בתהליך הפיתוח

הבדיקות צריכות להיות חלק מהתהליך הכללי של הפיתוח. זה כולל כתיבת בדיקות לפני כתיבת הקוד, בדיקות יחידה מתמידות, ובדיקת אינטגרציה תכנון מוקדם.

3. מעורר השקעה של צוותי הבדיקה

עיקרון זה דורש הקפדה על העסקת צוותי הבדיקה בשלב מוקדם יותר בתהליך הפיתוח. זה עשוי לכלול הכשרה והקמת צוותי בדיקה מקצועיים שיוכלו להשתלב מיד בתחילת התהליך.

יתרונות של גישת Shift Left:

כלל ידוע הוא שתקלה שנמצאת לאחר עלייה לאוויר בזמן שהמוצר בקו הייצור תעלה ביחס של פי 100 מתקלה שזוהתה ונפתרה כבר בזמן כתיבת הדרישות.

מפה אנו למדים שיתרון מובהק של השיטה הוא צמצום עלויות של תיקון פגמים ושיפור משמעותי של תהליכי הפיתוח.

יתרונות נוספים שיש לגישה:

• זיהוי ותיקון של פגמים בצורה מהירה ויעילה לפני שעוברים לבדיקות  דינמיות

• הגדלת אפקטיביות תהליכי הפיתוח והפחת זמן הפיתוח

• הפחתת עלויות וזמני הבדיקות

• שיפור התקשורת בין צוותי הפיתוח לבדיקות

• זיהוי של פגמים שלא ניתן לאתר באמצעות בדיקות דינמיות כמו למשל: קוד מת, זליגת זיכרון, קוד לא יעיל (קוד ספגטי) וכו'.

חשוב לציין שלצד היתרונות ובכדי לשמור על תמונה מאוזנת קיימים גם חסרונות לגישה זאת,

 חסרונות של גישת Shift Left:

ישנן תקלות שלא ניתן לאתר מבלי הניסיון של לקוחות הקצה כמו בדיקות AB ובדיקות של שימושיות מול קהל רחב של משתמשים.

• עלות גבוהה של הטמעת הגישה בשלב ההתחלה מאחר ויש צורך בשדרוגים טכנולוגיים, בפרויקטים שכבר קיימים זה אף יהיה יקר ומורכב יותר.

• העברת הבדיקות שמאלה דורשת התאמה והקפדה על תהליכי עבודה חדשים ולכן  ייתכן שנגלה התנגדויות מצד צוות הפיתוח המקורי.

כיצד נטמיע בחברה גישת Shift Left?

גופים רבים מתקשים לעשות את ההסטה שמאלה באופן מוצלח, כדי שזה יקרה מומלץ לחשוב על הנקודות הבאות שיכולות לאפשר את ההטמעה באופן מוצלח:

1. צרו מדדי איכות שניתנים לכימות

כדוגמת הגדרות מדויקות של תנאי כניסה מבוססים למשל על הצלחה של מבחני שפיות, כך שללא התקיימות המדד לא ניתן יהיה לקבל את הגרסה לבדיקה.

2. בדיקות מונחות סיכון

מאחר ולא ניתן לבדוק את כל המקרים בזמן קצר יהיה נכון לתעדף את מקרי הבדיקה החשובים יותר שימנעו רמת סיכון גבוהה מהמוצר.

3.    שילוב אוטומציה ברמות הבדיקה הראשוניות

במרבית המקומות האוטומציה מתייחסת לממשק המשתמש ביצירת תסריטי End to End שמצריכים תחזוקה של צוותי האוטומציה.

בדיקות אלו נעשים בדרך כלל בשלב של בדיקות המערכת לפני שהיא נמסרת ללקוח כדי שיבצע את בדיקות הקבלה מצידו (UAT) 

הגישה של Shift Left מעודדת השקעה בתהליכי אוטומציה ברמות הבדיקה הראשוניות בכדי להגיע לפחות בדיקות ידניות ברמות הגבוהות.

4. שינוי בתפיסה מאבטחת איכות למהנדס איכות

תפיסת הבודק בארגון חייבת להשתנות מאחד שצד באגים למי שתומך באיכות המוצר. הבודק החדש צריך להבין בפיתוח מונחה התנהגות (Behavior Driven Development) כדי להבין את התנהגות הלקוח ומעבר לכך להבין צדדים עסקיים של המוצר, היבטים טכניים בפיתוח ותחומים נוספים שיידרש אליהם כמו למשל הבנה בחוויית משתמש.

5. תמיכת ההנהלה 

כמו כל שינוי בחברה, גם כאן אנחנו משנים את תפיסת האיכות בחברה,  מלהטיל את כל האחריות על צוותי הבדיקות שפוגשים את המוצר הסופי בשלב מאוחר יחסית של הפיתוח (SDLC).

בגישה זאת האחריות נופלת על כל הצוות, שיתוף הפעולה הכרחי, זה כולל תהליכי הדרכה והטמעת הרעיון שלא רק אנשי הבדיקות לוקחים חלק באחריות על האיכות של המוצר הסופי. ללא תמיכה של המנהלים יהיה קשה עד בלתי אפשרי להטמיע רעיון זה אצל חברי הצוות ובעיקר אצל המתכנתים.

 לסיכום,

כאשר אתה עובר שמאלה על ידי מינוף טכנולוגיות בדיקת תוכנה מודרניות, אתה יכול להשיג תוכנה בטוחה, אמינה ומאובטחת. על ידי העברת בדיקה שמאלה, אתה יכול להפחית את עלות הבדיקה על ידי מציאת באגים מוקדם יותר, כאשר זה זול יותר, ובמקביל גם להפחית את מספר הבאגים שהכנסת לקוד מלכתחילה.

ולכן המסקנה של המאמר תהיה : לזוז שמאלה – זה כדאי !