אני רואה בנו, אנשי בדיקות התוכנה, אחראים בעצם לאיכות המוצר. אפשר לראות זאת בהיקף הצר של המילה, כלומר שאנו אחראים על הרצת התוכנה ושאיפה לגילוי כלל הבאגים שנמצאים בתוכה בפרק הזמן שהצבנו לפנינו ובעלות המתוכננת.
אבל אפשר לראות את תפקידנו בהיקף רחב יותר של המילה, כלומר אחראים לאיכות המוצר בכל שלביו, ואני לא מתכוון רק לבדיקת המסמכים וכו', אלא וידוא שתהליך הפיתוח בכללו נעשה בדרך משביעת רצון. אני לא רואה הבדל בין המקרים, כלומר לדעתי אם התהליכים לא יהיו נכונים בסופו של דבר המערכת תצא עם סוג זה או אחר של באג, בין אם זהו באג מובהק ובין אם מדובר בכך שהדרישות לא מולאו לחלוטין וכד'.
מסיבה זו אני אכנס מעט לתהליכים שבד"כ אנו לא מעורבים בהם.
הראשון הוא ה-unit test, להלן UT.
Unit Tests
הגדרה: ה-UT אמור לבדוק יחידה אינדיבידואלית על-ידי הפיתוח. זוהי היחידה הקטנה ביותר שניתנת לבדיקה, או אפילו חיבור לוגי של כמה יחידות. זו יכולה להיות תוכנית פשוטה, פונקציה, פרוצדורה, מתודה או מודול. למשל יחידה שמקבלת שם משתמש, שולחת לבסיס הנתונים, מקבלת אישור או דחייה ומעבירה את התוצאה הלאה.
אחריות וביצוע: פיתוח.
בד"כ בדיקות אלה אוטומאטיות, יכולות להיות "קופסא לבנה" וגם "קופסא שחורה". כמו כן בדיקות אלו יכולות וצריכות להיות פרוגרסיביות ורגרסיביות.
מומלץ לכתוב את ה-UT לפני כתיבת הקוד עצמו.
מטרות:
- שליחידה יש היכולות הנדרשות;
- מקבלת ומוסרת את הנתונים הנכונים;
- מתממשקת נכון;
- זיהוי של בעיות שניתן לגלות רק ברמה הזו. למשל אני מכיר מקרה שהתשובה שהיחידה סיפקה היתה נכונה אך כפולה. בבדיקות של המוצר היה קשה מאוד לגלות זאת, אבל ייתכנו מקרים מסוימים אצל הלקוח שהפארסינג היה פשוט נפסק כתוצאה מכך.
ולבסוף: שהיחידה מוכנה (לאחר תיקון כל הבאגים) לאינטגרציה.
יש לזכור את היתרון העצום של מציאת בעיה בשלב זה: החיסכון בזמן. זיהו בעיה בשלב זה כשרק אדם אחד מעורב, ובנוסף ברור מיידית מעיין נובעת ההתנהגות הבלתי רצויה. במקרה של קבלת מוצר שיש בו באג (כמו מה שקורה בחדר הבדיקות) האנליזה עלולה להיות ממושכת לא רק באפיון מדויק של התקלה שהבודקים עושים, אלא גם באנליזה של הפיתוח לגבי מקורה של הבעיה הנ"ל.
בדיקות טובות של UT הן:
- אוטומאטיות;
- קלות לניהול;
- קלות להרצה;
- שומרות לוגים;
- מייצרות סטטיסטיקות;
- כוללות בדיקות שליליות, טיפול בבעיות;
- ערכי קצה וערכי default;
- ארגומנטים לא ואלידיים (טקסט במקום מספר).
כמו תמיד, יש לעשות review על כל בדיקה ומידי פעם על ה-scope של הבדיקות, כיסוי האזורים וכד'. שני הדברים האחרונים – בתיאום עם מחלקת הבדיקות.
נקודות נגד:
מאריך את זמן הפיתוח, לא תמיד קל ליישום.
הערה: נעזרתי בויקי באנגלית: http://en.wikipedia.org/wiki/Unit_test שם יש חלק נוסף הקושר בין ה-UT ל-Extreme Programming.
אין תגובות:
הוסף רשומת תגובה