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

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

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

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

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

טריק שתי הרשימות

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

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

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

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

כשאתם באמת בודקים, עברו על רשימה א’ קודם כדי לאשר שהיסודות עובדים. ואז בלו את רוב הזמן שלכם על רשימה ב’. רשימה ב’ היא איפה שהערך נמצא. רשימה ב’ היא גם איפה שאתם מגלים מה אתם באמת רוצים שהאפליקציה תעשה כשהדברים משתבשים, מה שלעיתים קרובות מאלץ שיחת הבהרה עם הכלי (“כשהטופס מלא חצי, האם הוא צריך להזהיר או לשמור אוטומטית?”).

שלושה דברים לשבור בכוונה

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

קלטים ריקים ומוזרים. שלחו את הטופס בלי שום דבר ממולא. שלחו אותו עם שדה אחד ממולא. שלחו שם שאורכו 500 תווים. שלחו שם עם אימוג’י. הדביקו URL לשדה שמצפה לשם. נסו את שדה המייל עם “test”, עם “test@”, עם “test@example”, עם הכתובת “a@b.co” — האם הוא מקבל מיילים קצרים לגיטימיים? כלים לבניית אפליקציות עם בינה מלאכותית לעיתים קרובות מוסיפים ולידציה, אבל הוולידציה יכולה להיות שגויה בשני הכיוונים — מחמירה מדי (דוחה משתמשים אמיתיים) או רופפת מדי (מקבלת זבל).

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

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

איך נראה “מספיק טוב”

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

הנה היררכיה גסה שאתם יכולים לשאול.

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

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

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

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

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

הכלי שלכם יכול לעזור בבדיקות, אבל אתם צריכים להיות ספציפיים לגבי מה שאתם רוצים. “תוסיף בדיקות” היא הנחיה גרועה. היא תייצר קוד שנראה כמו בדיקות וכנראה עובר, בלי באמת לבדוק שום דבר שאכפת לכם ממנו. רוב הבדיקות שנוצרות אוטומטית מאשרות ש-1+1 עדיין שווה 2.

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

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

בדיקות הן קריאה, לא רק לחיצה

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

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

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

הגרסה הפשוטה

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

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