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

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

פיתוח מונחה רכיבים

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

אנו נהנים מיתרונות רבים מעבודה מונחית רכיבים:

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

• עבודה עם רכיבים מאיצה לעתים קרובות את תהליך הפיתוח על ידי מתן פתרונות Plug and Play.

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

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

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

הסיפור של הממשק שלנו בספר הסיפורים

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

רכיב כפתור בספר סיפורים

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

רכיב טופס התחברות ב-Storybook

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

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

אוננט בספר סיפורים

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

בדיקת נגישות ב-Storybook

בדיקת רגרסיה חזותית באמצעות Percy

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

בעזרת Storybook אני יכולה לבנות ולעצב רכיבים בנפרד, ויש לי תמיד תמונה כוללת של התרחישים השונים שתכננתי. בעזרת Percy, אני תמיד יודעת מה ההשפעה של השינויים שאני מבצעת.
Anouk
מפתחת Front-End ומעצבת UX

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

רגרסיות שנחשפו אצל פרסי

ההבדלים בין הגרסה הישנה לחדשה מסומנים באדום

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

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

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