טיפ 3 - 10 הכללים לתכנון בדיקות תוכנה


 
10 הכללים לתכנון בדיקות תוכנה

משולחנו של נתי הורנשטיין
 עורך אתר QAtest


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

בעבודתי עם אנשים, אני נתקל לא פעם באנשים האומרים – "אין זמן לתכנן בדיקות התחלנו לבדוק...",
"כשיהיה לי מסמך ייזום/אפיון מושלם... אז אוכל ..", "אני צריך... יותר זמן ...", "מה שחסר לי כדי להיות באמת יעיל, זה..." וכו'.
מה שאני מיד מזכיר להם, הוא שאנו חיים בעולם עסקי מהיר. חשיבות הכניסה לשוק היא מאוד קריטית לארגון TIME TO MARKET)) ולמרות שזה אולי קצת לא נעים לשמוע, תקופת המוצרים (תוכנות) היא מוגבלת.
כאשר אנו מבינים שהמוצרים כאן לתקופה מוגבלת, זה מחייב את העוסקים בתחום הבדיקות להיות יעילים ומהירים ככל שניתן.
אני מניח שישנם אנשים שיאמרו כי אינם מסכימים עם אמירה זו, וכי לפעמים ישנם גישות ומתודלוגיות אחרות, אירועים וכדומה שמרגיזים, מעצבנים ומשפיעים על תהליך הבדיקות ומונעים מהם להיות איכותיים ומהירים.
ולכן ריכזתי כאן, את "10 הכללים לתכנון בדיקות תוכנה" שלי – שאני בטוח שאם תיישמו אותם, יהיה לכם קל יותר בחיי היום יום כעוסקים בתחום הבדיקות.
הבנה של צרכי הלקוח (הדרישה העסקית)
האם חשבתם פעם, כמה זמן אתם מבזבזים על הבנה מה בדיוק הלקוח רוצה ?
בקריאת מסמכי ייזום (דרישה) ? הבנת האפיון – מה אתם קוראים? האם אלו מסמכים ברורים, מעודכנים,
הלוואי... רוב מה שאתם קוראים אינו עונה ב 100% לצרכי הלקוח.
אין זה אומר כי עליכם לחיות במנותק למה שקורה מסביבכם, אבל כשאתם מודעים לחשיבות שיש לתוכן
מסמכי הייזום ואפיון, ככל שתמונת הצורך העסקי תהיה ברורה כך תוכלו להיות יותר ממוקדים.
כאשר מתכננים בדיקות עם מסמכי ייזום ואפיון לא מושלמים או עדכניים זה משפיע על תכנון הבדיקות
שלכם ועל תוצאות הבדיקות שלכם בין אם אתם מודעים לכך או לא.
לסיכום, יש לוודא הבנה מהיבט הלקוח.
תכנון בדיקות
השלב החשוב ביותר ואין להתחיל בבדיקות או בכתיבת תסריטי בדיקות ללא ביצוע מיפוי
כללי של כלל מצבי הבדיקה.
ללא תכנון בדיקות מסודר אין להתחיל בתהליך הבדיקות.
תכנון בדיקות ניתן לבצע ע"י תרשימי זרימה / טבלת החלטה או כל דרך אחרת.
תכנון הבדיקות: הבנת צרכי הלקוח, מיפוי מצבי הבדיקה ורק לאחר מכן כתיבת תסריטי הבדיקות.
זמן השקעה בתכנון הבדיקות
שאלת המיליון, כמה זמן להשקעה בתכנון הבדיקות ?
ממוצע הזמן הדרוש הוא בין 30%-40% מכלל הזמן שהוקצב לטובת הבדיקות.
לדוגמא: אם מדובר בפרויקט בדיקות שמתוכנן לו 100 ימי בדיקה, זה אומר ש 30-40 ימים צרכים להיות לטובת תכנון הבדיקות.
תוצאה צפויה של כל צעד
כתיבת תסריטי הבדיקות חייבת להתבצע בצורה מובנת ומסודרת – חלק זה נכון וברור לכל העוסקים בתחום הבדיקות. עד כאן הכול בסדר ..
וזו הנקודה החשובה - לכל צעד וצעד (STEP) שנבדק חייבת להיות מראש תוצאה צפויה.
עוד בשלב תכנון הבדיקות אנו חייבים להבין מהי התוצאה הצפויה בכל שילוב אפשרי של הפרמטרים.
בדיקות ללא תוצאה צפויה תביא אותנו למצב שבו כל תוצאה שמתקבלת יכולה להיות תקינה או להתחיל דיון האם התוצאה תקינה או לא ??
כיסוי מלא של תסריטי הבדיקות
כיצד להפיק כמות גדולה של מקרי בדיקות ממסמכי הבדיקות ? הרעיון מבוסס על שיטה פשוטה בניתוח
מערכות: קח שני מרקרים (למשל, ורוד וצהוב), עבור על מסמך הדרישות / אפיון, צבע בצבע אחד את
כל שמות העצם, צבע בצבע אחר את כל הפעלים. כל שם עצם יהפוך לאובייקט (טבלהב-DB, קלאס),
כל פועל יהפוך לפונקציה.
דגשים לבדיקות
עברנו דרך ארוכה של הבנת צרכי הלקוח, תכנון הבדיקות, בדיקה לכיסוי מלא של התסריטים ועכשיו חשוב מאוד !
נא ליזום פגישה עם נציג מטעם הלקוח להציג בפניו את תכנון הבדיקות ולקבל ממנו דגשים נוספים לבדיקה.
טמפלט לסוגי בדיקות
חשוב לוודא שקיימת התייחסות לרמות וסוגי בדיקות.
לכן מומלץ ליצור טמפלט המחולק בצורה כזו, לדוגמא:
- בדיקות פונקציונאליות
- בדיקות GUI
- בדיקות רגרסיה
- בדיקות שליליות – צריכות להוות לפחות 30% מכלל התסריטים – רוב התקלות נפתחות
באזור זה.
ניתן להוסיף עוד תלוי בסוג בפרויקט ו….
צמצום בכמות התסריטים
מתקדמים ....ועכשיו חשוב לבדוק מול ראש צוות הפיתוח או המתכנת, האם הרכיבים הנבדקים הם גנריים במערכת המידע הנבדקת ועקב כך ניתן לצמצם בכמות התסריטים.
תכנות גנרי הוא הדרך לכתיבת תוכניות שאינן תלויות בטיפוסי המשתנים. בד"כ קיימת התלות של שיטות ותוכניות בטיפוס הנתונים הניתן להם, אך כאשר קיימת תוכנה גנרית ניתן לחסוך תסריטים, כמובן שרק לאחר חשיבה מסודרת.
עדיפות לתסריט
קרובים לסיום .....
חשוב לזכור ! לא כל התסריטים נמצאים באותה רמת עדיפות ולכן חשוב להתחיל לבדוק את המערכת מהתסריטים
בעלי עדיפות גבוהה.
לדוגמא:
תסריט 1 - בדיקת חישוב חשבון חודשי של לקוח סלולארי – עדיפות גבוהה.
תסריט 2 – בדיקה שסכום החיוב נרשם בפונט Arial כמו כל חשבון הלקוח – עדיפות נמוכה.
אם וכאשר לוחות הזמנים משתנים והמוצר חייב לעלות ליצור, חובה לסיים את כל התסריטים בעלי העדיפות הגבוהה.
10. ניהול תקלות הפיתוח - עדיפות וחומרה לכל תקלה
בודקים...אז יש תקלות .....
גם כאן, לא חייבים לטפל בכל תקלה שנפתחה, רצוי ואף חובה לתת עדיפות וחומרה
לכל תקלה ולטפל בתקלות בחומרה גבוהה לפני שמטפלים בתקלות בעדיפות נמוכה.
בסוף הפרויקט אם יש זמן ניתן לתקן את כל בתקלות.
מס' תקלות לפרויקט / חומרה
שם פרויקטגבוהה -1בינונית - 2נמוכה - 3
קליטת עסק חדש


מוצר חדש


קליטת תשלום


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