תכנון מקרי בדיקה - בדיקות תוכנה


תכנון מקרי בדיקה - בדיקות תוכנה

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

לפרטים ורכישת הספר ראה בהמשך העמודים באתר QAtest או  - לחץ כאן


אפשרות 1:

ויפול קוצ'ר - הרחבת טכניקת "שמות עצם ופעלים" 

כיצד להפיק כמות גדולה של מקרי בדיקות ממסמכי הבדיקות. הרעיון מבוסס על שיטה פשוטה בניתוח מערכות: קח שני מרקרים (למשל, ורוד וצהוב), עבור על מסמך הדרישות,צבע בצבע אחד את כל שמות העצם, צבע בצבע אחר את כל הפעלים. כל שם עצם יהפוך לאובייקט (טבלה ב-DB, קלאס), כל פועל יהפוך לפונקציה. עד כאן הרעיון המקורי, היישר משנות השבעים של המאה הקודמת (ועדיין עובד).
עכשיו ההרחבה:
הרעיון הוא להשתמש בכלים מנטאליים פשוטים על-מנת לקחת משפט ממסמך האפיון ולמצוץ ממנו את המיץ. הכלים המנטאליים הם שאלות ה - -WH המוכרות:

 (מי, מה, איפה, מתי, למה, איזה...)ועכשיו החוכמה היא להפעיל אותם *בשיטתיות* על שמות העצם והפעלים שמצאנו. התשובות לשאלות הללו יפיקו שמות עצם ופעלים נוספים, שגם עליהם צריך לשאול את ה-WH, עד שמגיעים למיצוי הדרישה (או למפץ הגדול, או לקיום האל). תזכרו  - השיטה מיועדת לבודקים חדשים, שלא בהכרח יכולים לשלוף את כל זה מהשרוול!
דוגמא: נגיד שבמסמך האפיון של הפורומים מופיע המשפט הבא: "המשתמש יוכל להגיב להודעות בפורום על-ידי לחיצה על כפתור "הוספת תגובה". פעולה זו תפתח את מסך עריכת תגובה."
שלב ראשון - זיהוי שמות עצם ופעלים:
שמות עצם: משתמש, הודעה, פורום, כפתור "הוספת תגובה", מסך עריכת תגובה.
פעלים: להגיב, לחיצה, פתיחה.
שלב שני - שאלות WH (במקרה הזה - על שם העצם "משתמש"):
מי המשתמש? הוא ידוע (logged-in)? לא ידוע?
מהו המשתמש? מה התפקיד שלו? הוא משתמש רגיל, אדמיניסטראטור? מנהל פורום?
איפה המשתמש? בהודעה הראשית של השרשור? באמצע? בהודעה אחרונה?
זהו. לא רעיון מתחום הפיזיקה הקוונטית, אבל מספיק פשוט ושימושי כדי לזכור, בשביל הפעם הבאה שנצטרך להסביר לבודק חדש איך להוציא טסטים מהדרישות. קישור למקור הכתבה:

http://www.tapuz.co.il/Forums2008/ViewMsg.aspx?ForumId=936&MessageId=102086727

אפשרות 2:

תרשים זרימה

 תרשים זרימה של דילמת אומגה - ויקיפדיה.

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

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

 סמלים נפוצים בתרשים זרימה

·                     מלבן - תהליך

·                     מלבן עם קוים אנכיים - תהליך המוגדר מראש

·                     מעוין - צומת החלטה

·                     טרפז הפוך - פעולה ידנית

·                     משושה רחב בסיס - הכנה

·                     אליפסה - סיום

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

אפשרות 3:

טבלאות החלטה

טבלאות החלטה - WikiBook 

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

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

 

 

 

 

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