זה זמן רב שנושא בדיקות השמישות מככב בבלוגים שונים של ממשק משתמש, ומאחר שהמערכת העיקרית שלנו סובלת מבעיות שמישות כאלה ואחרות, הרי שהנושא של בדיקות שמישות מאד מצא חן בעיני, ומאד רציתי להתנסות בו. עם זאת, גם לאחר שקראתי רבות על בדיקות שמישות, לא הצלחתי לעשות סדר בבלגן: מצד אחד יש לבצע בדיקות שבהן המפתחים יושבים ליד המשתמשים, אבל מצד שני יש בדיקות שבהן מספיק לקבל תוצאות אונליין; מצד שלישי יש להציב להם משימות לביצוע, מצד רביעי יש ממליצים לאפשר שיטוט חופשי; לפעמים צריך להתערב בבדיקה ולפעמים לצפות בשקט. מה? מי? מתי? כמה? למה?
כמו שקרה לי לא פעם בעבר, כאשר נושא מסויים הופך להיות רלוונטי בעבודה איכשהו גם חוצה את דרכי מאמר בנושא. תשועת ה’ כהרף עין… אז הפעם היה זה מאמר שכתב יזם של אתר מכירות בלונדון, והוא כתב על סדר הבדיקות שנעשו אצלם. מאחר שהסדר הזה נשמע לי הגיוני, אני רוצה לחלוק אותו עמכם.
היזם הזה מחלק את הבדיקות ל-4 שלבים. בכל שלב הוא כותב מהי מטרת הבדיקה, איך צריכה להתבצע הבדיקה, כמה אנשים צריכים להשתתף בה (אני רואה בזה המלצה בלבד). אני כמובן לא אתרגם את המאמר במלואו אלא רק את ראשי הפרקים.
השלב הראשון הוא בדיקה שבה המפתח יושב ליד המשתמש. הוא מציע לקיים את הבדיקה כשהאתר מתפקד ב-80%, ואפשר אפילו קצת פחות. המטרה של הבדיקה הזו היא למצוא את הנקודות הבעייתיות, אלה שמבלבלות את המשתמש.
השלב השני הוא בדיקה של ביצוע משימות. השלב הזה אינו מחייב צפיה במשתמשים, אפשר להסתפק במשלוח המשימות למשתמשים, וקבלת התוצאות.
השלב השלישי הוא בדיקת מטרות – כאן רוצים לראות איך המערכת מתפקדת מקצה לקצה.
השלב האחרון הוא בדיקות בטא.
המחבר מסיים בדבר שחשוב לו להדגיש: אנו מבקשים מהמשתתפים לומר לנו איפה המערכת לא מתפקדת נכון – לא איזו מערכת נפלאה בנינו… חשוב לא לקחת את הביקורת אישית, אלא להשתמש בה כדי לחזק את המערכת.
כמו שקרה לי לא פעם בעבר, כאשר נושא מסויים הופך להיות רלוונטי בעבודה איכשהו גם חוצה את דרכי מאמר בנושא. תשועת ה’ כהרף עין… אז הפעם היה זה מאמר שכתב יזם של אתר מכירות בלונדון, והוא כתב על סדר הבדיקות שנעשו אצלם. מאחר שהסדר הזה נשמע לי הגיוני, אני רוצה לחלוק אותו עמכם.
היזם הזה מחלק את הבדיקות ל-4 שלבים. בכל שלב הוא כותב מהי מטרת הבדיקה, איך צריכה להתבצע הבדיקה, כמה אנשים צריכים להשתתף בה (אני רואה בזה המלצה בלבד). אני כמובן לא אתרגם את המאמר במלואו אלא רק את ראשי הפרקים.
השלב הראשון הוא בדיקה שבה המפתח יושב ליד המשתמש. הוא מציע לקיים את הבדיקה כשהאתר מתפקד ב-80%, ואפשר אפילו קצת פחות. המטרה של הבדיקה הזו היא למצוא את הנקודות הבעייתיות, אלה שמבלבלות את המשתמש.
השלב השני הוא בדיקה של ביצוע משימות. השלב הזה אינו מחייב צפיה במשתמשים, אפשר להסתפק במשלוח המשימות למשתמשים, וקבלת התוצאות.
השלב השלישי הוא בדיקת מטרות – כאן רוצים לראות איך המערכת מתפקדת מקצה לקצה.
השלב האחרון הוא בדיקות בטא.
המחבר מסיים בדבר שחשוב לו להדגיש: אנו מבקשים מהמשתתפים לומר לנו איפה המערכת לא מתפקדת נכון – לא איזו מערכת נפלאה בנינו… חשוב לא לקחת את הביקורת אישית, אלא להשתמש בה כדי לחזק את המערכת.