עקביות בין שדות זהות: מדוע בדיקות עוברות על נתונים גרועים

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

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

מדוע שדות נכונים בנפרד יוצרים רשומה שגויה?

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

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

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

היכן חוסר עקביות הופך למעבר כוזב

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

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

האם נתונים לא עקביים צריכים להידחות או להתוקן?

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

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

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

כמה חזקה צריכה להיות בדיקת עקביות?

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

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

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

האם רשומות מופקות צריכות להיות עקביות בכל האצווה?

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

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

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

אילו זוגות נשברים לרוב בפועל?

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

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

למפתחים: היכן לאכוף את הכללים

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

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

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

הצעדים הבאים

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