משתמש לוחץ כפתור צילום מסך של הבאג ושולח זאת לי ללא התקנה של כלום

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

צילום מסך על מחשב דורש ידע בקיצור המקלדת הנכון, המשתנה לפי מערכת ההפעלה. בחלונות זה עשוי להיות Print Screen או Alt פלוס Print Screen עבור החלון הפעיל או מקש Windows פלוס Shift פלוס S לכלי cSnipping. על Mac זה Command Plus Shift Plus 3 או 4 או 5 כל אחד מהם מייצר תוצאות שונות במעט. בטלפון הג'סט כרוך בלחיצה על שני כפתורים פיזיים בו זמנית מה חצי הזמן בטעות נועל את המסך. לאחר צילום המסך, הוא צריך להימצא במערכת הקבצים, להצמד לאימייל או להדביק לטופס תמיכה, ולשלוח. כל אחד מהצעדים האלה הוא נקודה נוספת שבה המשתמש מוותר והחליט שהבאג אינו שווה דיווח. התוצאה היא שמפתחים מקבלים בערך דוח אחד לכל מאה באגים שמשתמשים בפועל נתקלים בהם.

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

מדוע הרחבות של דפדפן לא פתרו את הבעיה הזו

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

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

ספריות צילום מסך בצד הלקוח כמו html2canvas ניסו לפתור את זה מזווית שונה. ספריות JavaScript אלה מעבירות את ה-DOM ליסוד ג'יוקנבס ויוצרות למעשה צילום מסך ללא כל התערבות בצד השרת. הם עובדים סביר למדי טוב עבור פריסות פשוטות אך נופלות במהירות עם CSS מורכב, iframes משובצים, תמונות cross-origin, אלמנטים בד ופונטים מותאמים אישית. התמונה המתקבלת בדרך כלל לא נראית כמו מה המשתמש בעצם רואה, המביא את המטרה לחלוטין. דוח באגים המכיל צילום מסך שלא תואם את הדף בפועל גרוע מ-no צילום מסך בכלל, כי הוא שולח את המפתח ברדיפה בעיה ויזואלית שלא קיימת בזמן שהבעיה האמיתית נשארת מוסתרת.

צילומי מסך בצד השרת וכיצד הם צילום מה המשתמש רואה

הגישה מאחורי screenshots.yeb.to לוקחת נתיב שונה לחלוטין. במקום לנסות לשחזור את הדף בצד הלקוח, השרת מקבל את ה-URL ומעביר אותו באמצעות מנוע דפדפן אמיתי הפועל בסביבה מכווננת. צילום המסך משתנה בידי מופע Chromium אמיתי המטען את הדף, מעביר את JavaScript, מחיל CSS, מעביר פונטים, ותופס את התוצאה כתמונה דקיקה לפיקסל. זה אומר שצילום המסך נראה בדיוק כמו מה דפדפן אמיתי מציג, כי זה מה דפדפן אמיתי מציג.

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

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

הטבעה של הכפתור ללא שינוי היישום

האינטגרציה יועדה בכוונה לעיני. קטע JavaScript קטן טוען את רכיב הכפתור, אשר ניתן לעיצוב כדי להתאים את מערכת הדיזיין של יישום המארח. הכפתור צף בפינה של הדף, גלוי אך לא מובהק. בעת הלחיצה, הוא פותח שכבת משקל קל שבה משתמש יכול להקליד תיאור קצר ובחירה לעדכן את האזור של הדף בו התרחשה הבעיה. מאחורי הקלעים, הקטע שולח את כתובת ה-URL הנוכחית לצילום מסך API, המנתק את הדף וממחזור את כתובת ה-URL של התמונה. הדוח המכיל את צילום המסך, התיאור, כתובת ה-URL וחומרה בסיסית מטא-נתונים מפתח המדינה לכל יעד המפתח קבע: כתובת דואר אלקטרוני, webhook Slack, כלי ניהול פרויקטים, או נקודת קצה מותאמת אישית.

כל האינטגרציה לא דורשת שינויים לחלקו האחורי של היישום. אין SDK להתקין, אין middleware לתצורה, אין סכמת מסד נתונים לשינוי. הקטע פועל באופן עצמאי, תקשורת רק עם צילום מסך API והיעד דוח מוגדר. זה אומר שזה יכול להיות הפיל לתוך בלוג WordPress, יישום אחד עמוד React, אתר HTML סטטי, או יישום PHP מורשה עם קלות שווה. הזמן מהחלטה להוסיף דוח באגים לשהוא חי על האתר נמדד בדקות, לא ספרינטים.

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

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

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

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

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