4 סיבות מדוע משתמשי קצה צריכים להשתתף בבדיקות לפני UAT

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

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

1. משתמשי קצה מבינים בדיוק מה המערכת צריכה לעשות (עבורם).

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

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

2. סביר יותר לקבלה של משתמשי קצה אם הם מעורבים בשלבי בדיקה קודמים.

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

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

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

אתה לא יכול לשפר את כישורי התכנות שלך כאשר לאף אחד לא אכפת מאיכות התוכנה.

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

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

ואנחנו רואים רק את קצה הקרחון.

הרבה יותר קל למלא מחדש תפקיד מבצעי לעומת תפקידו של בודק UAT שכן האחרון מחייב מישהו עם ניסיון מאוד ספציפי, ולאחור בדיעבד, לאמת מוצר שפותח במיוחד לשימושם. הצצה מהירה בכל אתר עבודה קנדי ​​גדול מציינת כי המשכורת הממוצעת לבוחן QA נעה בין 55,000 ל 80,000 $. מספרים אלה יכולים בקלות להרקיע שחקים בחברה שמקורה במיקור חוץ למבחני הבוחן שלה, ששיעוריה יכולים להגיע עד 100 דולר לשעה בעבודה על פרויקט בעל פרופיל גבוה. השכר הממוצע לתפקיד אדמיניסטרטיבי, כמו רכז ניהולי קליני למשל, נע בין 35,000 $ ל- 45,000 $.

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

4. משתמשי הקצה מציעים נקודת מבט רחבה יותר.

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

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

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

סיכום

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