- למד את הבסיס התיאורטי: אל תדלג על השלב הזה. הכר את מונחי היסוד: מהו מחזור חיי פיתוח תוכנה (SDLC), מה ההבדל בין בדיקות פונקציונליות ללא-פונקציונליות, ואיך נראה מחזור חיים של באג (Bug Lifecycle). הספר הדיגיטלי או הסילבוס של ISTQB (ההסמכה הבינלאומית לבדיקות) הוא מקום מעולה להתחיל ממנו, גם אם אתה לא ניגש למבחן מיד.
- תרגל "על יבש" (בניית תיק עבודות): מעסיקים מחפשים ניסיון פרקטי. קח אתר אינטרנט מוכר (למשל, אתר מסחר או אפליקציית ניהול משימות) והתחל לכתוב עבורו תרחישי בדיקה (Test Cases). תעד באגים שמצאת בצורה מקצועית. זה יהיה "תיק העבודות" שלך בראיונות.
- הצטרף לפלטפורמות בדיקות המונים (Crowdsourced Testing): אתרים כמו uTest או TestIO מאפשרים לבודקים מתחילים לבדוק אפליקציות ואתרים אמיתיים של חברות גדולות ולקבל תשלום על כל באג שמתגלה. זו הדרך הטובה ביותר להכניס "ניסיון מעשי" אמיתי לקורות החיים.
5 הכללים הכי חשובים בבדיקות תוכנה (בדגש על ידני)
כדי להיות בודק מעולה, אלו העקרונות שחייבים להוביל אותך בכל בדיקה:
1. בדיקות מוקדמות חוסכות כסף וזמן (Early Testing)
באגים שנמצאים בשלבי התכנון או בתחילת הפיתוח עולים פרושים בהשוואה לבאגים שנמצאים רגע לפני שהמוצר עולה לאוויר (או גרוע מכך – כשהוא כבר אצל הלקוח). כבודק ידני, התפקיד שלך מתחיל כבר בקריאת מסמך דרישות המוצר (PRD). אם משהו לא הגיוני שם – זה הזמן להרים דגל.
דוגמה: במסמך האיפיון של אפליקציית משימות כתוב: "משתמש יכול לקבוע תזכורת למשימה". הערת ה-QA בשלב המוקדם: לא צוין מה קורה אם המשתמש בוחר זמן שכבר עבר (למשל, אתמול). תיקון הלוגיקה הזו בקוד בשלב התיאורטי לוקח דקה; תיקון שלה אחרי שהקוד נכתב דורש שעות עבודה.
2. הבנת חשיבות ה-Boundary Value Analysis (בדיקת ערכי קצה)
מערכות נוטות לקרוס או להתנהג בצורה שגויה דווקא בגבולות של הטווחים המותרים. בודק ידני מיומן לא יבזבז זמן על בדיקת עשרות ערכים באמצע, אלא יתמקד בדיוק בנקודות הקצה ובמה שמעבר להן.
דוגמה: שדה להזנת "גיל משתמש" באפליקציה צריך לקבל ערכים בין 18 ל-120. מה תבדוק ידנית? את ערכי הגבול: 18 ו-120 (שאמורים לעבור), ואת הערכים שחורגים ב-1: 17 ו-121 (שאמורים להיחסם ולהציג שגיאה).
3. בדיקות רגרסיה הן חובה (Regression Testing)
בכל פעם שהמפתח מתקן באג או מוסיף פיצ'ר חדש, יש סיכון גבוה מאוד שמשהו אחר, שעבד מצוין עד עכשיו, נשבר. לעולם אל תניח ש-"אם לא נגעו באזור הזה, הוא בטוח עובד".
דוגמה: המפתח תיקן באג בכפתור השיתוף של המשימות. הבדיקה שלך: מעבר לבדיקה שכפתור השיתוף עובד, אתה חייב לבצע בדיקת רגרסיה על כפתור "מחיקת משימה" ו"עריכת משימה" שנמצאים באותו תפריט, כדי לוודא שהתיקון לא שיבש את הפונקציות הקיימות.
4. כתיבת דוח באג ברור ומקצועי (Bug Reporting)
באג שלא תועד כמו שצריך הוא באג שלא יתוקן. כבודק ידני, המוצר הפיזי שלך הוא "דוח הבאג". הוא צריך להיות ברור, אובייקטיבי, ללא הנחות יסוד, וכזה שכל מפתח יוכל לשחזר לפיו את הבעיה בשניות.
דוגמה למבנה דוח באג איכותי:
- כותרת: שגיאת קריסה (Crash) בעת ניסיון להעלות תמונת פרופיל בפורמט PNG.
- צעדים לשחזור (Steps to Reproduce):
- היכנס למסך הגדרות פרופיל.
- לחץ על "שנה תמונת פרופיל".
- בחר קובץ בפורמט PNG שגודלו מעל 5MB.
- תוצאה צפויה (Expected): המערכת תציג הודעת שגיאה: "הקובץ גדול מדי, אנא העלה קובץ קטן מ-2MB".
- תוצאה בפועל (Actual): האפליקציה נסגרת באופן פתאומי (Crash).
5. אימוץ חשיבה שלילית וסקרנות (Pesticide Paradox & Negative Testing)
אם תבדוק רק את ה-"Happy Path" (המסלול שבו המשתמש עושה בדיוק מה שציפו ממנו), המוצר ייראה מעולה, אבל ייכשל במציאות. בודק ידני מצוין חושב כמו "ההרסן היצירתי" – מה קורה אם לוחצים פעמיים רצוף? מה קורה אם מנתקים את האינטרנט באמצע שמירה?
דוגמה: בבדיקת טופס תשלום, ה-Happy Path הוא להזין כרטיס תקין וללחוץ "שלם". בדיקה שלילית (Negative Testing): ללחוץ על כפתור ה-"שלם" 5 פעמים ברצף במהירות (כדי לראות שהלקוח לא מחויב 5 פעמים), או להזין אותיות בשדה של מספר הכרטיס.
לקרוא מאמרים זה נחמד אבל לא יביא אותך לתוצאה שאתה רוצה, בדיוק בשביל זה הכנו עבורך את הקורס הדיגיטלי המהיר, תוך שעתיים וחצי תלמד את תחום הבדיקות ידניות, תוכל להתחיל לעבוד מהבית דרך FIVERR או ולהתכונן נכון לראיונות עבודה שיעזרו לך לצלוח אותם. כנס כאן הקורס ממוקד בבדיקות תוכנה ידניות הנותן בסיס חזק לתחום.
לעבוד מהבית כבודק תוכנה עם FIVERR >> לחץ כאן
TesQA 