מקרי בדיקה לטופס גיוס: איפה מסתתרים הפגמים

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

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

למה טפסים רב-שלביים מסתירים כל כך הרבה פגמים?

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

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

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

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

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

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

אילו ענפי מועמדים ראויים למקרה בדיקה נפרד?

אלה שמייצרים מסלול שונה בפועל, ולא אלה שנשמעים מעניינים בכלל.

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

איך שדות חובה משתנים לפי התשובות שניתנו?

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

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

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

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

מה צריך לקרות בשליחה חוזרת?

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

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

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

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

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

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

למפתחים: בניית מצב הטופס

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

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

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

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

צעדים הבאים

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

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