
הטקסט המלא של הדקות הראשונות בהרצאה «בדיקות קופסא לבנה» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
בשיעור הזה אנחנו נדבר על בדיקות קופסה לבנה בדיקות קופסה לבנה זה אומר בעצם לרדת לרמה של שורות הקוד אם יש לכם ידע והבנה בלדעת איך מתכנתים, תכלס, איך כותבים שורות הקוד היכולת הזאת לראות את המערכת ברמה שלה, מי שכותב אותה יכולה להעניק לכם את היכולת לבצע בדיקות ברמת הקוד ברמת הקוד והארכיטקטורה של המערכת
לדבר הזה קוראים בדיקות קופסה לבנה עכשיו, בדיקות ברמת התוכנה פנימה, כלומר בדיקות שמעורבות ברמת שורות הקוד זה נקרא Static Whitebox Testing שזה בעצם בדיקות קופסה לבנה סטטיות הרעיון של זה זה בעצם לעבור ולסקור בצורה שיטתית לעשות ריוויו לקוד ולארכיטקטורה מבלי לבצע פעולת Executing שזה פעולת הוצאה של התוכנה כאילו שתעבוד
הדבר הזה גם נקרא בשפה המקצועית Structural Analysis מטרת בדיקות קופסה לבנה היא לנסות לאתר את הבאגים עוד בשלב הפיתוח. כלומר מי שמבין בתכנות רואה איך המתכנת כתב את השורות קוד והוא יכול לנסות לאתר כבר בבעיה אם המתכנת כתב את השורות קוד שלו בצורה לא מקצועית הוא יכול לאתר את זה כבר שמה.
מה הרעיון? כבר דיברנו על זה כדי למנוע עלות יקרה יותר של איתור הבאג בשלב מתקדם יותר של הפיתוח. מה זה פורמל ריוויוז? פורמל ריוויוז זה תהליך רשמי שהוא בעצם תהליך סקירת הקוד.
המתכנתים עוברים על הקוד, אנשי ה-QA ששולטים בקוד עוברים על הקוד, הם קובעים מהם כללי הבדיקה, הם מבצעים חלוקת תפקידים ואחריות בין המשתתפים, והם מפיקים דוח ממצאים על מה היו תוצאות הבדיקה.
אז אם אני מבצע פורמל ריוויוז, שזה בעצם כתיבת דוח ממצאים, אני מגיע למצב שתוצאות הסקירה של הפורמל ריוויוז של בדיקות הקופסא הלבנה, הוצאות הסקירה של בדיקות הקופסא השחורה מסייעות לשלב הבדיקות הקופסא השחורה בכך שניתן ביתר קלות להגדיר מקרי מבחן
במיקומים שנראים כבעייתיים יותר בתוכנה. כלומר, התהליך של ה-Formal Reviews עוזר לי לבצע את ה-Equivalent partitioning. עצם התהליך הרשמי והמסודר של סקירת קוד עוזר לי בעצם לאתר באקים עוד בשלב הראשוני. מדוע?
בגלל שיש לי מסמך שאני יכול לפנות אליו. עכשיו, אני לא אבצע, להימנע מלבצע סקירה פורמל ריוויו כפתרון הדוק אופנתי, כלומר פתרון עכשווי כזה שאני אומר אוקיי צריך לעשות את זה כי צריך לבצע עוד מסמכולוגיה, לא.
הרעיון הוא שעצם הביצוע של הדוח הזה, עצם הביצוע של הדוח נמצאים מאפשר למתכנתים ללמוד ממפתחים בעלי ניסיון רב יותר, כי יש פה הם מתחככים אחד עם השני והמתכנת גם חייב להתאמץ לכתוב קוד יותר נכון כי הוא יודע שהוא נתון לתחת ביקורת.
בתוך הזה גם מאפשר למנהלי הפרויקט לקבל כלי מהקו איך הפרויקט הזה מתקדם, אז זה התפקיד של ה-Formal Reviews. זה כמו איזה סוג של Brain-Storming ממוסמך, כל המתכנזים הצעירים מנהלי הפרויקטים מרוויחים מזה.
גיידלנד וסטנדרטס, כדי לדעת איך בכלל לעבוד עם מדריכים וסטנדרטים בתעשייה הזאת, כשל-QA יש איזה שלוש אגודות, שלוש עמותות ה-NC, טכנולוגי אמריקן ניישנל סטנדרט אינסטיטוט, ה-IEEE שזה Institute of Electrical and Electronics Engineers הם קובעים סטנדרטים בתעשייה הזאת, אתם יכולים
לראות את הכתובות שלהם פה, וגם ה-ISO נתונה של Organization for Standardization, זה ISO אז שם אם אתם רוצים לבדוק איזה מסמכי בדיקה יש האחרונים, מהם התקן למסמכים של הבדיקות, מהו התקן למסמכים של פיתוח, כל הנתונים האלה בדרך כלל נמצאים דווקא באדר השלישי ב-IEEE