יש מערכות שאפשר להרשות לעצמנו לטעות בהן.

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

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

ולכן, כשאני מסתכל על בדיקות במערכות פיננסיות, אני לא שואל רק:

"האם הפיצ'ר החדש עובד?"

אני שואל:

"מה עוד יכול להשתנות בגלל הפיצ'ר הזה?"

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

למה בדיקות במערכות פיננסיות שונות מבדיקות רגילות?

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

במערכת פיננסית צריך לבדוק לפחות ארבעה דברים:

1. האם הפעולה הצליחה?
2. האם הסכום נכון?
3. האם הנתונים עברו נכון בין כל המערכות?
4. האם המצב שנוצר במערכת נשאר עקבי גם לאחר מכן?

לדוגמה, נניח שלקוח ביצע עסקה ב־1,000 ₪.

מבחינת המסך, הכול יכול להיראות תקין.

אבל מאחורי הקלעים יכולים להיות:

לקוח → אתר/אפליקציה → Payment Gateway → מערכת תשלומים → מערכת כרטיסי אשראי → מערכת חשבונאית → מערכת Legacy → מערכת דיווח

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

לכן בדיקות עומק חייבות להתייחס ל־End-to-End Business Flow, ולא רק למסך שבו בוצע השינוי.

השלב הראשון: להבין את הזרימה לפני שכותבים Test Case

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

במערכות פיננסיות אני דווקא ממליץ לעצור.

לפני Test Case ראשון צריך לבנות מפת זרימה.

לדוגמה:

Customer
   ↓
Frontend
   ↓
API
   ↓
Payment Service
   ↓
Card Processor
   ↓
Core Banking
   ↓
Accounting
   ↓
Reporting

עכשיו מתחילים לשאול שאלות:

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

רק כאן מתחילים להבין את עומק הבדיקה האמיתי.

לא לבדוק רק את ה-Happy Path

במערכת פיננסית Happy Path הוא אולי 20% מהסיפור.

נניח:

לקוח מבצע תשלום של 500 ₪.

התרחיש החיובי ברור:

Payment Request
↓
Authorization
↓
Success
↓
Database Update
↓
Receipt

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

למשל:

• הסכום הוא 0.
• הסכום שלילי.
• הסכום כולל יותר מדי ספרות אחרי הנקודה.
• המטבע שונה.
• הכרטיס פג תוקף.
• אין מספיק מסגרת.
• השרת של חברת האשראי לא מגיב.
• התשובה מגיעה באיחור.
• התשובה מגיעה פעמיים.
• המשתמש לוחץ פעמיים.
• נשלחת אותה בקשה פעמיים.
• העסקה אושרה אבל ה־DB לא עודכן.
• ה־DB עודכן אבל ה־response נכשל.
• העסקה נכשלה אבל המשתמש קיבל הודעת Success.
• שירות אחד מציג סכום בשקלים ושירות אחר בדולרים.
• נוצרה עמלה למרות שהעסקה בוטלה.

זה כבר Testing אמיתי.

בדיקות גבול הן קריטיות במערכות כספיות

במערכות פיננסיות, Boundary Value Analysis מקבלת משמעות הרבה יותר גדולה.

צריך לבדוק:

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

לדוגמה, אם מוגדר:

מקסימום עסקה: 10,000 ₪

לא מספיק לבדוק:

9,000

צריך לבדוק:

9,999.99
10,000
10,000.01

ואם קיימת מגבלה יומית:

99,999
100,000
100,000.01

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

בדיקות של דיוק כספי – מקום שבו אסור לסמוך על "נראה לי"

אחד הנושאים הרגישים ביותר הוא חישוב כספי.

צריך לבדוק:

• Rounding.
• עיגול כלפי מעלה.
• עיגול כלפי מטה.
• Decimal Precision.
• מטבעות שונים.
• המרות מטבע.
• עמלות.
• ריבית.
• הצמדות.
• הנחות.
• מסים.

לדוגמה:

100 × 17.5% = 17.50

אבל מה קורה כאשר החישוב הוא:

19.99 × 17.5%

ומה קורה כאשר מבצעים את החישוב על 10,000 עסקאות?

ייתכן שהפער של אגורה בעסקה בודדת הופך בסוף החודש לאלפי שקלים.

לכן בודק טוב לא מסתפק בבדיקה של עסקה אחת.

הוא בודק גם:

Accumulated Financial Accuracy.

בדיקות כרטיסי אשראי – העסקה היא רק ההתחלה

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

לדוגמה:

Authorization
↓
Capture
↓
Settlement
↓
Clearing
↓
Refund
↓
Chargeback

כל אחד מהשלבים יכול להיכשל.

צריך לבדוק למשל:

Authorization

• אישור.
• דחייה.
• Timeout.
• Retry.
• כרטיס חסום.
• כרטיס שפג תוקפו.

Capture

• Capture מלא.
• Capture חלקי.
• Capture כפול.
• Capture לאחר ביטול.

Refund

• החזר מלא.
• החזר חלקי.
• החזר כפול.
• החזר לאחר Settlement.

Chargeback

• פתיחת Chargeback.
• קבלת Chargeback.
• ביטול Chargeback.
• התאמת סכומים.

הטעות היא לבדוק כל פונקציה בנפרד.

הבדיקה החשובה באמת היא:

האם מצב העסקה נשאר עקבי לאורך כל מחזור החיים שלה?

בדיקות Idempotency – אחד הדברים החשובים ביותר בתשלומים

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

Idempotency.

נניח שהלקוח לחץ על Pay.

הבקשה נשלחה.

השרת ביצע את החיוב.

אבל התשובה לא הגיעה ללקוח.

המשתמש חושב:

"כנראה הייתה תקלה."

ולוחץ שוב.

אם המערכת לא תוכננה נכון, נקבל:

Transaction #1 = 500 ₪
Transaction #2 = 500 ₪

הלקוח חויב:

1,000 ₪ במקום 500 ₪.

לכן צריך לבדוק:

• אותה בקשה פעמיים.
• אותה בקשה מספר פעמים.
• Retry אוטומטי.
• Timeout + Retry.
• שני משתמשים במקביל.
• שתי בקשות עם אותו Transaction ID.

והשאלה המרכזית:

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

בדיקות Concurrency – מה קורה כששני דברים מתרחשים באותו זמן?

מערכות פיננסיות הן מערכות מרובות משתמשים.

לכן צריך לבדוק Race Conditions.

לדוגמה:

ללקוח יש:

1,000 ₪

ובאותו זמן יוצאות שתי פעולות:

Payment A = 700
Payment B = 700

האם שתי העסקאות יאושרו?

אם כן, ייתכן שנוצר מצב:

יתרה = מינוס 400 ₪

למרות שהמערכת אמורה למנוע זאת.

לכן צריך לבצע בדיקות במקביל ולא רק סדרתיות.

ומה עושים עם מערכות COBOL ו-Legacy?

כאן מתחיל האתגר האמיתי.

בארגונים פיננסיים רבים עדיין קיימות מערכות Legacy ותיקות, כולל מערכות COBOL.

הבעיה אינה בהכרח שהקוד "ישן".

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

לפעמים יש מערכת בת עשרות שנים שבה שינוי קטן בשדה אחד משפיע על:

• מערכת תשלומים.
• מערכת חשבונאית.
• דוחות.
• מערכת אשראי.
• מערכת דיווח.
• Batch לילי.
• מערכת חיצונית.

ולכן בבדיקות Legacy צריך לאמץ גישה שונה.

לא לשאול רק "מה הקוד עושה?"

צריך לשאול:

"איזה Business Rule מסתתר בתוך הקוד?"

לדוגמה, קוד COBOL יכול להכיל תנאי שנראה פשוט:

IF CUSTOMER-TYPE = 'A'
    APPLY-DISCOUNT

אבל אולי Customer Type A קיים רק בגלל חוק עסקי שנכתב לפני 25 שנה.

אם מוחקים את התנאי כי "הוא נראה מיותר", אפשר לשבור תהליך עסקי חשוב.

לכן בדיקות Legacy צריכות להתבסס על שילוב של:

Code + Documentation + Business Rules + Historical Behavior + Production Data Patterns

Golden Master Testing למערכות ישנות

אחת הגישות המעניינות ביותר לבדיקת מערכת Legacy היא ליצור:

Golden Master

כלומר:

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

שומרים את התוצאות.

לאחר שינוי המערכת מריצים בדיוק את אותם נתונים.

ואז משווים:

OLD SYSTEM OUTPUT
        VS
NEW SYSTEM OUTPUT

המטרה אינה בהכרח שהקוד החדש יהיה זהה.

המטרה היא לוודא שההתנהגות העסקית לא השתנתה במקום שבו היא לא אמורה להשתנות.

Regression Testing במערכות פיננסיות חייב להיות חכם

אי אפשר בכל שינוי להריץ ידנית 50,000 Test Cases.

לכן צריך לבנות:

Risk-Based Regression.

לדוגמה:

ככל שהשינוי נוגע יותר בכסף, הרשאות או נתוני לקוח – כך עומק ה־Regression צריך לגדול.

איך AI משנה את בדיקות העומק?

כאן לדעתי נמצא אחד השינויים הגדולים ביותר בעולם ה-QA.

AI לא צריך להחליף את הבודק.

הוא צריך להפוך את הבודק ל־בודק שחושב רחב יותר.

אפשר לתת ל-AI:

• דרישות.
• User Stories.
• API specifications.
• SQL queries.
• Logs.
• קטעי קוד.
• מסמכי מערכת.
• Business Rules.
• תוצאות בדיקות היסטוריות.

ולבקש ממנו לזהות:

"מה יכול להישבר בעקבות השינוי הזה?"

שימוש ראשון ב-AI: יצירת Risk Map

נניח ששינינו מנגנון לחישוב עמלה.

במקום לבקש מ-AI רק:

"צור לי Test Cases"

עדיף לשאול:

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

לאחר מכן אפשר לבקש:

Impact Analysis
↓
Risk Identification
↓
Test Scenarios
↓
Edge Cases
↓
Integration Tests
↓
Regression Tests

זו גישה הרבה יותר חזקה.

AI יכול להיות מצוין גם בניתוח קוד COBOL

כאשר אין תיעוד מספק, אפשר להשתמש ב-AI כדי לבצע:

• הסבר של הקוד.
• זיהוי משתנים.
• זיהוי תנאים.
• זיהוי Business Rules.
• זיהוי תלויות.
• זיהוי נקודות כניסה.
• זיהוי יציאות.
• זיהוי שדות שמשתנים.
• יצירת תרשים זרימה.
• הצעת תרחישי בדיקה.

אבל יש כלל חשוב:

לא מתייחסים לתשובת AI כאמת.

AI יכול לטעות בהבנת קוד Legacy.

לכן:

AI → Hypothesis

ואחר כך:

Tester → Verification

AI יכול למצוא תרחישים שהבודק לא חשב עליהם

נניח שהדרישה אומרת:

"שינוי מגבלת תשלום יומי מ־50,000 ל־100,000 ₪."

בודק יכול לחשוב על:

50,000
100,000
100,001

אבל AI יכול להציע:

• שתי עסקאות במקביל.
• עסקה שמתחילה לפני חצות ומסתיימת אחריה.
• Refund שמשפיע על המגבלה.
• ביטול עסקה.
• Retry.
• מספר כרטיסים לאותו לקוח.
• מספר חשבונות לאותו לקוח.
• שינוי מגבלה באמצע היום.
• שינוי timezone.
• Batch לילי.
• כשל במערכת באמצע ספירת העסקאות.

וזה בדיוק המקום שבו AI יכול להיות מכפיל כוח לבודק.

אבל יש דבר אחד שאסור לעשות עם AI

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

אין להכניס למודל ציבורי:

• מספרי כרטיסים.
• פרטי לקוחות.
• חשבונות בנק.
• סיסמאות.
• Tokens.
• מידע אישי.
• נתוני עסקאות אמיתיים.
• מידע פנימי מסווג.

AI צריך לעבוד עם:

Synthetic Data / Masked Data / Anonymized Data

ובארגון פיננסי חשוב במיוחד להגדיר Governance ברור לשימוש ב-AI.

בדיקות נתונים – לא רק UI

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

לכן צריך לבדוק גם את הנתונים עצמם.

לדוגמה:

UI
↓
API
↓
Message Queue
↓
Database
↓
Batch
↓
Accounting

בודק צריך לדעת לבצע Validation בכל שכבה רלוונטית.

לדוגמה:

UI אומר 1,000 ₪

האם:

API = 1000
DB = 1000
Message = 1000
Accounting = 1000
Report = 1000

?

אם במקום אחד נמצא:

1000

ובמקום אחר:

100000

זה לא UI Bug.

זה יכול להיות באג פיננסי משמעותי.

בדיקות Batch – המקום שבו באגים יכולים להסתתר במשך שעות

מערכות פיננסיות רבות עדיין נשענות על תהליכי Batch.

למשל:

23:00 – קבלת עסקאות
00:00 – עיבוד
01:00 – התאמות
02:00 – חישובים
03:00 – יצירת דוחות
04:00 – העברת מידע

לכן צריך לבדוק:

• Batch מלא.
• Batch חלקי.
• Batch שנכשל.
• Restart.
• Retry.
• Duplicate File.
• Missing File.
• קובץ ריק.
• קובץ פגום.
• סדר קבצים שגוי.
• עיבוד כפול.
• Timeout.
• שינוי תאריך.
• מעבר חודש.
• סוף שנה.

במיוחד:

End of Month ו-End of Year

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

בדיקות זמן – הרבה יותר חשובות ממה שנדמה

צריך לבדוק:

• 23:59:59.
• 00:00:00.
• מעבר יום.
• מעבר חודש.
• מעבר שנה.
• Leap Year.
• Daylight Saving Time.
• Time Zone.
• Business Date מול System Date.

לדוגמה:

עסקה שהתחילה ב־31 בדצמבר בשעה 23:59 והסתיימה ב־1 בינואר.

לאיזה יום היא שייכת?

לאיזה חודש?

לאיזה דוח?

איזה Limit חל עליה?

זו בדיוק שאלה שבודק חייב לשאול.

בדיקות Reconciliation – אחד הנשקים החזקים ביותר של QA פיננסי

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

לדוגמה:

Payment System
        ↓
Banking System
        ↓
Accounting System

בסוף התהליך:

Number of Transactions
Total Amount
Refunds
Fees
Net Amount

צריכים להתאים.

אם:

Payment System = 10,000 transactions
Accounting = 9,998

יש בעיה.

אם:

Payment System = 5,000,000 ₪
Accounting = 4,999,950 ₪

צריך למצוא את הפער.

בדיקות Reconciliation מסוג זה יכולות להיות הרבה יותר אפקטיביות מבדיקת מסכים.

איך הייתי בונה תהליך בדיקות לשינוי פיננסי משמעותי?

אני ממליץ לעבוד בשמונה שלבים:

1. Understand

להבין את הדרישה ואת ה־Business Rule.

2. Map

למפות את כל המערכות המושפעות.

3. Risk

לזהות מה יכול לגרום לנזק כספי או תפעולי.

4. Challenge

לייצר Edge Cases ותרחישי כשל.

5. Test

לבצע Functional, Integration, API, Data ו-End-to-End Testing.

6. Compare

להשוות למערכת הישנה או ל־Golden Master במידת האפשר.

7. Reconcile

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

8. Monitor

לא לסיים את העבודה ברגע שהגרסה עלתה לייצור.

צריך לבדוק Metrics, Logs, Alerts וחריגות.

Checklist לבודק לפני עלייה לייצור

לפני שינוי משמעותי במערכת פיננסית הייתי שואל:

פונקציונלי

• האם Happy Path עובד?
• האם Negative Cases עובדים?
• האם Boundary Cases נבדקו?

פיננסי

• האם הסכומים נכונים?
• האם העמלות נכונות?
• האם Rounding נכון?
• האם היתרות נכונות?

תשלומים

• האם Retry בטוח?
• האם קיימת Idempotency?
• האם חיוב כפול נמנע?

Integration

• האם כל המערכות מקבלות את הנתונים הנכונים?
• מה קורה כאשר מערכת חיצונית לא זמינה?

Legacy

• האם המערכת הישנה נבדקה?
• האם Business Rules נשמרו?
• האם יש Regression?

Data

• האם DB תקין?
• האם Messages תקינים?
• האם Batch תקין?

Concurrency

• מה קורה בשתי פעולות במקביל?

Time

• מה קורה בחצות?
• בסוף חודש?
• בסוף שנה?

Reconciliation

• האם מספר העסקאות תואם?
• האם הסכומים תואמים?

AI

• האם AI שימש ל־Impact Analysis?
• האם הוא הציע תרחישי קצה?
• האם התוצרים שלו אומתו על ידי בודק?

בסופו של דבר, AI לא מחליף את הבודק – הוא מעלה את הרף שלו

אני חושב שהעתיד של QA במערכות פיננסיות לא יהיה רק אוטומציה של Test Cases.

הבודק של העתיד יצטרך להבין הרבה יותר.

הוא יצטרך להבין:

Business + Technology + Data + Finance + Integration + Legacy + AI

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

לעומת זאת, בודק שיודע לשאול:

"מה יקרה אם העסקה תצליח במערכת אחת ותיכשל בשנייה?"

"מה יקרה אם המשתמש ילחץ פעמיים?"

"מה יקרה אם ה־Batch יופעל פעמיים?"

"מה יקרה אם העסקה תעבור את חצות?"

"מה יקרה אם ה־COBOL מחזיק Business Rule שאף אחד כבר לא זוכר?"

"ומה יקרה אם השינוי הקטן הזה משפיע על מערכת אחרת שאפילו לא נמצאת ב־User Story?"

הוא כבר לא רק בודק תוכנה.

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

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

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

קורס לבדיקות תוכנה מדויק

לעבוד מהבית כבודק תוכנה עם FIVERR >> לחץ כאן