
הטקסט המלא של הדקות הראשונות בהרצאה «פרמידת הבדיקות» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום לכולם, בסרטונים הקרובים נדבר על רמות בדיקה. מה זה בעצם רמות בדיקה? רמות בדיקה הן קבוצות של פעילויות בדיקה שמאורגנות ומנוהלות יחד כאיזשהו שלב בתהליך שמשתלב עם תהליך פיתוח התוכנה.
דיברנו על Software Development Lifecycle, המחזור חיים של פיתוח התוכנה. יש לנו דוגמה לאיזושהי סכמה פשוטה של Software Development Lifecycle, יש לנו את שלב התכנון, שלב הפיתוח הבסיסי, שלב העיצוב של התהליך, שלב ההספקה בעצם, שלב ה-Maintenance, שלב ההספקה ללקוח. לכל אחד ואחד מהשלבים שראינו יש את הרמות בדיקה
המתאימות לו. אני רוצה לעבור איתכם על מצגת על מנת שהנושא הזה יהיה קצת יותר ברור. לכל אחד ואחד משלבי הפיתוח יש את השלב או את רמת הבדיקה המתאימה לו, כך שאפשר לצייר את זה או לייצג את זה בצורת פירמידה.
מהי פירמידת הבדיקות? הבסיס הרחב הוא שלב הפיתוח, שלב ה-Development, הפיתוח המאסיבי של כל הקומפוננטות, כל המתודות, הפונקציות, הקלאסים, הטבלאות, הקישור ל-DataBase, השאילתות.
כל השלב הזה מתבצע בחלק הראשון של ה-Software Development Lifecycle, ופה הרמת בדיקה היא Unit Test או Component Test, רמה של בדיקות רכיבים, כל רכיב שהולך להיות חלק מהקוד, חלק מהמערכת, חלק מהפרויקט, שבסוף ייצר את המוצר הסופי למשתמש הקצה.
בואו נדמה את התוכנה שלנו, נשתמש בדוגמה של מערכת ATM, מערכת למשיכת כסף בבנק. אז בשלב הזה בעצם אנחנו נבצע את כל הקידוד, את כל הטבלאות, את כל הקישוריות למערכת של האשראי, מערכת החשבונות של הבנקים.
בשלב הזה אנחנו נבצע את כל השאילתות אם לקוח צריך לוודא או לדעת את הפעולות האחרונות שבוצעו בחשבון שלו או רוצה לבצע משיכת כסף. בשלב הזה בעצם יתכתבו כל השאילתות, כל הפעולות.
בעצם באופן נפרד, כל רכיב ייבדק ברמה די בסיסית שלו. אם אנחנו מבצעים שאילתות לגבי מצב חשבון או פעולת משיכה, גריעה, מסלקה של הכסף, הוצאת תדפיס של מצב חשבון וכדומה, אנחנו נבדוק את כל הנתונים בשלב הזה.
לעיתים קרובות השלב הזה לא יבוצע על ידי הבודקים עצמם, אלא על ידי מפתחים שיבדקו מפתחים אחרים. השלב השני הוא שלב האינטגרציה או ה-System Test.
Integration Test ו-System Test זה שלב שבו כבר אנחנו יכולים לבצע איזושהי בדיקה, בשלב אמנם מוקדם, לפני שהלקוח הסופי יכול להיחשף למערכת, אבל כבר של חלקים במערכת בצורה מוגמרת, כולל גוי, כולל הקצה אל קצה, הנקודה שבה המשתמש יוכל לבצע פעולות בצורה שלמה. דיברנו על סיפורי לקוח, סיפורי משתמש, המשתמש שלנו רוצה להיכנס ולקבל דיווח על מצב
החשבון שלו. אז אנחנו כבר נוכל לבצע את התהליך הזה עם משתמשי הבדיקה שלנו, עם מערכת הבדיקה שלנו. כאן אנחנו רואים שכבר יש פחות קומפוננטות שחשופות, אנחנו כבר לא צריכים לבדוק את כל הקומפוננטות ישירות, אנחנו יכולים לעשות את
זה בצורה יותר מערכתית, יותר כללית, ומספר הטסטים יורד. יש לנו יחס של מספר קומפוננטות למספר טסטים.
אז הכמות הכי גבוהה היא בשלב ה-unit test, והכמות הנמוכה יותר היא בשלב האינטגרציה. והשלב האחרון, שבו הלקוח כבר יכול להיחשף אל התוכנה שאנחנו מפתחים, ה-acceptant test. ב-acceptant test אנחנו רוצים בעצם לבדוק את סיפורי המשתמש.
בחלק הזה, שימו לב, ויש את הכי פחות טסטים והכי פחות קומפוננטות.