מצבי הבדיקה: Black Box, Grey Box ו-White Box

זו נקודה שכדאי לומר במפורש: אלה מצבים, לא רמות. White Box אינו “בדיקה יסודית יותר” ו-Black Box אינו “בדיקה חלקית”. כל מצב חזק במשהו אחר ועיוור למשהו אחר, והבחירה ביניהם היא החלטה עסקית ולא החלטה על עומק.

שלושת המצבים

Black Box

הבודקים מקבלים את האפליקציה הרצה ומשתמשים לכל תפקיד, ותו לא: אין קוד מקור, אין מסמכי ארכיטקטורה ואין עזרה נוספת. זו העמדה שבה תוקף אמיתי נמצא.

חזק ב: כל ממצא הושג מהעמדה של תוקף אמיתי, ולכן ברור שאפשר להגיע אליו בפועל — אין ויכוח על כך שהוא ניתן לניצול.
עיוור ל: מסלולי קוד שהממשק לא מגיע אליהם. בדיקה שלא הגיעה למסלול לא הוכיחה שהוא תקין — רק שלא הצליחה להגיע אליו.
נבחר בדרך כלל כאשר לקוח, רגולטור או תהליך רכש מבקשים הערכה בלתי תלויה, שהתוצאה שלה לא נשענת על מה שהספק מספר על הקוד שלו.

Grey Box

הבודקים מקבלים את מה שאדם מבפנים היה יודע — ארכיטקטורה, מודל הנתונים, התפקידים ולעיתים גם חלק מהקוד — וממשיכים לתקוף את המערכת הרצה מבחוץ. זו לא פשרה בין שני המצבים האחרים אלא שיקול אחר: אותן בדיקות, מכוונות טוב יותר.

חזק ב: תפוקה ליום עבודה. הידיעה ששדה מסוים נכנס לשאילתה, או ששני שירותים בוטחים זה בזה, חוסכת את הימים שבדיקת Black Box משקיעה בהסקה שלה. הזמן הזה עובר לבדיקה עצמה.
עיוור ל: מה שהחומר שנמסר מטעה בו. כשהתיעוד והמימוש סותרים זה את זה, הבדיקה הולכת אחרי התיעוד אלא אם משהו סותר אותו — ולכן אנחנו מתייחסים לחומר שנמסר כהשערה ומאמתים אותו מול המערכת.
נבחר בדרך כלל כאשר רוצים את מירב הממצאים בזמן נתון ואפשר למסור לבודקים חומר פנימי.

White Box

הבודקים קוראים את הקוד בנוסף לתקיפת המערכת. כך מגיעים למסלולים שבדיקה חיצונית לא מגיעה אליהם: טיפול בשגיאות, פונקציות אדמין, קוד מאחורי feature flags, וענפים שרצים רק בתנאים שהממשק לא מייצר.

זה גם משנה מה נחשב ממצא. בדיקה חיצונית מדווחת על המקרה שאליו הגיעה; קריאת הקוד מראה אם המקרה הזה הוא מופע אחד של דפוס שחוזר לאורך הקוד — וזה בדרך כלל מה שכדאי לתקן. דלתות אחוריות, מכוונות או מקריות, מתגלות בפועל רק כך.

חזק ב: כיסוי של מסלולים שבדיקה חיצונית לא מגיעה אליהם, ובמתן שורש הבעיה במקום המופע הבודד.
עיוור ל: ההבדל בין הקוד לבין הסביבה שבה הוא רץ בפועל. קוד יכול להיות תקין והסביבה לא מאובטחת, ולכן בדיקת White Box מתבצעת מול המערכת הרצה בנוסף למאגר הקוד ולא במקומו.
נבחר בדרך כלל כאשר האפליקציה מטפלת במשהו שאסור לטעות בו, או כשצריך את הסיבה ולא את המופע.

איך בוחרים

• אם מישהו אחר צריך לסמוך על התוצאה — לקוח, מבקר, תהליך רכש — Black Box הוא בדרך כלל מה שהתכוונו אליו.
• אם התקציב קבוע ורוצים ממנו כמה שיותר — Grey Box כמעט תמיד מחזיר יותר, כי המיפוי שבדיקת Black Box משלמת עליו בימים נמסר בבוקר הראשון.
• אם טעות יקרה — תשלומים, מידע רפואי, בטיחות, כל דבר עם רגולטור — White Box הוא המצב היחיד שמגיע לקוד שהממשק לא מריץ.
• אפשר לערבב לפי רכיב. צורה נפוצה: White Box על שכבת ההרשאות ועל מסלול התשלום, Grey Box על כל השאר.

מה זה אומר על הכיסוי

המצב לא מוסיף ולא מוריד מקרי בדיקה. הוא משנה על איזה חלק מהאפליקציה כל מקרה יכול לחול, ובאיזה ביטחון אפשר לדווח על תוצאה שלילית. גם עומק הביצוע לא משתנה: בדיקה שסורק מבצע מתוארת כאוטומטית בכל מצב, ובדיקה שדורשת שיקול דעת מתוארת כידנית בכל מצב.

נשמח לשמוע מה אתם בונים

ספרו לנו מה המערכת עושה ומה מדאיג אתכם בה. נחזור אליכם עם שאלות אפיון, הצעה ברורה ולוח זמנים מציאותי — ואם בדיקה היא לא מה שאתם צריכים בשלב הזה, נגיד גם את זה. צרו קשר.