איך לבדוק מערכות POS בלי חומרה אמיתית

מה אפשר לבדוק בלי חומרה

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

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

להתחיל מתהליך הסורק

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

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

לבנות מטריצת בדיקה קטנה אבל מציאותית

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

בדרך כלל אני רוצה לפחות:

• מוצר רגיל אחד במלאי
• ברקוד לא מוכר אחד
• פריט אחד עם אפסים מובילים
• פריט מוגבל או עם הגבלת גיל
• מוצר אחד עם מבצע או כלל תמחור

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

לדמות התנהגות מפעיל, לא רק התנהגות מערכת

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

נסו תרחישים כאלה:

1. לסרוק את אותו פריט פעמיים במהירות
2. לסרוק בזמן שחלון מודאלי פתוח
3. להסיר פריט ולסרוק אותו שוב
4. להפעיל עקיפת מנהל ולסרוק שוב
5. לאבד מיקוד בכוונה ולוודא שהממשק מתאושש

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

להשתמש בשכבות בכוונה

לבדיקות POS אני אוהב שלוש שכבות:

• פיתוח מקומי עם נתונים זרועים ואמולטור ברקוד
• staging עם לוגיקת מחיר, מס ומלאי אמיתית
• אימות חומרה על מסוף אמיתי לפני שחרור

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

לדעת מה עדיין דורש חומרה אמיתית

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

• צימוד סורק והתנהגות מנהל התקן
• פלט מדפסת קבלות וטיפול בנייר
• תקשורת מסוף תשלום
• הגבלות רכזת USB וקיוסק
• אילוצי רשת ומסוף ייחודיים לחנות

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

איפה צוותים בדרך כלל טועים

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

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

דוגמה מעשית

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

• לדמות קלט סורק ברקוד לשדה החיפוש
• לוודא שהפריט נוסף נכון
• לוודא שמבצעים וכללי מחיר חלים
• לאשר שהסריקה הבאה נוחתת באותו שדה

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

בדיקת מציאות קצרה

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