מקרה לקוח – אפסים מובילים בתעודת הזהות גם לכשל כספי

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

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

מקרה פרטי שללקוח מסויים יש מספר זיהוי עם 7 ספרות בת"ז. אנחנו רגילים ל 9 ספרות, אולם ישנן אנשים עם מספרי זהות עם פחות ספרות.

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

הראשונה ברמת ה UI שאנחנו לא אוספים במידי את מספר הנייד, למקרה של נטישת עסקה בשלב מקדים.

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

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

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

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