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