כיצד לתעד נכון את הבדיקות שלכם !

מאת : נתי הורנשטיין , עורך אתר QAtest

אחד הנושאים החשובים בביצוע בדיקות תוכנה הוא תיעוד הבדיקות,

ללא תיעוד, לא ניתן לדעת אילו מצבים נבדקו,
האם בוצע כיסוי נכון לתהליך הנבדק, האם נבדקו כל מקרי הקצה,
האם סדרי עדיפות לבדיקות נכון ?

על בסיס האמרה המפורסמת "עשית ולא דיווחת - לא עשית", אפשר לומר:

נבדק ולא תועד = לא נבדק.

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

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

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

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

במאמר זה נעסוק בשאלה - כיצד לתעד נכון את בדיקות התוכנה ?

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

בנוסף, אם חמק באג למערכת המבצעית (PROD) ניתן לוודא האם תסריט X  או Y נבדקו בסביבת הבדיקות (TEST).

תיעוד הבדיקות מתחלק למספר קטגוריות: 

1.      מצבי הבדיקה – תסריט הבדיקות.

2.      אוכלוסיה נבדקת.

3.      הדפסות / צילומי מסך / הקלטת סרטון וידיאו.

4.      תיעוד הבאגים.

 1.מצבי הבדיקה – תסריטי הבדיקות –

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

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

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

בדיקות ללא תוצאה צפויה תביא אותנו למצב שבו כל תוצאה שמתקבלת יכולה להיות תקינה או להתחיל דיון האם התוצאה תקינה או לא ?? מומלץ לא לכתוב תסריטי בדיקות ארוכים מידי

 - עד 15 STEP.

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

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

לטובת תיעוד מצבי הבדיקה קיימים היום בשוק מספר מערכות כגון QualityCenter/

 Team Test  / Practitest / MS-TFS

 כלים נוספים ניתן למצוא באתר QAtest> תוכנות ועזרים לבודק.

כמובן שניתן להשתמש בגיליון אקסל פשוט, לדוגמא:  
         

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

.2 אוכלוסיה נבדקת – ישות נבדקת (ערך חד-ערכי) -

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

 בנוסף כאשר האוכלוסייה הנבדקת קריטית/ ייחודית מומלץ לתעד בתסריטים את שאילתת ה SQL שאיתרה את אוכלוסיית הנתונים.

 3. הדפסת / צילומי מסך -

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

תיעוד המסכים יכול להתבצע ע"י :

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

 צילומי מסכים  -

כדי לחסוך בדפים ובכל זאת ליצור תיעוד של תהליך הבדיקה (כאשר נדרש) ניתן ליצור תיקיה ראשית ברשת המשותפת לכלל המשתמשים. בתיקיה זו , ניתן לשמור צילומים (כמובן בצורה מסודרת ע"פ – גרסה, מספר אפיון, שם בודק וכו'...) כולל עיבוד קצר ב- paint עם הצבעה ברורה על הבעיה ולהציג אותם  לכל גורם בתהליך ע"י שליחת הלינק (URL) לתיקיה.

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

 הקלטת וידיאו

שיטה חדשה יחסית ומומלצת הינה תיעוד נוסף בעזרת סרטון של תהליך הבדיקה.  ישנם מקרים בהם רצף הצילומים אינו מספיק ברור כדי להבין את מהות הבאג (בנוסף להסבר מילולי שהינו חובה). במקרים אילו, מומלץ להשתמש בהקלטת וידיאו המציגה את רצף הפעולות שביצע בודק התוכנה עד לקבלת הודעת השגיאה. אופציה זו קיימת תוכנה  Quality Center, MS- TFS ו-   snagit.

4. תיעוד הבאגים - 

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

עבודה בצורה זו תמנע טעויות רבות בתהליך הפיתוח ולכן חשוב להפנימה כנוהל עבודה.

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

אי פתיחת באג במערכת ייעודית מסודרת, יכול לגרום למצב של העברת באגים ליצור (PROD) ובכך לפגוע באיכות המוצר/ הגרסה.

ע"פ פרופסור cem kaner אחד מהגורואים המובילים בארה"ב בתחום בדיקות תוכנה :
"טופס פתיחת תקלה הינו המסמך החשוב ביותר של הבודק". להלן מספר שדות שחובה למלא בכל תיעוד של תקלה:   

1.    טופס – תיעוד בטופס תקלה המקבל מספר חד-ערכי. בכל טופס תקלה תדווח רק תקלה אחת.

2.    Severity (חומרה) – דרוג חומרת התקלה (קלה, בינונית, חמורה, קריטית).

3.    Priority (עדיפות) – נמוכה, בינונית, גבוהה.

4.    סיווג התקלה – סיבת פתיחה: בעיית אפיון/דרישה, קידוד, הצעות לשיפור, הצעות לשינוי.

5.    שם פותח התקלה.

6.    שם אחראי לטפל בתקלה.

7.    סטאטוס התקלה.

8.    מספר התקלה – נומראטור שנותן באופן אוטומטי מספרי תקלות באופן רץ (כך שלא יהיה מצב לכפילות). 

9.    תאריך פתיחת התקלה.

10.    תאריך סגירת התקלה.

11.      שדה שחזור התקלה: שבו הבודק רושם האם ניתן לשחזר את התקלה או אירוע חד-פעמי.

12.           שדות לציון סביבת הבדיקה – סימון סביבת תוכניות, סימון סביבת DB.

13.         נושא התקלה.

14.           מספר גרסה שנבדקת.

15.           מספר ישות נבדקת – מספר לקוח / ת.ז/ מספר משלם/ מספר חשבון  (ערך חד ערכי).

16.           קישור התקלה לנושא הבדיקה (תרחיש הבדיקה והפיצ'ר/ הדרישה הנבדקת)

17.           קובץ מצורף (תמונה, סרטון, לוג)

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

דגשים לתיאור התקלה:

·       התיאור חייב להיות בנוי STEP BY STEP (צעד אחר צעד)

·       מה הם המסכים שעברנו עד קבלת הודעת השגיאה ?

·       מהי הפעולה שבוצע לפני קבלת התקלה/הודעת השגיאה ?

·       איך נוצרה התקלה ? מה הם הכפתורים שנלחצו לפני קבלת התקלה ?

·       מתי בוצע הפעולה ? שעה מדויקת!

·       הסבר למה זו תקלה ? תיעוד ע"י צילום מסכי המערכת.

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

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

 כמובן שמנתוני התקלות המדווחות, בסוף כל גרסה יש להפיק דוח סיכום בדיקות לגרסה S.T.R - Software Test Result (מסמך המתאר תוצאה  של הרצת סבב בדיקות על המוצר).

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

לסיכום – במה תהליך נכון של תיעוד יעזור לכם:

1. חסכון בזמן/יעילות - בדיקת התסריטים החשובים ביותר בשלב הראשון.

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

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