תוֹכֶן
- הדגמה ותמות!
- צעד אל נעלי המשתמשים
- היסטוריה קצרה של UAT
- UAT אומר לך עד כמה השימוש במערכת
- מי יכול לבצע UAT?
- אין באגים, אין מתח - המדריך השלב אחר צעד שלך ליצירת תוכנה לשינוי חיים מבלי להרוס את חייך
- זרימת הצלחה וכישלון
- יתרונות UAT
מקור: Lightcome / iStockphoto
להסיר:
ברגע שתוכנה עוברת בדיקות יחידה, אינטגרציה ובדיקת מערכות, הצורך בבדיקת קבלה עשוי להראות מיותר. מדוע עדיין בדיקת קבלת משתמשים (UAT) חשובה? כאן, למד על היתרונות של UAT ומדוע זה ייחודי.
הדגמה ותמות!
האם העברת אי פעם מצגת או הדרכה של לקוח, ומשהו פורץ באמצע הדרך? או, האם אי פעם נתת למישהו סט הוראות והבנת שהחמצת משהו, או שזה לא ממש עבד כמו שקיווית? בכל אחד מהמקרים האלה אתה מאמצ את נקודת המבט של משתמש הקצה ועובד עם התוכנה באותה פרסונה. רוב הסיכויים שעשית משהו שונה כיוון שאתה חושב כמשתמש, ולא כמפתח.
צעד אל נעלי המשתמשים
הזווית הייחודית של בדיקת קבלת משתמשים (UAT) היא לבחון תוכנה כמשתמש קצה. תוכנה בנויה כדי לספק למשתמשים תוצאות מוחשיות. לדוגמה, אתרי מסחר אלקטרוני מאפשרים ללקוחות לרכוש מוצרים. כאשר לקוח מבצע הזמנה, תוכנת אתרי המסחר האלקטרוני מודיעה למנהל החנות, כך שניתן יהיה למשוך את הפריט שנבחר ולארוז למשלוח. יתכנו סוגים שונים של משתמשי תוכנה, ולכן שלב בדיקה זה מאפשר לצוות הפיתוח לאמת שמשתמשי הקצה משיגים תוצאות תוכנה צפויות.
היסטוריה קצרה של UAT
לפני כניסתו של האינטרנט, רוב התוכנות נפרסו עבור קהל משתמשים ידוע. אם חברה פיתחה תוכנה עבור לקוח, למנהל שהוקצה הייתה הסמכות לאמת שהתוכנה עומדת בתנאי ההתקשרות. זה נועד לייצג נקודה בה התוכנה "מתאימה למטרה", שהושגה על ידי בחירת נציגי משתמשי קצה לביצוע בדיקות ולספק דוח עם תוצאות. מכיוון שהמשתמשים היו קבוצה ידועה וסגורה, ניתן היה לאמן כל אחד בשימוש בתוכנה, בדרך כלל באמצעות שלבי בדיקה מפורטות מאוד. המוטו של היום היה שיותר פרטים היו טובים יותר.
ככל שפותחה יותר ויותר תוכנה עבור לקוחות באינטרנט, קהל משתמשי הקצה הפך להיות פתוח יותר. כבר לא ניתן היה לזהות ולהכשיר את כל משתמשי הקצה הסבירים, ולכן תכנון תוכנה היה צריך לכלול דגש הרבה יותר גדול על השימושיות והיה צריך להיות מובן בקלות - אפילו עם מידע מינימלי המסופק. לכן, UAT נאלץ להשתנות כדי לעמוד בדרישות הללו.
UAT אומר לך עד כמה השימוש במערכת
לכן, לא רק UAT מגלה לנו את מידת הפונקציונליות של פיסת תוכנה, אלא גם אומר לנו עד כמה זה שמיש. רוב ה- UAT מבוצע בצורה הטובה ביותר על ידי אנשים שמבינים את משתמש הקצה הממוקד אשר יחווה את התוכנה עם מעט ידע מוקדם ויכול לתת אינדיקציה אמיתית על נוחות השימוש בתוכנות ומה צריך לשפר.
מי יכול לבצע UAT?
כאשר מפתחים בודקים תוכנה, הם זוכרים פרטים על אופן הכתיבה של מערכת. ידע זה יכול להשפיע על הבדיקה, ומפתחים עשויים לנקוט בצעדים שונים מאשר משתמשי קצה, כגון ביצוע צעדים במהירות רבה יותר או ביטול פרטים נאים שמשתמשי קצה עשויים למצוא בהם מבלבל. לפיכך, מפתחים אינם המועמדים הטובים ביותר ל- UAT. אז מי כן?
ארגונים רבים מעסיקים צוותי בדיקה ספציפיים שאינם מעורבים בתכנון ופיתוח טכני. ארגונים קטנים יותר מקצים בדיקות לצוות שאינו פיתוח, כמו אלו שממלאים תפקידים אדמיניסטרטיביים, או משתמשים בשירותיה של חברה חיצונית. ארגונים מסוימים משתמשים במה שמכונה "בדיקת מסדרון", שם הם ממש בחרו באנשי צוות שאינם מועסקים באופן פעיל בפרויקט ומבקשים מהם לנסות את המערכת מנקודת המבט של משתמשי הקצה. דוגמא לכך היא הזמנת מוצר באופן מקוון.
לאחר בדיקות פנימיות, יכולים להתרחש שלבי בדיקות טייס או בטא, לפיהם התוכנה זמינה לקבוצות קטנות של משתמשים "אמיתיים" המוזמנים להשתמש במוצר בחינם או בהנחה משמעותית, בתמורה למשוב מפורט על השימוש.
אין באגים, אין מתח - המדריך השלב אחר צעד שלך ליצירת תוכנה לשינוי חיים מבלי להרוס את חייך
אתה לא יכול לשפר את כישורי התכנות שלך כאשר לאף אחד לא אכפת מאיכות התוכנה.
שלבי UAT מתקדמים עם קהלים מגוונים מגדילים את האמון בשימושי התוכנה. בשילוב שלבים של התפתחות איטרטיבית, ניתן לבצע מחזורי UAT מרובים לבדיקת תכונות חדשות במהלך מסירתם, תוך אימות הפונקציות הקודמות.
בודקי UAT טובים סקרנים לראות מה קורה אם הם עולים בדרכים שונות למטרה מסוימת. אחרי הכל, כולם ניגשים לשימוש בתוכנה בדרכים שונות, כך שאם קבוצה קטנה של אנשים יכולים לכסות אפשרויות רבות, האמון של התוכנה במצב הפעלה גבוה יותר.
זרימת הצלחה וכישלון
על תהליכי UAT לוודא כי כל סוג של משתמש בתוכנה משיג את התוצאות המוחשיות הנדרשות הן לזרמי ההצלחה והן לכישלונות הכישלון.
בזרימת הצלחה, משתמש קצה מסתלק עם תוצאה צפויה, כגון ביצוע הזמנת מוצר. בזרימת כישלון, התוכנה תומכת במשתמש הקצה באמצעות תרחיש שגיאה כלשהו, למשל כאשר לקוח מספק מידע על כרטיס אשראי לא חוקי.
כדי לאמת פונקציונליות, יש לספק מידע מסוים לבודקים. אחרת, הם לא יודעים מה התוכנה אמורה לעשות. אבל כדי לבדוק את השימושיות, זה חייב להיות מינימלי - רק על בסיס משימה או דרישות, כגון קנייה של "x" (מוצר) ותשלום "y" (באמצעות פרטי כרטיס אשראי). יש להעמיד את הבוחנים על הבוחנים כדי לרשום תצפיות, הצלחות וכישלונות.
יתרונות UAT
היתרון העיקרי של UAT טוב הוא שהוא שומר על עלויות תחזוקה שוטפות נמוכות ככל האפשר. זה זול יותר לתקן בעיות פונקציונליות ושימושיות בשלב מוקדם. הרבה יותר קשה לתקן באג כשיש קוד נוסף לבדיקת רגרסיה או אם היזם המקורי אינו זמין.
UAT המתבצעת בשלבים מרובים ועם סוגים שונים של קהלי מבחן מספקת הזדמנויות אופטימליות לזיהוי ותיקון של תכונות / בעיות שבירות שבורות בשלבים המוקדמים של הבדיקה. שמירה על יעדי UAT ברמת המשימה והדרישה מאפשרת לבוחנים להתבונן ולהבחין בהרבה יותר ואף לנסות צעדים מחוץ למפתחים שסופקו.
ניתן להזין משוב ממחזורי UAT לאיטרציות עוקבות של פיתוח, להגדיל את חוסן התוכנות ואת השימושיות שלה. מתוזמן היטב, אפילו שלבי בדיקות בטא יכולים להשלים פעילויות שיווק ומכירות על ידי מתן הפניות ומשוב למחקר מקרה.