מאת : נתי הורנשטיין , עורך אתר QAtest
אחד הנושאים החשובים בביצוע בדיקות תוכנה הוא תיעוד הבדיקות,
ללא תיעוד, לא ניתן לדעת אילו מצבים נבדקו,
האם בוצע כיסוי נכון לתהליך הנבדק, האם נבדקו כל מקרי הקצה,
האם סדרי עדיפות לבדיקות נכון ?
על בסיס האמרה המפורסמת "עשית ולא דיווחת - לא עשית", אפשר לומר:
נבדק ולא תועד = לא נבדק.
כיום גופים פיננסים בישראל כפופים לרגולציית SOX המחייבת תיעוד תהליך הפיתוח והפרדת רשויות (פיתוח ובדיקות),
רגולציה זו מגדילה את חשיבות תיעוד תהליך הפיתוח בפרט
והבדיקות בכלל. אי עמידה ברגולציה זו עשויה לפסול את
ספרי החשבונאות של החברה ולגרום לנזק כספי וציבורי רב לארגון.
תהליך תיעוד הבדיקות היה חשוב עוד לפני עידן ה SOX,
בעזרת תהליך תיעוד נכון ניתן לחסוך זמן יקר בבדיקות
ולזהות אזורי כיסוי ועדיפות בעת ההחלטה לעלות לאוויר עם מוצר.
בנוסף, אם חמק באג למערכת המבצעית (PROD) ניתן לוודא האם תסריט X או Y נבדקו בסביבת הבדיקות (TEST).
תיעוד הבדיקות מתחלק למספר קטגוריות:
- מצבי הבדיקה – תסריט הבדיקות.
- אוכלוסיה נבדקת.
- הדפסות / צילומי מסך / הקלטת סרטון וידיאו.
- תיעוד הבאגים.
1.מצבי הבדיקה – תסריטי הבדיקות -
לטובת תיעוד מצבי הבדיקה קיימים היום בשוק עשרות מערכות כגון :
QualityCenter (QC))/ Team Test / informup
כלים נוספים ניתן למצוא באתר QAtest> תוכנות ועזרים לבודק.
ניתן להשתמש בגיליון אקסל המצ"ב:
*ניתן להוסיף שדות : עדיפות, מטרת בדיקה, תוצאה בפועל, גרסת אפיון וכו' ....
|
צעד
(או שם מסך)
|
תיאור בדיקה
|
תוצאה צפויה
|
תקין - כן/לא
|
ישות נבדקת (ערך חד-ערכי)
|
שם הבודק
|
תאריך ביצוע הבדיקה
|
הערות
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2. אוכלוסיה נבדקת – ישות נבדקת (ערך חד-ערכי) -
במהלך הבדיקות מבצעים תהליכים בסביבת הבדיקות על
סוגים שונים של אוכלוסיות כגון: מלאי / לקוח / גיל וכו'
כאשר האוכלוסייה הנבדקת קריטית בתהליך הבדיקות יש לתעד את הישויות הנבדקות ע"י מספר חד ערכי : ת.ז / מס' לקוח כך תמיד תהיה נגישות לנתונים גם בעתיד כלומר לאחר סיום הבדיקות ואפילו לאחר שנה ויותר מיום הבדיקה.
3. הדפסת / צילומי מסך –
לפעמים בודקי התוכנה נדרשים לתעד רצף צילומי מסכים עד לקבלת הודעת השגיאה.
תיעוד המסכים יכול להתבצע ע"י :
הדפסת המסכים הנבדקים –
ניתן להדפיס את רצף המסכים לפני ואחרי הבדיקה וע"י כך
ליצור תיעוד של תפקוד המערכת בגרסה הרלוונטית.
אך חשוב לזכור שתיעוד בצורה זו גוזל הרבה דפים, דיו,
קלסרים ומקום על המדפים – בעידן הירוק עלינו לצמצם את כמות
הדפים וע"י כך להביא לצמצום כריתת יערות הגשם והקטנת עלויות.
אציין כי, קיימות בשוק תוכנות ייעודיות לביצוע צילומי מסכים
לדוגמא – תוכנת snagit .
צילומי מסכים והקלטת וידיאו בתיקיה ציבורית ברשת -
כדי לחסוך בדפים ובכל זאת ליצור תיעוד של תהליך הבדיקה ניתן ליצור תיקיה ראשית ברשת המשותפת לכל המשתמשים.
בתיקיה זו , ניתן לשמור צילומים (כמובן בצורה מסודרת ע"פ – גרסה,
מספר אפיון וכו'....)
ולהציג אותם לכל גורם בתהליך ע"י שליחת הלינק (URL ) לתיקיה.
אפשרות צילום מסכים במהלך הבדיקות קיים במערכות כגון :Quality Center.
תיעוד נוסף נעשה בעזרת הקלטת וידאו, ישנם מקרים בהם רצף הצילומים אינו מספיק ברור כדי להבין את מהות הבאג (בנוסף להסבר המילולי - חובה) במקרים אילו, מומלץ להשתמש בהקלטת וידיאו המציגה את רצף הפעולות שביצע בודק התוכנה
עד לקבלת הודעת השגיאה. אופציה זו קיימת בתוכנת snagit.
4. תיעוד הבאגים –
חובה לתעד כל תקלה שנמצאה במערכת גם אם בסוף התהליך
לא בוצע תיקון בקוד.
עבודה בצורה זו תמנע טעויות רבות בתהליך הפיתוח ולכן חשוב
להפנימה כנוהל עבודה.
תופעה רווחת שראויה לתשומת לב היא טיפול בבאגים
דרך מערכת המיילים על מנת לזרז או לוודא האם באמת מדובר בבאג או בבעיה תפעולית.
אי פתיחת באג במערכת ייעודית או כל פורמט מסודר אחר,
אשר יוצר רצף מתודולוגי מסודר בין צוות הבדיקות לפיתוח,
יכול ליצור מצב של העברת באגים ליצור (PROD) ובכך לפגוע באיכות המוצר.
כיצד פותחים באג בצורה נכונה ? גם זו מתודולוגיה סדורה שנפרט עליה במאמר אחר.
|
בטעינה...
