הבדלים בין Testing לבין Debugging
פרקי ההרצאה: הבדלים בין Testing לבין Debugging
תמלול ההרצאה: הבדלים בין Testing לבין Debugging
הטקסט המלא של הדקות הראשונות בהרצאה «הבדלים בין Testing לבין Debugging» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום לכולם, אנחנו ממשיכים עם סעיף 1.1.2 בחומר ה-STQB. בדיקות וניפוי באגים טסטינג מול דיבאגינג שתי פעולות שונות זו מזו הרצת בדיקות עשויה למצוא כשלים אשר נגרמים על ידי פגמים בתוכנה או באגים התרגום של פגמים זה באגים ניפוי באגים דיבאגים דיבאג הינה פעילות פיתוח שמוצאת מנתחת
ומתקנת את הפגמים את הבאגים האלה זאת אומרת אותו מפתח שכותב שורות קוד עשה איזשהו טעות, כתב שמשתנה לא נכון או סוג משתנה לא נכון ובעצם תהליך הדיבאגינג הוא ניטור התקלה על ידי הודעות שגיאה, על ידי אירו לוג, על ידי לוג רגיל בעצם והגעה
למקום שבו הייתה הגדרה לא נכונה או כתיבה לא נכונה ובעצם לתקן את זה. בדיקת אימות Confirmation Testing בודקת אם התיקונים אכן פתרו את הכשלים, הם פתרו את התוצרים של אותם פגמים.
אז לזכור שגם מבחינת השפה של ה-sdqb הפירוש שלו הוא באג. במקרים מסוימים הבודקים אחראים לבדיקות ראשוניות ולבדיקות העימות הסופיות.
בעוד שמפתחים עושים את ניפוי הבאגים, את הדיבאג ובדיקות הרכיבים, את יוניט טסטינג. יוניט טסטינג או קומפוננט טסטינג זה אומר בדיקה ממש ברמת הקוד.
נדבר על מושג נוסף שנכיר שזה white box טסטינג בדיקות קופסה לבנה שזה בדיקות קוד ממש. לעומת זאת, ברוב המקרים בודקי התוכנה, בודקי ה-QA יבדקו Black Box Testing שהם בודקים את התוצרים של המערכת ברמה של שלב האינטגרציה של הקומפוננטות אחת עם השנייה ולא ברמת הקומפוננטה עצמה שעומדת לבדה.
בפיתוח מסוג אג'ייל, אג'ייל זה סוג של מתודולוגיית פיתוח, הרבה פעמים משקיעים ומלמדים את הבודקים להיות מעורבים גם בשלב הדיבאג, בשלב הקומפוננט טסטינג או בדיקת הרכיב יוניט טסטינג.
מדוע בדיקות נחוצות? בדיקות קפדניות של תוכנה, מערכות והמסמכים שקשורות אל הפיתוח תוכנה, עשויות לסייע בהפחתת הסיכון להופעת כשלים בזמן הפעלת מערכת פיתוח תוכנה כמו כל דבר בחיים. אם אנחנו עושים את זה בצורה מסודרת, מתוכננת, מושכלת, סיכוי שהתוצרים יהיו בהתאם לדרישות עולה.
איכות התוכנה או המערכת עולה כשפגמים באגים נמצאים ומתוקנים בנוסף. בדיקות תוכנה עשויות להידרש על מנת לענות על דרישות חוזיות או חוקיות. בהרבה פעמים יש תקן שעליו החברה צריכה לעמוד, זאת אומרת, הקצאת מערך בדיקות על מנת לוודא שהלקוח הסופי יקבל את התוכנה כפי
שהוא מצפה לפי ה-Business Story ולפי ה-Requirement. איך הבדיקות תורמות להצלחה? לאורך כל היסטוריית המחשוב והתכנות, המערכות נמסרות לשימוש כשהן מכילות פגמים.
עקב כך מתגלים כשלים במערכות או כשהמערכות לא עומדות בדרישות בעלי העניין. זאת אומרת, כמעט לא נמצא מוצר תוכנה שהוא נקי מבאגים או מפונקציות לא תקינות או לא מלאות מבחינת המשתמש הסופי.
כמעט כל תוכנה שאנחנו מכירים, החל מאתרים מורכבים, אתרי קניות, אתרי שירות, אפליקציות, כמעט תמיד אנחנו נמצא דברים שלא עובדים בצורה כזאת או אחרת כפי שהיינו רוצים או שזה היה אמור להיות.
זאת אומרת, אפליקציות שנכשלות, אפליקציות שקורסות, הודעות שגיאה, כל אלה הם בעצם סוגים של פגמים באגים. שימוש בטכניקות בדיקה מתאימות עשוי להפחית את תדירות המקרים שבהן מערכות עם כשלים משוחררות למשתמשים במידה וטכניקות אלה מיושמות במומחיות ועל ידי
האנשים הנכונים ברמות הבדיקה המתאימות ובשלבים הנכונים במחזור חיי התוכנה, אז כל הבאגים וכל התקלות בעצם מתמעטות והופכות לנדירות יותר ופחות משמעותיות או פחות קריטיות.
בודקים המשתתפים בסקירה של דרישות או סיפורי משתמש עוזרים בזיהוי הפגמים הקיימים כבר בשלב התכנוני. זיהוי והסרה של פגמים בדרישות יפחית את הסיכון שהתוכנה תמומש או תממש יכולות שלא נדרשו, יכולות שגויות או כאלה שלא ניתנות לבדיקה כראוי.
שילוב בודקים בעבודה עם מתכנני מערכת בשלב עיצוב יגדיל את ההבנה של שני הצדדים בעיצוב המערכת ואיך לבדוק אותה. הבנה זו תפחית את הסיכון לפגמים בסיסיים בעיצוב המערכת ותאפשר לזהות את הבדיקות הנדרשות בשלב מוקדם ככל הניתן. דיברנו על זה שככל שיותר מהר אנחנו מערבים את צוות הבודקים,
ככל שיותר מהר הבודקים מעורבים ומכירים את המוצר, מוקדם או לזיהוי ואיתור תקלות בשלב מוקדם,