משחקי תפקידים - לא מילה גסה

משחקי תפקידים - לא מילה גסה

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

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

במה תורמת לנו שיטת העבודה הנ"ל לתכנון וביצוע הבדיקות?
 Testing Personas - מעניקות לנו את האפשרות "לחוות" את המערכת דרך עיניהם ומציאות עולמם, כשכל אחת מהן מייצגת אחוז מסויים מכלל אוכלוסיית המשתמשים של המוצר. בדרך זו נוכל לנסות לחזות דפוסי שימוש, בעיות פוטנציאליות עבור כל אחת מהן, ולביים תרחישים של מקרי קצה. לכל מוצר\מודול מתוך מוצר, ניתן ורצוי ליצור דמויות יעודיות שיתאימו להתפלגות קהל היעד.
קצת פילוסופיה: כשאני חושב על "לתקוף" מערכת, אני מנצל את מיטב הניסיון, היצירתיות והמחשבה הביקורתית שלי (בדגש על שלי) על מנת לראות היכן היא יכולה להכשל, לקרוס, לא לתפקד כמצופה או להתברר כנחותה לעומת מתחריה. כאשר אני מאמץ לעצמי Persona לביצוע אותו Flow - דרך מציאות עולמה אני מנסה לשחזר את דפוסי ההתנהגות וסדר היום שלה - אני איפשהו זוכה לעוד "חווית בדיקה" שיכולה להשלים את המערך הכולל ולתרום רעיונות לתרחישים שאולי לא הייתי חושב עליהם כ"דניאל הבודק".

אז, איך זה עובד? 

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

אילו מאפיינים עלינו לקבוע עבור הדמות?
* שם - דמויות דורשות שם קליט, שיקל עלינו להתחבר לדמות ולביים עבורה התרחשויות. היא כבר לא בגדר מושג אפרורי או דימיון מעורפל - יש לה שם, וכעת נתחיל להכיר אותה ואת תכונותיה.
* תמונה - אמנם זו לא חובה, אבל מבחינה תאורתית, כמה ש"נחיה" יותר את ה Persona בתודעתנו - כך נוכל יותר להתחבר אליה באופן אישי, לחשוב על דברים אותם היא עלולה לעשות ובעיות בהם היא צפויה להתקל.
* תיאור קצר - על מנת לא להעמיס על הבודק, (רצוי לתעד לצורך בדיקות עתידיות של חברי צוות נוספים) ועם זאת להקנות לדמות תכונות המייחדות אותה, נוסיף לה תיאור קצר. ניתן לרשום גיל, מצב משפחתי, תכונות אופי בולטות, מטרת השימוש במוצר שלנו, ואף סלוגן קליט שיתאר במשפט את ה Persona המסתורית.
* יצוג לקהל ייעד ו - Priority לתכנון הבדיקות - איזה פלח משתמשים (User Segments) מייצגת הדמות? מהו ה Priority בהתאם לאחוז הקהל המיוצג?
אני מניח שזה המקום לציין שמבחינת משוואת זמן עלות תועלת רצוי לכוון את התרחישים בעיקר למקומות בעלי החשיבות העסקית הגדולה ביותר. כלומר להתרכז בלוגיקות העיקריות ולוא דווקא בדברים שוליים. (אסייג את עצמי ואומר שבמידה ויש זמן ניתן להפיג תועלת משיטה זו בשלל היבטי הבדיקות - לרבות בדיקות אפיוניות - Review).

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

אז, איזו דמות נוכל ליצור על מנת לדגום סגמנט?

 כעת, בעזרת דנה - ננסה ליצור תרחיש (User Journey) המבוסס על מציאות עולמה:

• דנה מגיעה בבוקר לעבודה לאחר שפיזרה את 2 ילדיה בגנים.
• פותחת את המערכת וממתינה שהיא תעלה.
• השעה 9:00 בבוקר והשיחות מתחילות להגיע.
• נכנסת שיחה מקניין משנה - הוא מבקש להזמין מספר פריטים רב מאותה קבוצת מוצר עקב הזמנה מרוכזת.
• מיד לאחר שדנה מנתקת מתקשר מזמין נוסף ומבקש לבצע הזמנה של אותם מוצרים שהוא מזמין מדי שבוע.
• השעה 11:00 דנה מקבלת שיחת טלפון של הזמנה גדלה שעליה להקליד במחשב הכוללת מוצרים רבים ממשפחות מוצר שונות.
• תוך כדי השיחה הבוס שלה מתקשר ומבקש בדחיפות להזין הזמנה קצרה עבור לקוח סופר חשוב ממש בזה הרגע.
• השעה 12:00 - תוך כדי שדנה מזינה הזמנה, מגיעה חברתה למשרד וקוראת לה לאכול איתה ארוחת צהריים. דנה נועלת את המחשב בלי לסיים את ההזמנה ויוצאת.
• השעה 13:00 - המנהל של דנה מבקש ממנה להביא לו בדחיפות קלסר של מסמכים, תוך כדי שדנה מבצעת הזמנה לגוף בטחוני חסוי. 
• היא קמה מהכיסא מבלי לנעול את המחשב, במחשבה שהיא תספיק למצוא את הקלסר לפני שמישהו יכנס למשרד ועלול לראות את המחשב. 
• בעוד דנה איננה במקומה, הבן של אחת הבנות במשרד לחץ בשוגג על כפתור השליחה בהזמנה.
• השעה 14:30 - תוך כדי הזנת הזמנה לספק, דנה מקבלת שיחת טלפון מהגן שהילד לא מרגיש טוב והיא חייבת לצאת מהעבודה בזריזות. היא לוחצת על שליחה ורצה מהמשרד מבלי לשים לב ששליחת ההזמנה נכשלה.
• בערב, המנהל מקבל טלפון כי לא התקבלה הזמנה (זו שנכשלה) ומחליט להכנס למערכת ולבדוק האם הוא יצליח לשלוח מחדש.

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

• זמני תגובה.
• שימושיות.
• ריבוי Tasks במקביל, תמיכה בריבוי טאבים.
• נוחות ביצוע הזמנות מרוכזות (אפשרויות לבחירות מרובות, בחירת תיקית מוצר שלמה).
• ניווט קל בין מוצרים ולקוחות שונים.
• מנגנוני בטיחות fool proof
• אבטחת מידע
• האם קיים מנגנון Auto Logout?
• האם מתבצעת שמירת נתונים בהזמנה הקיימת - במקרה שבוצע  Logout אוטומטי?
• האם מתבצעת פעולה לשמירת הזמנות במקרה של כשלון בשליחה?
• שליחה חוזרת ושליחה חוזרת אוטומטית.
• האם ישנה אפשרות לשמירת הזמנה קבועה לספק?\הזמנה חוזרת?
• האם המנהל בעל ההרשאה המתאימה יכול לצפות בהזמנות אותם ביצעה העובדת שלו? אם כן, האם יוכל לבצע פעולות? 

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

נקודות (על קצה המזלג) שכדאי לקחת בחשבון בתכנון דמויות ותרחישים:

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

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