זוזו רגע: המדריך השלם לעבודה בגישת Shift left

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

תרבות ארגונית חדשה שגורמת ל-QA להיות יותר מעורב בתהליך כולו (צילום: Dreamstime)

מאת לירז מרקוביץ, Solution Consultant, IL & APAC ב-Applause

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

בדיקת התוכנה או המוצר הדיגיטלי חייבת להיות מאמץ רוחבי ברמת החברה, ולא רק שלב בתהליך לפני שחרור גרסה. מסיבה זו ניתן לראות יותר ויותר חברות מצטרפות לתנועת ה-Shift left, כאשר החזון הוא איכות, המהונדסת למוצר כבר מההתחלה ולא בסוף ה-SDLCי(Software Development Life Cycle).

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

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

למה כדאי לעשות Shift left?

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

1. שיפור קצב העברה לייצור/Live:

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

2. שיפור שביעות רצון לקוח: אחד היתרונות הגדולים של Shift left הוא היכולת לשחרר גרסה מהר יותר ועם מינימום תקלות – דבר המביא לשביעות רצון גבוהה של לקוחות הארגון או המוצר ויכול להיות שווה עשרות אם לא מאות אלפי דולרים.

כך תעשו זאת נכון בארגון שלכם

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

1. בנו מדדי איכות.
אם לומר זאת בפשטות, אחוז מסוים של Test Cases צריך לעבור עם פחות באגים קריטיים. במילים אחרות, צריך לוודא שרק אחוז מסוים של באגים "יברחו" ל-Production (יש שישאלו למה שבאגים יברחו מלכתחילה, אבל על זה נדון בטיפים הבאים).

מדד איכות נוסף הוא אחוז Smoke Tests שחייבים לעבור, אחרת הבילד לא יתקבל. זהו מדד אקוטי בארגון פיתוח פחות בשל, בו מעבירים ביודעין כמות באגים ל-QA. האחריות הזו היא בעיקר של מנהלי ה-QA שלעתים חייבים להתעקש על כך על מנת להבטיח Shift left מוצלח.

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

  • בהינתן תנאי שמאפשר העברת נתונים ממערכת a למערכת b בארכיטקטורת המוצר, מהי הסבירות שהוא יתרחש או יופעל בייצור?
  • מהי ההשפעה של אותו תנאי על הפן העסקי במידה וייכשל?

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

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

3. עברו מ-Quality Assurance ל-Quality Engineering.

  • הפכו את אנשי ה-QA ממחפשי באגים לתומכי איכות – שינוי קטן על פניו, אך גדול ב-Mindset הארגוני: שדרוג מאמץ ה-QA באסטרטגיית ה-SDLC וה-QE, לצד שיתוף פעולה הדוק יותר על ידי Behavior-Driven Development – BDD.
  • אמצו את גישת "שלושת המוסקטרים": מנהלי המוצר (המייצגים את הצד העסקי), פיתוח ו-QE חייבים לעבוד בשיתוף פעולה ולהגדיר את דרישות ה-Acceptance כך שיספקו את כל הצדדים. QE יעבדו עם הפיתוח בהיבטים הטכניים ובמתודולוגיית בדיקות המתאימה לכל פיצ'ר.
  • בגישה זו נוצרת תרבות ארגונית חדשה הגורמת ל-QA להיות יותר מעורב בתהליך כולו ולא רק בסופו, כמו שקורה לרוב. בתרבות כזו, QA הופכים להיות "שערי האיכות" האידיאליים והנכונים למוצר ששואף להיות בעל איכות דיגיטלית גבוהה.

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

פירמידת "Agile Test Automation" עוסקת בדיוק בזה: חלוקה של האוטומציה לאבני בניין – Unit/Acceptance/API/component – ולא חלקים גדולים ב-UI.

5. שילוב בדיקות כחלק מה-Sprint.
החשיבות של הבדיקות הידניות תוך כדי הספרינט לעתים גדולה יותר מזו של הבדיקות האוטומטיות. זה נכון במיוחד בצוותי פיתוח העובדים ב-CI/CD ונדרשים לרוץ בצורה מהירה תוך כדי שמירה על איכות של פיצ'רים חדשים. בדיקה תוך כדי ריצה של צוות QE – חיצוני או פנימי – מאפשרת תוצאות ממוקדות בתוך שעות ספורות וזיהוי בעיות מוקדם בתהליך ה-SDLC, ללא צווארי בקבוק בהמשך שעלולים לגרום לעיכוב בלוחות זמנים ואף לבאגים ש"בורחים" ל-Production.

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

הרבה ארגונים חושבים שאיכות המוצר תלויה ב-QA בלבד, למרות שברוב המקרים ה-QA מקבלים את הגרסה בשלב מאוחר יחסית. זה בדיוק מה שמניע את גישת ה-Shift left: כדי להשפיע על כולם לשתף פעולה בשלבים מוקדמים, גורם בכיר בפיתוח חייב להיות מעורב ולהעביר את המסר בין כל הקבוצות והצוותים. כאשר האיכות היא באחריות כולם, שיתוף הפעולה מיד יוצא לפועל בדרך הנכונה והבריאה. זוזו קצת שמאלה, זה ישתלם לכם.

הכתבה בחסות Applause

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

כתבת אורחת

הגב

3 תגובות על "זוזו רגע: המדריך השלם לעבודה בגישת Shift left"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
בודקבודק
Guest

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

בודקבודק
Guest

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

ASD
Guest

יצא לך באג של שכפול תגובה

wpDiscuz

תגיות לכתבה: