
הטקסט המלא של הדקות הראשונות בהרצאה «הבדל בין Black box בין White box» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום לכולם, בשיעור הקרוב נלמד מושגים חשובים בחומר ההסמכה ל-ISTQB, חומר ההסמכה לבודקי תוכנה. המושגים שבהם נתמקד בשיעור הקרוב ובסרטון הקרוב הם White Box ו-Black Box Testing, בדיקות קופסה לבנה מול בדיקות קופסה שחורה.
בסיום השיעור הקרוב תוכלו להבין ולדעת את המושגים בדיקות קופסה לבנה מול בדיקות קופסה שחורה. אז על מנת להבין את המושג בדיקת קופסה שחורה נכיר את שלבי הפיתוח.
יש לנו רשימת Requirement, יש לנו צוות פיתוח R&D שמעבד את הדרישות של צוות המוצר, של מאפייני המוצר, לדוגמה אתר כלשהו שצריך לפתח, או אפליקציית אנדרואיד, או אפליקציית iOS שצריך לפתח, לוקחים את ה-Requirement ומתחילים לממש את
זה. איך עושים את זה? מתחילים לכתוב קוד, מתחילים לעבוד בפרויקט של כתיבת קוד. הפרויקט יכול להיות בשפת תכנות כלשהי Java, .NET, C-Sharp, PHP, Kotling או כל שפה אחרת, כמובן שיש הרבה שפות אחרות.
לאחר מכן מתבצעת בנייה של הקוד שנכתב על ידי צוות הבדיקות שמממש את ה-requirement ומתקבל המוצר הסופי, אותו אתר, אותה אפליקציה שבה עושים שימוש על לקוחות.
איפה נכנס צוות הבדיקות לתרשים הזה, לחלק הזה של הפיתוח? בעצם יש לנו איזשהו תרשים זרימה Life Cycle, מחזור חיים של פיתוח. כרגע אנחנו מכניסים לתמונה גם את צוות הבדיקות.
בא הבודק ומסתכל על האפליקציה, על התוצר הסופי, אוקיי? ומתייחס לכל התהליך שקדם לתהליך של היצירה של האפליקציה כקופסה שחורה, אוקיי?
בעצם הוא מתעלם ממה שקדם, את כל התהליך של המימוש עצמו, את כתיבת הקוד, את השאילתות בפנים, ובעצם מתמקד רק בתוצר הסופי של האפליקציה, ואז הוא מתחיל להריץ functional tests, בדיקות פונקציונליות, בדיקות לא פונקציונליות, בדיקות שימושיות, בדיקות אינטגרציה,
בדיקות רגרסיה, סיפורי לקוח שממומשים ל-Test Cases. והם חלק מהבדיקות שפיות או מהבדיקות רגרסיה כאמור. אז בעצם כשאנחנו מדברים על בדיקות קופסה שחורה זה ההתמקדות, ההגדרות האלה, המושגים האלה מדברים על איפה נמצא המיקוד של צוות הבדיקות.
ובקופסה שחורה כל התהליך שקדם לחלק של התוצר הסופי של אחרי הביט והקומפייל והיצירה של המוצר הסופי, של אותו אתר, אותה אפליקציה, אותה מערכת שאנחנו בודקים, בעצם כל זה הוא בעצם קופסה שחורה ואנחנו בודקים רק את התוצרים, אוקיי?
אם מדובר לדוגמה באתר שמאפשר תשלום דוחות, לדוגמה דוחות תנועה או דוחות חנייה, אנחנו לא נתעסק כלל בתהליך באיזה שפה נכתב האתר, אלא רק נתייחס לסיפורי לקוח, לבדיקות פונקציונליות, לבדיקות אינטגרציה, לדוגמה היכולת לשלם בכרטיס אשראי בצורה מוצלחת ולקבל מספר אישור.
אוקיי, זה מה שמעניין אותנו, התוצר הסופי וחוויית המשתמש. אחרי שהכרנו את המושג בדיקת קופסה שחורה, קוד קופסה שחורה, אנחנו נעבור למושג המקביל אליו, שזה בדיקות קופסה לבנה, White Box Testing.
יושב צוות הפיתוח, יש לו Requirement והוא מתחיל לממש, מתחיל לעשות צ'ק אין צ'ק אאוט לקוד, בעצם מתחיל לכתוב גרסאות לקוד, ונוצר לנו פרויקט של קוד.
נוצר לנו פרויקט שמכיל המון המון מתודות, המון פונקציות, המון קלאסים שאנחנו משתמשים בהם, אם זה פרויקט מונחה עצמים כמו Java או .NET, אז יש לנו הרבה אובייקטים, הרבה הורשה, כל שאר הדברים שמאפיינים פרויקט פיתוחי אבל אז שלא כמו בדוגמה של אופסה שחורה אז מגיע צוות הבדיקות והוא מתחיל
לסרוק את הקוד מתחיל לראות את הפרויקט מתחיל להריץ את הפרויקט לפני שלב הקמפול הסופי לפני שלב הייצור של המערכת כמוצר מוגמר של