אגדת הבטא ובקרת האיכות

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

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

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

פרופיל אישי של משתמש אחר

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

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

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

אתר ממשלתי: לא מצחיק בעיקר כי אנחנו מימנו אותו

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

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

אתר משרד התיירות: דנמרק לעומת ישראל

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

לונדון לא מחכה לנו ואין אזהרת בטא

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

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

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

בטור הבא:  לא רוצים להתייעל רוצים לפטר

הכותב הינו יועץ וארכיטקט ממשקי משתמש