אלא מה? התהליך לא היה כפי שציפיתם: בשל בעיות פה-ושם המחיר עלה, ואת המפתחות קיבלתם זמן רב לאחר התאריך שנקבע. אבל כאן לא נגמרת החוויה: כשנכנסתם בהתלהבות לבית החדש גיליתם שלא בדיוק קיבלתם את מה שביקשתם: היציאה לחצר היא לא מהסלון, והמטבח מופרד מפינת האוכל. ולא זו בלבד, אלא שכבר ביום הראשון התברר שצינור המים לא מגיע לברז של המטבח.
אז מה לסיפור הזה ולבדיקות תוכנה?
גם בפיתוח תוכנה הלקוח מגדיר את הדרישות שלו, יש אדם אשר מתכנן את המערכת על סמך דרישות אלו, ואחר אשר בונה אותה. בסופו של דבר, הלקוח רוצה לקבל בזמן, ובמחיר הנכון – תוצר שעובד טוב. אם ננתח את תהליך בניית הבית, נגלה ששלושה היבטים בתהליך לא בוצעו כראוי:
- הבית לא נבנה במחיר ולא בזמן שנקבעו
- תכנון הבית לא היה לפי דרישות הלקוח
- תקלה בהרכבת צינורות המים
תהליכי הבטחת איכות תוכנה
בעולם המחשוב אנחנו מגדירים שני תהליכים אשר מטרתם להבטיח שמצבים כאלו לא יקרו:
בקרת איכות (QC – Quality Control) – פעילות שנועדה לבדוק את תפקודי התוכנה שפותחה (המערכת) ולוודא גם שהיא עונה על דרישות הלקוח וגם שהיא עובדת נכון, כלומר: אין בה תקלות. אלו למעשה הן בדיקות התוכנה.
הבטחת איכות (QA – Quality Assurance) – זה אוסף פעולות שנועדו להבטיח שהתוצר הסופי ייצא בזמן ובתקציב שהוגדרו.
מקצועות בדיקות התוכנה (QC) והבטחת האיכות (QA) הם מקצועות חדשים יחסית, אבל צומחים ומתפתחים במהירות עצומה. בתחילת עידן המחשבים הם לא היו קיימים, מכיוון שהיו רק מחשבי-על מסיביים ויציבים, וטכנולוגיות פשוטות יחסית. תוכנות המחשב שימשו רק ארגונים בודדים למטרות מאוד ספציפיות והמפתחים וידאו די-בהצלחה את היעילות והנכונות של תוכנות אלו.
בעשרים השנים האחרונות טכנולוגיות המחשוב התפתחו והשתלטו כמעט על כל היבט בחיינו: עסקאות בנק, טלפונים, מכוניות וכו'. בהתאמה – מערכות התוכנה נעשו מורכבות יותר ולכן גם פחות יציבות, והתוצאה היא: תוכנות לא טובות שגורמות נזקים, גם כספיים ואפילו נזקים בנפש. הנה לפניך מספר דוגמאות רק כדי להמחיש:
- מערכת הניווט של מעבורת חלל תוכננה לפי יחידות של אינצ'ים במקום יחידות של ס"מ, דבר שגרם לנזק עצום.
- מערכת המכס בשדה התעופה של לוס-אנג'לס לא עבדה נכון, וגרמה להשבתת שדה התעופה למספר רב של שעות. 17,000 טיסות עוכבו.
- מערכת המנהלת את מכשיר ה- CT בבית-חולים לא עבדה נכון וגרמה למותם של 5 אנשים.
והרשימה עוד ארוכה.
במשך הזמן הרבה מומחים גיבשו מתודולוגיות ושיטות עבודה שונות שיוכלו לייעל את תהליך בדיקות התוכנה ולשפר את איכות התוצר הסופי, אבל עד כה לא נמצאה שיטה אחת ספציפית המתאימה לכל סוגי המערכות, לכל הארגונים ולכל הטכנולוגיות. ברוב הארגונים העוסקים בפיתוח תוכנה ישנם כיום גם צוותי בודקים, אבל שיטות העבודה שלהם – גם אם הן מתבססות אולי על מתודולוגיה מוכרת – הן גם מותאמות לצרכים הייחודיים של הארגון.
האתגרים של בדיקות איכות תוכנה
אם זה כך, נשאלת השאלה: מה יכול הבודק ללמוד? ובכן, מעבר למתודולוגיות המוכרות, הבודק חייב ללמוד חשיבה מתאימה ויצירתיות וזאת מכיוון שהבודק עומד בפני מספר אתגרים לא פשוטים, כמו:
- לא ניתן לבדוק את הכול. כמות הבדיקות האפשרית היא כמעט אין-סופית, והזמן, כמובן, הוא מוגבל. אם כך, איך בודקים מערכת תוכנה ומבטיחים ללקוח שימוש יעיל בה, מבלי לבדוק את הכול-הכול?
- הבודקים תלויים במספר רב של גורמים, המשתנים בין ארגון לארגון, כמו למשל:
- שיטת פיתוח התוכנה – באיזו צורה זה משפיע על תהליך הבדיקות? ומה הבודק צריך לעשות כדי להתאים את עבודתו?
- מהו הקשר בין הבודק למפתח? כיצד מתנהל תהליך תיקון התקלות שהבודק מגלה?
- מהו סוג המערכת? שהרי בדיקת מערכת לניהול הפריטים במחסן אינה דומה לבדיקת אתר קניות באינטרנט או מערכת המנווטת מטוס. כיצד על הבודק לפעול בכל אחד מסוגי המערכות האלו?
- האם המערכת הנבדקת קשורה למערכות אחרות? מהי המשמעות מבחינת בדיקות?
- האם מדובר במערכת חדשה או אולי במערכת שעוברת שדרוג?
- האם בארגון ישנם כלי עזר לצורך הבדיקות? או אולי העבודה כולה ידנית?
- הבודקים עובדים מול אנשים רבים ושונים: מנהל הפרויקט, מפתחים, מנתחי מערכות, מנהלי-מוצר, לקוחות, אנשי תשתיות. מהי מהות הקשר עם כל אחד? כיצד זה משפיע על העבודה?
- כיצד בדיוק "מודדים" אם המערכת מוכנה לשימוש הלקוח? שהרי בסופו של תהליך, הבודק הוא זה שיכול להגדיר את המערכת כ"תקינה" לאחר ביצוע הבדיקות. ומה קורה אם המנהל מחליט על סיום הבדיקות למרות שזה נוגד את דעת הבודק על איכותה?
בשל כל האתגרים האלו, עבודת הבודק היא מלהיבה, מעניינת ומאוד יצירתית. הבודק של היום חייב להיות מקצוען, כי נדרשת ממנו אחריות רבה, ולכן – הוא חייב גם להיות בעל ראייה מערכתית יחד עם קפדנות לפרטים. הוא נדרש ללמוד ולהבין את תפקודי מערכת התוכנה, ולנתח אותם החל מהרמה הכללית ועד ללוגיקה ולקשרים של הפרטים הקטנים.
בודק תוכנה חייב לדעת להפעיל חשיבה יצירתית כדי לתכנן בדיקות אשר יבטיחו את התפקוד הנכון של מערכת התוכנה בכל תנאי ובכל מצב. הוא חייב גם להיות סקרן ועקשן, השואל שאלות של "ומה אם….?" על כל פעילות לא ברורה של המערכת. וכמו כן, הבודק צריך להיות בעל יחסי אנוש טובים כי הפעילות שלו כרוכה גם בעבודת צוות עם בודקים נוספים וגם בשיתוף פעולה עם גורמים אחרים.
סיכום
עולם הבדיקות הוא עולם מעניין וקצת מוזר: אמנם אין בו תוצרים מלהיבים, אבל הוא יצירתי יותר מכל פעילות אחרת הקשורה לתוכנה. יש לו מתודולוגיה, אבל יחד עם זאת, צורת העבודה איננה קבועה אלא משתנה ממערכת אחת לשנייה, מארגון אחד לשני.
