בדיקות רגרסיה - גישות, מצבים ופתרונות ניסים אריאל

מה הן בדיקות רגרסיה

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

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

 

 

מצבים משתנים מצריכים גישות שונות

 

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

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

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

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

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

פקטור נוסף שאינו פחות חשוב, הוא אופי הפיתוח החדש שמוזג לתוך המוצר. לעיתים ישנם פיתוחים שנוגעים פחות בצד הפונקציונאלי של המוצר, אך נוגעים בשינויים תשתיתיים. למשל, עדכון גרסה של AngularJS Material או React – תשתיות שה Front End  נשען עליהן, מעבר לעבודה עם קונטיינרים חדשים, מעבר Cloud חדש וכו'...כל אלה צריכים להילקח בחשבון על מנת להתאים את אופי הבדיקות, שיבטיחו שהמעברים נעשו חלק וכראוי. למשל, בעדכון גרסה לתשתית UI כפי שהוזכר, קל יותר לבצע מעברי מסכים ולראות שלא השתבש דבר. לעומת זאת כשהקוד עובר לסביבה חדשה, הסברה נותנת שזה מצריך יותר מאשר לראות שה-UI תקין.

תכנון מקדים

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

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

מגבלות הכוח

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

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

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

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

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

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

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

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

החלום הוורוד

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

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

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