
הטקסט המלא של הדקות הראשונות בהרצאה «בדיקות הקבלה - חלק 1» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום לכולם. בשיעורים הקודמים הכרנו את רמות הבדיקה. אמרנו שרמות בדיקה הן קבוצות של פעילויות בדיקה שמאורגנות ומנוהלות ביחד בהתאם לשלב שבו אנחנו נמצאים במחזור החיים של פיתוח התוכנה.
Software Development Lifecycle. הכרנו את בדיקת הרכיבים, בדיקות האינטגרציה, בדיקות מערכת, ואנחנו נכיר היום את בדיקות הקבלה. אם אנחנו מסתכלים על איזשהו תרשים זרימה של ה-Software Development Lifecycle, המחזור החיים של פיתוח התוכנה אנחנו רואים שיש לנו את שלב האפיון, שלב התכנון, האפיון והתכנון, אחד ושתיים, שלב הפיתוח וארבע טסטינג,
חמש maintenance. זוהי חלוקה קצת מיושנת. היום הגישה אומרת שהבדיקות, תהליך הבדיקות לא נמצא בשלב ספציפי מבודד אלא בכל שלבי הפיתוח.
גם בשלב אחד ושתיים, שלב ה-requirement וה-design, שלב האפיון והתכנון, גם שם מבוצעות תהליך של בדיקה וביקורת, הן על ידי הטסטרים עצמם, אנשי הבדיקות, והן על ידי גורמים אחרים בארגון. בשלב הפיתוח, אמרנו, שלב בדיקות הרכיב, קומפוננט טסטינג, שזה מבוצע הרבה פעמים לאו דווקא על ידי הבודקים עצמם, אלא על ידי צוות המפתחים עצמם,
שבעצם רוצים לבדוק שאכן הקומפוננטות, הקלאסים, המתודות, הפונקציות, השאילתות, בצורה האופטימלית והנכונה. שלב 4, הטסטינג הוא באמת שלב האינטגרציה והסיסטם טסט, זאת אומרת השלב שבו אפשר לבצע את הטסטים בצורה מקצה עד קצה בעצם end-to-end אפשר לדמות תהליכים מבוססים סיפורי לקוח סיפורי משתמש
דיברנו על הדוגמה של המערכת ATM מערכת למשיכת כספים אז פה יש לנו את השלב של בניית המערכת 1, 2 ו-3 בשלב 4 יש לנו את שלב הבדיקה שכבר בודקת האם המשתמש יוכל לבצע את כל הפעולות, החל מזדהות בהקשת קוד סודי וכלה במשיכת כסף או בבירור יתרה או בקבלת פרטים אחרים מהמערכת.
שלב 5, אנחנו נכיר אותו, זה שלב ה-Maintenance בעצם, שבו המערכת מתוחזקת כבר בצד הלקוח. אפשר להגיד ששלב 4 הוא לא מבוצע רק על ידי בודקים אלא גם יכול להתבצע על ידי גורמים בארגון, לקוחות המערכת.
אם אנחנו מכירים ואנחנו נדבר על המושגים האלה בדיקות אלפא ובטא אז אנחנו נראה שהם מתמקדים בשלב 4. כשאנחנו מגיעים לבדיקות קבלה זה אומר מבחינת צוות הפיתוח, מבחינת צוות התכנון, צוות היישום של המערכת שהוא צריך לספק את המערכת בצורה השלמה.
יכול להיות שחלקים ממנה עדיין לא יהיו מוגמרים אבל זה צריך להיות מוסכם וצריך להיות ידוע מבחינת היקף הבדיקות, מבחינת הסקופ של הבדיקות זאת אומרת כשאיש הבדיקות מגיע לבדיקות קבלה אקספטנט טסט הוא צריך לדעת בדיוק את הסיפורי משתמש שניתן להריץ סיפורי משתמש סיפורי לקוח המטרות של
בניות הקבלה בדיקות הקבלה בניית אמון באיכות המערכת בשלמותה זאת אומרת המוצר המוגמר כל המערכת אם אנחנו שוב בדוגמת המערכת ה-ATM משיכת כספים המערכת של הכספומט בעצם אנחנו מדברים על זה שאנחנו נוכל להגיד שהמערכת עובד בשלמותה, כל התפריטים, כל האופציות שמוצגים למשתמש הקצה גמורים וניתנים לבדיקה.
מטרה נוספת של בדיקות הקבלה, וידאו שהתנהגות הפונקציונלית והלא פונקציונלית, נדבר על המושגים האלה של המערכת הן בהתאם לאפיון.
בדיקות קבלה אמורות לספק מידע שישמש להערכת מוכנות המערכת להפצה ולמגע עם המשתמש הלקוח האמיתי בסוף התהליך. בשלב הזה המטרה היא אמנם לבדוק את המערכת, לבדוק מוכנות מערכת, לנסות לאתר פגמים ותקלות אבל שימו לב בנקודה הזאת הארגון לא מצפה להגיע למצב שיש הרבה תקלות קריטיות הרבה תקלות
משמעותיות אקוטיות שפוגעות בליבה של המוצר אם נגיד אנחנו בבדיקות הקבלה לא נוכל לבצע משיכת כסף שזה סיפור משתמש בסיסי של כספומט, זאת אומרת אנחנו נוכל להבין שיש סיכון גדול מבחינת הפרויקט על עצם המשמעות