רוב בודקי התוכנה מכירים היטב את המושג "בדיקות גבול" (Boundary Value Analysis). זה אחד השיעורים הראשונים בקורס QA: אם שדה טקסט אמור לקבל עד 20 תווים, אנחנו נבדוק מה קורה ב-19, ב-20, ב-21, ואולי נשתולל קצת עם 100 תווים כדי לראות מה נשבר. זה בסיסי, זה הגיוני וזה עובד.
אבל כאן מגיעה נקודת התורפה האמיתית שנתקלים בה שוב ושוב בפרויקטים: מה קורה כשהאפיון שותק?
יותר מדי פעמים, בודקים ידניים נופלים במלכודת ה"אין דרישה". אם ב-Acceptance Criteria (קריטריוני הקבלה) של המשימה לא נכתב במפורש מהו גבול התווים או מה נפח הקובץ המותר – הם פשוט לא בודקים את הגבולות האלו. מדובר בהנחת עבודה מסוכנת.
תפקידו של הבודק הידני הוא לא רק "לסמן וי" על מה שכתב מנהל המוצר, אלא לחשוב על מה שהוא שכח לכתוב. חוסר היכרות עם המגבלות של המערכת שלכם הוא פתח לחוויית משתמש גרועה במקרה הטוב, ולפרצת אבטחה חמורה במקרה הרע.
כדי שלא תפספסו את הגבולות הבאים, הנה שלושה סוגי מגבלות שאתם חייבים לחקור, לאתגר ולבדוק בכל אפליקציה – גם (ובמיוחד) כשהאפיון לא אומר לכם לעשות זאת.
1. מגבלות גודל ונפח (Size Limits)
בכל פעם שאתם פוגשים שדה קלט (Input Field) או רכיב העלאת קבצים, תהפכו לבלשים. אל תניחו שהמפתח חסם את השדה בצד הלקוח או השרת.
- בשדות מספריים: מה הערך המקסימלי שהשדה מסוגל לקלוט? מה המינימלי? האם הוא מקבל אפס? האם הוא מאפשר להזין מספרים שליליים (למשל, האם אפשר להזמין מינוס 3 כרטיסים להופעה)?
- בשדות טקסט: מה קורה כשמזינים תו בודד? ומה קורה כשמדביקים מגילה של 5,000 תווים?
- בהעלאת קבצים: מהו נפח הקובץ המקסימלי שהמערכת מסוגלת להכיל? 5MB? 50MB? גיגה?
למה זה קריטי עבורכם?
- חוויית משתמש (UX): תארו לעצמכם משתמש עם שם משפחה ארוך במיוחד (או שם המורכב משני שמות) שמנסה להירשם לשירות שלכם. המערכת מאחורי הקלעים מוגבלת ל-20 תווים, אך השדה פתוח. המשתמש לוחץ "שמור", הטופס נכשל, אך הוא לא מקבל שום הודעת שגיאה שמסבירה למה. התוצאה? משתמש מתוסכל שנוטש את האפליקציה.
- אבטחת מידע (Buffer Overflow): שדה טקסט ללא הגבלת נפח הוא הזמנה פתוחה להאקרים. משתמש זדוני יכול להציף את השדה באלפי או מיליוני תווים במטרה להעמיס על השרת, לייצר שגיאת מערכת פנימית (Server Error) ולחלץ דרכה מידע רגיש על בסיס הנתונים (DB).
2. מגבלות סוג ופורמט (Type Limits)
רכיבי העלאת קבצים (File Upload) הם אחד האזורים הרגישים ביותר בכל מערכת. האפיון אומר שניתן להעלות רק תמונות? מצוין. עכשיו תורכם לבדוק מה קורה בפועל.
- הודעות שגיאה: ודאו שמשתמש שמנסה להעלות קובץ PDF במקום תמונה מקבל חיווי ברור, נעים ומדויק על כך שהפורמט אינו נתמך.
- בדיקת תקינות הפורמטים המותרים: אם המערכת מצהירה שהיא תומכת בקבצי
.png,.jpgו-.webp– בדקו את כולם! אל תניחו שאם פורמט אחד עובד, השאר יעבדו אוטומטית. - אל תאמינו לסיומת הקובץ (Extension): זוהי נקודת תורפה קלאסית. האקר מתוחכם יכול לקחת קובץ הרצה זדוני (
.exe) ופשוט לשנות את השם שלו באופן ידני ל-image.jpg. אם המערכת שלכם בודקת רק את ה-Extension (הסיומת של השם) ולא את ה-Content-Type האמיתי של הקובץ, הקוד הזדוני הזה יעלה לשרת שלכם – ומשם הדרך לפריצה קצרה. תשאלו את צוות הפיתוח: "איך אנחנו ממתקפים את סוג הקובץ האמיתי?"
3. מגבלות ביצועים (Performance Limits)
נכון, בדיקות עומסים וביצועים מורכבות נעשות לרוב באמצעות כלי אוטומציה וסימולטורים. אבל כבודקים ידניים, אתם חייבים להבין את גבולות הסיבולת של האפליקציה שלכם ולדעת איך היא מתנהגת כשהיא "מתעייפת".
הציפו את השאלות האלו מול צוות הפיתוח ומנהל המוצר:
- כמה משתמשים המערכת אמורה להחזיק בו-זמנית לפי התוכנית העסקית?
- מה קורה למשתמש הקצה כשיש עומס נקודתי (למשל, בשעת שיא של רכישת כרטיסים או מבצע בלאק פריידי)?
כאשר משאבי המערכת מגיעים לקצה והתגובות מתעכבות, מה המשתמש יראה? האם הוא יקבל הודעה בנוסח "אנו חווים עומס, אנא נסה שנית בעוד דקה"? האם המסך פשוט יקפא? או שהוא ייאלץ לבהות בגלגל טעינה (Spinner) אינסופי במשך דקות ארוכות בלי להבין אם הפעולה שלו הצליחה? ההבדל בין התרסקות שקטה לבין ניהול נכון של חוויית המשתמש בזמן עומס הוא קריטי.
סיכום: הערך המוסף של הבודק האנושי
הכוח הגדול ביותר של בודקי תוכנה ידניים הוא הסקרנות והיכולת לחשוב על מה שלא נאמר. אוטומציה תבדוק בדיוק את מה שתוכנתה לבדוק, קריטריוני הקבלה יגדירו רק את מה שמנהל המוצר לקח בחשבון – אבל אתם נמצאים שם בשביל התמונה המלאה.
אל תתנו לאפינסקי (האפיון) להגביל אתכם. בכל מסך, בכל שדה ובכל תהליך, תמיד תשאלו את עצמכם: "מה הגבול כאן, ומה יקרה אם אעבור אותו?"
לקרוא מאמרים זה נחמד אבל לא יביא אותך לתוצאה שאתה רוצה, בדיוק בשביל זה הכנו עבורך את הקורס הדיגיטלי המהיר, תוך שעתיים וחצי תלמד את תחום הבדיקות ידניות, תוכל להתחיל לעבוד מהבית דרך FIVERR או ולהתכונן נכון לראיונות עבודה שיעזרו לך לצלוח אותם. כנס כאן הקורס ממוקד בבדיקות תוכנה ידניות הנותן בסיס חזק לתחום.
לעבוד מהבית כבודק תוכנה עם FIVERR >> לחץ כאן
TesQA 