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