נספח א: איך מייצרים ראיות שאפשר להתווכח עליהן

נספח א. איך מייצרים ראיות שאפשר להתווכח עליהן — ולא רק להתרשם מהן#

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

מדרג שימושי של ראיות#

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

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

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

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

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

איך נראית טענה מבוקרת#

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

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

אל תתבלבלו בין שלושה סוגי תקינות#

תקינות תחבירית: פלט מתאים למבנה, קוד מתקמפל, תשובת API חוזרת בצורה תקינה.

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

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

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

להעמקה בהמשך: מדריך ייעודי לבניית בדיקות QA איכותיות וליצירת בודק AI יעסוק בתכנון מקרי בדיקה, הפעלת בדיקות, איסוף ראיות ובקרת התוצאות. הנספח כאן נשאר חלק עצמאי ושימושי של המדריך הנוכחי.