דמיינו שהעליתם אתר חדש לעסק. הוא נראה מצוין בטלפון, הטופס מציג ״תודה, פנייתך התקבלה״ והקמפיין כבר מביא מבקרים. אחרי שלושה ימים אתם מגלים שהטופס הציג הודעת הצלחה גם כשהשליחה נכשלה. הלקוחות חיכו לתשובה, ובינתיים העסק שילם כדי להביא אותם לאתר.
זה אחד הסיכונים בבניית אתר עסקי באמצעות AI כשאין בתהליך מפתח שמבין את הקוד ואת המערכת שנבנתה. קל לבדוק מה רואים על המסך. קשה יותר לדעת אם הפעולה שהמסך מבטיח באמת התבצעה.
הטופס נשלח. לאן הגיעה הפנייה?
בבדיקה הראשונה בדרך כלל ממלאים את כל השדות ולוחצים פעם אחת על ״שליחה״. באתר פעיל, לקוחות לוחצים פעמיים, עוברים בין רשתות או משאירים את הדף פתוח וחוזרים אליו מאוחר יותר. גם שירות הדיוור או מערכת ניהול הלקוחות שאליה הטופס מחובר יכולים להפסיק להגיב.
בדיקה טובה עוקבת אחרי הפנייה עד ליעד שלה. האם היא הגיעה לתיבה או למערכת ניהול הלקוחות? האם הגיעה פעם אחת? ומה רואה הלקוח אם השליחה נכשלה? בחנות מקוונת, אותו עיקרון חל על תשלום. בדקו מה נרשם במערכת כשהתשלום מצליח, כשהוא נדחה וכשהלקוח סוגר את החלון באמצע.
עמוד שנראה פרטי יכול לחשוף פרטי לקוחות
נניח שבניתם אזור אישי שבו כל לקוח יכול לראות את ההזמנות שלו. אם האתר מציג את ההזמנה לפי מספר שמופיע בקישור, השרת צריך לבדוק שהלקוח המחובר רשאי לראות אותה. בלי הבדיקה הזאת, שינוי המספר בקישור עלול לחשוף הזמנה של אדם אחר, כולל שם, כתובת ופרטי רכישה. הכשל הזה מוכר באבטחת אתרים ככשל בבקרת גישה. מדריך OWASP לבקרת גישה
בעל העסק יכול לבקש לראות בדיקה פשוטה בסביבת בדיקות. נכנסים עם שני חשבונות לקוח נפרדים ומוודאים שכל אחד יכול לראות רק את ההזמנות שלו. בדיקה כזאת חשובה במיוחד כשהאתר שומר מידע אישי או מחבר בין כמה מערכות.
מה קורה כשצריך לשנות משהו בעוד חודשיים?
נניח שהעסק פותח סניף נוסף ורוצה שכל פנייה תגיע לסניף שהלקוח בחר. שינוי שנראה קטן יכול לדרוש עדכון של הטופס, כללי הניתוב והחיבור למערכת ניהול הלקוחות. אם כל שינוי נעשה באמצעות בקשה נוספת ל־AI, בלי שמישהו מבין איך החלקים מתחברים, תיקון בסניף אחד עלול לפגוע בקליטת הפניות בסניף אחר.
כבר בתחילת הפרויקט כדאי לברר למי יש גישה לקוד ולאחסון, איך בודקים שינוי לפני שהוא מגיע ללקוחות ואיך חוזרים לגרסה שעבדה אם העדכון נכשל. ככל שהעסק תלוי יותר באתר להכנסות או לפניות, כך חשוב יותר לדעת מי מטפל בתקלה כשהיא קורית.
איפה AI כן נותן למפתח יתרון?
מפתח ששולט בשפת הקוד ובמערכת שבה האתר נבנה יכול להשתמש ב־AI כדי להכין אב־טיפוס, לכתוב רכיבים שחוזרים בכמה עמודים ולהציע בדיקות למצבים חריגים. למשל, בחנות חדשה אפשר להציג לבעל העסק שתי גרסאות של תהליך ההזמנה מוקדם, לבחור את המסלול הנוח יותר ורק אז להשקיע בחיבור למלאי ולסליקה.
היתרון הוא שהמפתח יכול לקרוא את ההצעה, להבין מה היא משנה, להתאים אותה לכללי העסק ולבדוק אותה לפני העלייה לאוויר. הוא יכול גם להיעזר ב־AI לכתיבת בדיקות, ואז לבדוק שהן מכסות תרחישים שהעסק באמת פוגש. גם GitHub ממליצה לבדוק ולבחון היטב קוד שנוצר באמצעות Copilot, במיוחד כשהוא משמש לפעולות רגישות לאבטחה. הנחיות GitHub לשימוש בהצעות קוד של Copilot
מה לבקש לראות לפני העלייה לאוויר?
בחרו פעולה אחת שהעסק תלוי בה, כמו קבלת פנייה או השלמת הזמנה, ובקשו לראות אותה מתחילתה ועד סופה. אחר כך בקשו לראות מה קורה כשהפעולה נכשלת. אם האתר כולל חשבונות לקוח, בקשו גם לראות איך נבדקת הגישה למידע. לבסוף, שאלו מי מקבל התראה אם יש תקלה ומי יכול לתקן אותה.
אם אין לכם היכולת לבדוק את הקוד ואת החיבורים של האתר, כדאי שמפתח שמכיר את הטכנולוגיה יעבור עליו לפני שלקוחות משתמשים בו. ואם אתם מתכננים אתר חדש, אפשר להתחיל את השיחה עם שקד פרסום מהפעולות שהאתר צריך לבצע עבור העסק ומהבדיקות שיראו שהוא עושה אותן.
