בדיקות הקבלה - חלק 2
פרקי ההרצאה: בדיקות הקבלה - חלק 2
תמלול ההרצאה: בדיקות הקבלה - חלק 2
הטקסט המלא של הדקות הראשונות בהרצאה «בדיקות הקבלה - חלק 2» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
בדיקות קבלה Accepted Testing כוללות גם בדיקות המבוססות על סעיפי חוזה ורגולציה. פיקוח בבדיקות חוזיות אנחנו נבצע את הבדיקות מול קריטריון הקבלה שנקבע בחוזה לפיתוח התוכנה.
בדיקות קבלה רגולטוריות לדוגמה יכולות להיות בדיקות הנגשה, בדיקות המחייבות את ספק התוכנה לדוגמה לחברה ממשלתית לספק תוכנה או מערכת שהיא נגישה לאנשים עם מוגבלויות פיזיות.
המטרה המרכזית של בדיקות הקבלה החוזיות והרגולטוריות היא בניית אמון בכך שדרישות החוזה או התקינה יתמלאו ושלא יהיה סיכון מבחינת תביעות או הפרת סעיפי תקנון או סעיפים רגולטוריים לספק התוכנה או לגוף הממשלתי שמספק את השירות לאזרח.
בדיקות Alpha ו-Beta בדיקות Alpha ו-Beta אופייניות לפיתוח של תוכנת מוצר מדף מסחרי, זאת אומרת Out of the Box או Out of the Shelf, שמסופקת ואמורה לעבוד בצד הלקוח, אצל הלקוח, בגוף הארגוני של הלקוח.
שארגון המפתח, שהגוף שמייצר את התוכנה, את האפליקציה, את המערכת, רוצה לקבל משוב ממשתמשים פוטנציאליים או קיימים, לפני שהמוצר בעצם יוצא לשוק באופן מלא, באופן חופשי, באופן ציבורי, יתבצעו בדיקות אלפא.
בדיקות אלפא נערכות עדיין באותו ארגון שמייצר את התוכנה. זאת אומרת, אם יש לנו גוף פיתוח או חברת פיתוח כמו אלביט או חברה אחרת שמייצרת תוכנה אז בעצם יזמנו את הלקוחות הפוטנציאליים או צוות שנקבע מצד הלקוח שאמור לקבל את התוכנה ולהשתמש בה לתוך אלביט לתוך הארגון שמייצר את התוכנה על מנת
לבדוק אותה ולראות האם הפעילויות והביצועים של התוכנה אכן מספקים ועומדים בציפיות. בדיקות בטא לעומת זאת, ההבדל המרכזי לעומת בדיקות אלפא זה שבדיקות הבטא יתקיימו כבר בארגון או בצד של הלקוח.
אם בדיקות האלפא מחייבות הגעה של הלקוחות לגוף המיישם, לגוף שמפתח, לגוף שבנה את האפליקציה, בדיקות בטא יתקיימו כבר בצד הלקוח, ממש בדיקות, אפשר להגיד פיילוט מבחינת המערכת, איך זה ייראה ממש בייצור, על ידי בודקים שיודעים שהמערכת היא בשלב העיצוב, שלב עדיין הפיתוח ובדיקות.
המטרה המרכזית של בדיקות אלפא ובטא היא קבלת משוב מהלקוחות או המפעילים, הקיימים או הפוטנציאליים, בכך שהמערכת עומדת בדרישות ובציפיות הבסיסיות שלהם במצבים רגילים, יומיומיים, שהיא עובדת גם מבחינה פונקציונלית אבל גם בסביבה שהם מצפים לראות אותה עובדת, הביצועים שהם מצפים לראות אותם ובמהירות של
התגובה שהציפייה שלהם היא ממנה. בשלבים של Alpha ו-Beta הרבה פעמים נקבל רג'קטים או באגים או פגמים שקשורים למהירות הפעולה, שקשורים לתגובות של המערכת.
בבדיקות Alpha ו-Beta הרבה פעמים נקבל גם פגמים שקשורים לסביבה. הרבה פעמים בסביבה הסטרילי של הארגון שמייצר את התוכנה, את האפליקציה או את המערכת לא ניתקל בתופעות שניתקל בסביבת הלקוח, הן מבחינת סוג המכשירים, הן מבחינת הקונפיגורציה של המחשבים, הרשתות וכדומה, העומס על המערכת
וכדומה. בסיס הבדיקות בשלבי האלפא והבטא, תהליכים עסקיים, סיפורי משתמש, דרישות עסקיות, רגולציה, פיקוח, סעיפים חוזיים שמדברים על מהירות תגובה, על סביבת עבודה, על גיבויים, מקרי שימוש, סיפורי
משתמש בעצם, דרישות מערכת, requirement, hardware requirement, דרישות מינימום מהמערכת,