אנשים בתעשייה המכירים את שלל תחומי ההנדסה הבחינו שאמינות סביבת התוכנה נמוכה במידה משמעותית מזו המאפיינת תחומי הנדסה אחרים. לאחר שהמוצר הושלם והגיע למשתמש הקצה, סביר לצפות שהוא יעבוד בצורה אמינה. לעומת זאת, במוצרי תוכנה, סביר לגלות שהתוכנה מכילה באגים ואינה מתפקדת בצורה אמינה אצל חלק מהמשתמשים. משתמשי הקצה, המודעים רק למספר קטן של תקלות תוכנה, עשויים לטעות ולהתייחס אליהם כחריגים שנגרמו על ידי מתכנתים ובודקים בלתי-מנוסים. אלו מבנינו המעורים בתחום התוכנה מבינים שגם המתכנתים והבודקים הטובים ביותר לא תמיד יכולים להימנע מבעיות אלו.
נשאלת השאלה, כיצד ייתכן כיום, שבכל מוצר תוכנה קיימים באגים על אף ההתקדמות הטכנולוגית המאפיינת את ימינו. במאמר זה ננסה לענות על שאלה זו, תוך הצגת סיבות שונות לכך.
- ריבוי פלטפורמות – קיימות אינספור סביבות הרצה ליישומי תוכנה בעולם המודרני. בעולם ה Web, מדובר על מערכות הפעלה שונות ודפדפנים שונים במגוון גרסאות. בעולם ה Mobile מדובר על מכשירים שונים מערכות הפעלה שונות ודפדפנים שונים בגרסאות שונות. אין ספק שבאידיאל היינו רוצים לבדוק את שלל הפלטפורמות, אך עקב אילוצי זמן ותקציב הדבר אינו אפשרי. לכן, לרוב נבדוק את הפלטפורמות העיקריות שעליהן היישום אמור לעבוד, בהתאם לסקר שוק לאיתור קהל היעד או בהתאם לדרישת הלקוח (בדרך כלל אלו יהיו הפלטפורמות הנפוצות).לא נוכל לדעת כיצד האפליקציה תעבוד על סביבת הרצה שלא נבדקה. יתכן שהפלטפורמה כלל לא תריץ את האפליקציה (לדוגמא בשל הכנסת פיצ’ר בודד שאינו נתמך בפלטפורמה ומקריס את כולה), או שהיא תריץ את האפליקציה אך לא בהתאם לתכנון המקורי.
- קביעת דד-ליין בצד הלקוח – בארגונים שונים (לדוגמא בחברות סטארט-אפ קטנות), עקב אילוצי זמן, לא מכינים מסמכי בדיקות כלל וכלל. במצב זה ניתן לפספס באגים שהיו ניתנים לאיתור במידה והחברה הייתה עובדת עם מסמכי בדיקות מסודרים. במידה והחברה כן עובדת עם מסמכי בדיקות, גם במקרה זה, בודק התוכנה יעבוד תחת אילוצי זמן ולכן יצטרך לבנות מערך בדיקות כמה שיותר יעיל ומקיף תוך תיעדוף הבדיקות החשובות. מתוך הבאגים שיימצאו, לרוב, יבוצע תיעדוף לתיקון לבאגים החמורים שאותרו, והבאגים בדירוג הנמוך יישארו ברקע לתיקון בגרסה הבאה, או שלא יתוקנו כלל.
- כתיבה לא מדויקת של תסריטי בדיקות – חוסר מיקוד בתסריטי בדיקות או מסמך STD שאינו כתוב באופן מדויק עלול להוביל לפספוס באגים, או לחילופין לדיווח על באג כאשר לא באמת מדובר בבאג. לדוגמא, במסמך האפיון מוגדר ששם המשתמש יהיה באנגלית בלבד 4-10 תווים ללא תווים מיוחדים. במסמך הבדיקות הבודק ירשום באחד מתרחישי הבדיקה “הזן שם משתמש באורך 6 תווים”, מכך ניתן להסיק שהבדיקה לא הוגדרה באופן מדויק ובפועל עלולים להיווצר 2 מקרים בעייתיים בעת הרצתה: הראשון, כתיבה של שם משתמש בעברית והשני, כתיבה של שם משתמש עם תווים מיוחדים. שני מקרים אלה יובילו לדיווח על באג כאשר לא באמת מדובר בבאג אלא בתרגום לא מדויק של מסמך האפיון למסמך בדיקות.
- עצלנות / חוסר מקצועיות של בודק תוכנה – עצלנות או חוסר תשומת לב לפרטים הקטנים אצל בודק עשויים לגרום לפספוס באגים. בבדיקות רגרסיה למשל, כאשר אין אוטומציה המטפלת בבדיקות אלה בחברה, בודק ידני עלול למצוא את עצמו עושה את אותן בדיקות מספר פעמים ולעתים הוא עלול “לעגל פינות” ובכך לפספס באגים שנוצרו עקב פיתוח פיצ’רים חדשים. לעתים, הבאגים הללו יתגלו רק בסביבת הייצור אצל משתמש הקצה.
- אילוצי תקציב בצד הלקוח – אילוצי תקציב עשויים להשפיע באופן ישיר על כמות הבודקים בחברה ובאופן עקיף על רמת הבדיקות, מתוך הנחה שבודק עם ניסיון רב יותר יהיה פרודוקטיבי ויקר יותר. חברות שונות לעתים כלל לא יעסיקו בודקי תוכנה עקב אילוצי תקציב. בחברות אלה, במרבית המקרים, מפתח התוכנה יבדוק את המוצר, אך אין ספק שזה עלול להביא לאיתור מספר נמוך יותר של באגים רבים שבודק תוכנה היה יכול למצוא. מדוע לא מומלץ שמפתח המוצר יבדוק אותו? יש לכך מספר סיבות עיקריות. הסיבה הראשונה היא שמפתח המוצר לא יכול להיות מספיק ביקורתי כאשר הוא בודק את המוצר שהוא עצמו פיתח, הוא לא ינסה “להתקיל” את המוצר ולתקוף אותו מכיוונים שונים ואילו איש QA כן. סיבה שניה היא שלמפתח לרוב אין זמן לבדיקות מעמיקות וסיבה נוספת היא שמי שבא “מבחוץ” יכול לחשוב על בעיות מחוץ לקופסא שמפתח המוצר כנראה פחות יכול לחשוב עליהן.
גרוע מכך, לעתים הלקוח עצמו בודק את המוצר במקום איש בדיקות, הוא אינו בעל רקע טכני ובטח לא יודע כיצד לערוך בדיקות מספיק מקיפות ואיכותיות.
- מקרי קיצון שגם בודק מאוד מנוסה לא יכול לצפות – לעתים גם בודק מנוסה ומיומן אינו יכול לצפות מקרים מסוימים. לדוגמא, בעדכון גרסה של אנדרואיד, בין היתר, עדכנו את פיצ’ר שירותי המיקום על מנת להיטיב ולדייק שירותים של אפליקציות מבוססות GPS. אפליקציה ספציפית המושתתת על שירותי מיקום עבדה כצפוי בגרסה הקודמת של אנדרואיד היות ופותחה וסונכרנה עם פיצ’ר שירותי המיקום הישן. לאחר עדכון גרסת האנדרואיד, האפליקציה הקפיצה pop-up להפעלת שירותי המיקום ולאחר ההפעלה היא מייד קרסה. תפעול האפליקציה נפגע היות והקוד שלה סונכרן עם שירותי המיקום הישן ולא עם פיצ’ר שירותי המיקום החדש, כמובן שזה מקרה קיצון שגם לבודק מנוסה יהיה מאוד קשה לצפות מראש.
- חוסר סנכרון בשיטות העבודה של הצוותים/המחלקות בחברה – בחברות הייטק (לרוב בחברות בינוניות וגדולות) קיימות מספר מחלקות פיתוח ובדיקות. במידה ועובדים במתודולוגיית AGILE, לרוב מפתחים ובודקים יהיו באותו צוות, ויהיו צוותים רבים בחברה. לעתים עקב סיבות שונות (למשל ניהול לקוי, חוסר סדר ועוד), קיים חוסר סנכרון בשיטות העבודה בין הצוותים/המחלקות השונות בחברה ומכאן יתכן כי יתפספסו תרחישי בדיקות שהיו עשויים להוביל לאיתור באגים.
- לוגיקה שגויה באפיון המוצר – שגיאה לוגית באפיון המוצר עלולה להביא בתרחישים ספציפיים להתנגשות של קוד שעשוי להוביל לבאג בתוכנה. לדוגמא: באפיון אתר קניות מצוין באחד הסעיפים שבמידה וסל הקניות יהיה ריק האייקון שלו לא יופיע כלל. בסעיף אחר מצוין שבמידה ונבצע הוספה של מוצרים לסל הקניות אז מספר המוצרים שנבחר יופיע בסמוך לאייקון שלו, כאשר ברירת המחדל של הסל היא אפס. מה יקרה בתרחיש בדיקה שבו נרצה לבדוק את ברירת המחדל? נוסיף מוצר אחד לסל הקניות ואז נמחק אותו. מה נצפה שיקרה כעת? האם יופיע 0 ליד סל הקניות או שהיות ואין מוצרים בסל, הוא לא יופיע כלל? ברור שמדובר כאן בסתירה באפיון.
- התנהגות המוצר לאחר שחרורו לסביבת הייצור – לרוב, מוצר תוכנה ייבדק בשלב כזה או אחר לפני שחרור הגרסה בסביבת ה- Staging. סביבה זו הינה סביבה המדמה את המוצר בבית הלקוח עד כמה שניתן. כאשר חברה רוצה לשחרר אפליקציה חדשה היא תצטרך לערוך מחקר על קהל היעד, להבין אילו אפליקציות ושירותים הוא צורך ולצאת מנקודת הנחה שעל האפליקציה הנוכחית לעבוד במקביל עם שירותים אלה. לדוגמא, אפליקציה שקהל היעד שלה עד גיל 18, צריכה לקחת בחשבון “רעשי רקע” כמו אפליקציות שונות שרצות במקביל על מכשיר המובייל (למשל Facebook, Instagram, YouTube וכו’) ולהריץ תרחישי בדיקות על האפליקציה הנוכחית כאשר שאר האפליקציות רצות במקביל. בדיקות על האפליקציה בסביבת ה- Staging עשויות לאתר באגים הנובעים מ”רעשי רקע” ובכך יהיה ניתן לתכנן איך להתמודד עימם לפני שחרור הגרסה ללקוח. יש לציין שגם אם הבאגים שימצאו בסביבת ה- Staging יתוקנו, אין זה אומר בוודאות שלא יהיו באגים הקשורים להתנהגות המוצר בסביבת הייצור.
- באגים הנובעים מעומסים – בשלבי הפיתוח השונים עובר המוצר בדיקות על ידי משתמש בודד או מספר משתמשים קטן יחסית. בדיקות העומסים בוחנות ומודדות את תפקודה של המערכת תחת עומסים שונים. בבדיקות אלה, מסמלצים מספר משתמשים שיעבוד בו זמנית על המערכת ובודקים שהשימוש בזיכרון, אחוז צריכת המעבד (CPU), זמן תגובה ועוד, פועלים בהתאם להגדרת האפיון. הכלים הייעודיים לבדיקות עומסים לרוב יקרים מאוד ולכן לקוחות רבים לא מוכנים לשלם על בדיקות אלה. לכן, בסביבת הייצור עלולים להתגלות באגים הנובעים מעומסים.
- באג באלגוריתם – באגים יכולים להווצר מאלגוריתם שגוי, או אלגוריתם שלא דאגו “לטפל” במקרי הקצה שלו. לדוגמא, בתוכנה עבור ספקים המשמשת להזמנת מוצרים, הספק יקבל הנחה על כמויות כאשר יבצע הזמנה עבור מספר לקוחות רב יותר. כאשר הספק יזין את מספר הלקוחות עבורם הוא מבצע את ההזמנה, מאחורי הקלעים בקוד, יבוצע חישוב של הממוצע ללקוח. אין זה טריוויאלי שהספק יזין אפס בשדה מספר הלקוחות, אך מה יקרה אם הוא יעשה זאת? במידה ולא דאגו לטפל במקרה הקצה של חלוקה ב- 0 (לדוגמא להציג הודעת שגיאה בהתאם) הדבר יביא לשגיאה אריתמטית שעשויה להקריס את האפליקציה.
- שדרוג גרסה של תוכנות אינטגרטיביות שונות – לרוב התוכנה המפותחת אינה עומדת בפני עצמה ובאה באינטגרציות עם תוכנות אחרות באמצעות Web services או API’s שונים. כאשר אלו האמורים עוברים שדרוג גרסה, ייתכן ורכיבים המתממשקים עם התוכנה המפותחת יעברו שינוי כלשהו שיגרום להם להפסיק להתממשק עם התוכנה.
- יישום לא נכון של תוכנות בדיקה אוטומטיות – יישום לא נכון של בדיקות באמצעות תוכנות בדיקה אוטומטיות עשוי להביא לכיסוי חלקי של התרחישים האפשריים במוצר והדבר עלול להוביל לפספוס באגים.
לסיכום, ישנן סיבות רבות אשר יכולות להסביר מדוע ביישומי תוכנה עלולים להימצא כשלים רבים.
על אף הקידמה הטכנולוגית אנו נמשיך להיחשף לבאגים שונים ביישומי תוכנה, בין אם נשים לב אליהם ובין אם לא. אין ספק שנעשים מאמצים רבים להפחית את כמויות הבאגים עד כמה שניתן אך מכורח המציאות לא ניתן להגיע למצב אידיאלי שבו המוצר יהיה “מושלם” וללא באגים.
המאמר נכתב ע”י דור חן, מרצה במכללת SVCollege
