בדיקות תוכנה ידניות: מה בודקים, איך עובדים ומה צריך לדעת

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

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

כאן נכנס לתמונה בודק התוכנה הידני.

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

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

1. מהן בדיקות ידניות (Manual Testing)?

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

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

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

בודק תוכנה ידני עשוי לבצע את הפעולות הבאות:

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

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

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

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

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

2. מה ההבדל בין בדיקות ידניות לבדיקות אוטומטיות?

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

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

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

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

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

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

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

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

3. מה בודקים במסגרת בדיקות תוכנה ידניות?

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

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

3.1 בדיקות פונקציונליות

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

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

דוגמאות:

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

נניח שמערכת מספקת הנחה של 10% על רכישה מעל 500 שקלים.

הבודק לא יסתפק בבדיקה של רכישה בסך 600 שקלים. הוא יבדוק גם רכישה בסך 499 שקלים, רכישה בסך 500 שקלים ורכישה בסך 501 שקלים.

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

3.2 בדיקות ממשק משתמש (UI Testing)

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

הבודק בוחן בין היתר:

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

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

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

3.3 בדיקות ולידציה של נתונים

בדיקות ולידציה בוחנות כיצד המערכת מתמודדת עם נתונים שהמשתמש מזין.

לדוגמה, בטופס הרשמה ניתן לבדוק:

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

נניח ששדה גיל מקבל מספרים בלבד.

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

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

3.4 בדיקות תהליכים עסקיים מקצה לקצה

בדיקות תהליך עסקי בוחנות רצף של פעולות ולא רק רכיב בודד.

לדוגמה, בתהליך רכישה באתר:

1. המשתמש מתחבר למערכת.
2. מחפש מוצר.
3. מוסיף אותו לעגלה.
4. מזין כתובת למשלוח.
5. בוחר אמצעי תשלום.
6. משלים את ההזמנה.
7. מקבל אישור הזמנה.

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

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

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

3.5 בדיקות הרשאות ואבטחת מידע בסיסית

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

דוגמאות:

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

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

3.6 בדיקות תאימות לדפדפנים ולמכשירים

מערכות אינטרנטיות עשויות לפעול בסביבות שונות.

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

לדוגמה:

• Chrome במחשב Windows.
• Edge במחשב ארגוני.
• Safari במכשירי iPhone.
• Chrome במכשירי Android.

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

4. סוגי בדיקות ידניות שכל בודק QA צריך להכיר

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

סוג הבדיקה	מה בודקים?	דוגמה
Smoke Testing	האם הפונקציות המרכזיות עובדות	התחברות ופתיחת מסך ראשי
Sanity Testing	האם שינוי ממוקד פועל כמצופה	תיקון חישוב הנחה
Regression Testing	האם שינוי חדש פגע בפונקציות קיימות	בדיקת תהליך הזמנה לאחר עדכון
Exploratory Testing	חקירה של המערכת ללא תסריט מלא מראש	ניסיון למצוא דרכים לא צפויות להשתמש בטופס
Usability Testing	נוחות ובהירות השימוש	בדיקה אם משתמש מבין כיצד להשלים הרשמה
Compatibility Testing	התנהגות בסביבות שונות	בדיקת אתר בכמה דפדפנים
Integration Testing	תקשורת בין מערכות ורכיבים	בדיקת העברת נתונים בין אתר למערכת CRM

בדיקות Smoke

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

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

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

בדיקות Regression

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

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

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

להרחבה בנושא, קראו את מדריך בדיקות הרגרסיה ב-SAP.

בדיקות Exploratory

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

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

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

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

5. איך כותבים תרחישי בדיקה (Test Cases)?

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

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

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

המבנה של תרחיש בדיקה

תרחיש בדיקה מקצועי כולל בדרך כלל את השדות הבאים:

שדה	הסבר
Test Case ID	מזהה ייחודי לתרחיש
Title	כותרת המתארת את מטרת הבדיקה
Preconditions	תנאים מוקדמים לביצוע
Test Data	הנתונים שיש להזין
Steps	שלבי הבדיקה
Expected Result	התוצאה הצפויה
Actual Result	התוצאה שהתקבלה בפועל
Status	Passed, Failed או Blocked

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

דוגמה מעשית לתרחיש בדיקה

נניח שמפתחים מסך התחברות לאתר.

Test Case ID: TC-LOGIN-001

Title: התחברות עם פרטי משתמש תקינים

Preconditions: קיים משתמש פעיל במערכת עם שם משתמש וסיסמה תקינים.

Test Data:

• Username: qa_test@example.com
• Password: סיסמת בדיקה שהוגדרה בסביבה הייעודית.

Steps:

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

Expected Result:

המשתמש מתחבר בהצלחה ומועבר למסך הראשי בהתאם לאפיון.

Actual Result: יתועד לאחר ביצוע הבדיקה.

Status: יתעדכן לאחר ביצוע הבדיקה.

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

איך כותבים תרחישי בדיקה איכותיים?

ראשית, יש לוודא שכל שלב ברור ואינו תלוי בפרשנות של הבודק.

שנית, יש להגדיר תוצאה צפויה שאפשר לבדוק באופן אובייקטיבי.

לדוגמה, "המערכת עובדת טוב" אינה תוצאה צפויה טובה.

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

שלישית, יש לכלול גם תרחישים חיוביים וגם תרחישים שליליים.

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

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

6. טכניקות לתכנון בדיקות ידניות

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

Equivalence Partitioning – חלוקה למחלקות שקילות

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

נניח ששדה גיל מאפשר ערכים בין 18 ל-65.

ניתן לחלק את הקלט לשלוש קבוצות:

• ערכים מתחת ל-18 – קלט לא תקין.
• ערכים בין 18 ל-65 – קלט תקין.
• ערכים מעל 65 – קלט לא תקין.

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

Boundary Value Analysis – בדיקות ערכי גבול

תקלות רבות מתרחשות בגבולות של תנאים עסקיים.

אם טופס מקבל גיל בין 18 ל-65, כדאי לבדוק את הערכים:

17, 18, 19, 64, 65 ו-66.

כך ניתן לזהות טעויות שבהן תנאי נכתב בטעות כגדול מ-18 במקום גדול או שווה ל-18.

Decision Table – טבלת החלטה

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

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

סוג לקוח	סכום רכישה	תוצאה צפויה
לקוח רגיל	300 ₪	ללא הנחה
לקוח רגיל	600 ₪	הנחה בהתאם לכללים
לקוח VIP	300 ₪	הנחת VIP
לקוח VIP	600 ₪	שילוב ההטבות לפי האפיון

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

State Transition Testing – בדיקות מעברי מצבים

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

לדוגמה, הזמנה יכולה לעבור בין המצבים:

טיוטה ← אושרה ← שולמה ← נשלחה ← הושלמה.

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

לדוגמה, האם אפשר לסמן הזמנה כמשלוח שהושלם לפני שהיא שולמה?

התשובה צריכה להגיע מהדרישות העסקיות.

7. איך מדווחים על באג בצורה מקצועית?

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

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

מבנה מומלץ לדיווח באג

Bug ID: BUG-102

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

Environment: Chrome, Windows, סביבת QA, גרסה 1.4.2.

Preconditions: קיימת עגלת קניות עם מוצר מתאים לקופון.

Steps to Reproduce:

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

Expected Result: סכום ההזמנה מתעדכן בהתאם לשיעור ההנחה שהוגדר.

Actual Result: הודעת הצלחה מופיעה, אך סכום ההזמנה נשאר ללא שינוי.

Severity: תיקבע בהתאם להשפעה העסקית ולחומרת התקלה.

Attachments: צילום מסך או הקלטת מסך, לפי הצורך.

מה ההבדל בין Severity ל-Priority?

Severity מתארת את חומרת ההשפעה של התקלה על המערכת או על המשתמש.

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

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

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

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

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

8. תהליך העבודה של בודק תוכנה ידני בארגון

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

שלב ראשון: קבלת דרישות ואפיון

הבודק מקבל מסמך אפיון, User Story או משימה שמתארת את השינוי המתוכנן.

בשלב זה עליו להבין:

• מה המערכת אמורה לבצע?
• מי המשתמשים בתהליך?
• אילו כללים עסקיים חלים?
• מה נחשב לתוצאה תקינה?
• אילו מערכות אחרות מושפעות מהשינוי?

אם הדרישה אינה ברורה, חשוב להעלות שאלות לפני תחילת הבדיקות.

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

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

לאחר הבנת הדרישות, הבודק מתכנן מה לבדוק ובאיזה סדר.

התכנון כולל את היקף הבדיקות, סביבת הבדיקה, הנתונים הנדרשים והסיכונים המרכזיים.

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

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

שלב שלישי: הכנת סביבת בדיקות ונתונים

הבודק מוודא שהמערכת זמינה בסביבת הבדיקות ושהנתונים הדרושים קיימים.

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

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

שלב רביעי: ביצוע הבדיקות

הבודק מבצע את תרחישי הבדיקה, מתעד את התוצאות ומסמן כל תרחיש כ-Passed, Failed או Blocked.

כאשר מתגלה תקלה, יש לתעד אותה ולוודא שהיא ניתנת לשחזור.

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

שלב חמישי: דיווח ומעקב אחר תקלות

לאחר פתיחת באג, הבודק עוקב אחר הטיפול בו.

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

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

שלב שישי: סיכום בדיקות

בסיום מחזור הבדיקות, צוות ה-QA עשוי להכין סיכום הכולל:

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

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

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

9. אילו כלים משמשים בבדיקות ידניות?

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

Jira – ניהול משימות ובאגים

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

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

TestRail – ניהול תרחישי בדיקה

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

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

Chrome DevTools – כלי פיתוח בדפדפן

Chrome DevTools מאפשר לבדוק היבטים טכניים של אפליקציות אינטרנט.

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

• לבדוק שגיאות JavaScript בלשונית Console.
• לראות בקשות ותגובות HTTP בלשונית Network.
• לבחון את מבנה ה-HTML וה-CSS.
• לבדוק כיצד האתר מתנהג בתצוגת מכשירים שונים.
• לזהות בקשות שנכשלו או זמני תגובה חריגים.

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

Postman – בדיקות API

גם בודק שעיקר עבודתו ידני יכול להיעזר ב-Postman כדי לשלוח בקשות API ולבחון את התשובות.

לדוגמה, ניתן לשלוח בקשת GET לקבלת פרטי משתמש, או בקשת POST ליצירת רשומה בסביבת בדיקות.

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

למידע נוסף ניתן לקרוא על סוגי בדיקות התוכנה במדריך המלא.

Excel ו-Google Sheets

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

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

כלי ניטור ולוגים

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

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

להרחבה בנושא, קראו את המדריך לניטור מערכות IT.

10. אילו מיומנויות צריך כדי לעבוד בבדיקות ידניות QA?

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

יש כמה מיומנויות מרכזיות שכדאי לפתח.

חשיבה אנליטית

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

תשומת לב לפרטים

הבדל קטן בין התוצאה הצפויה לתוצאה בפועל עשוי להעיד על תקלה משמעותית.

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

יכולת תיעוד וכתיבה

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

הבנה עסקית

מערכות תוכנה נועדו לתמוך בתהליכים עסקיים.

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

תקשורת ועבודת צוות

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

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

אנגלית טכנית

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

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

11. האם צריך לדעת SQL, API או תכנות כדי לבצע בדיקות ידניות?

התשובה תלויה בסוג המשרה ובמערכת הנבדקת.

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

מיומנות	למה היא משמשת?	רמת הידע ההתחלתית
SQL	בדיקת נתונים במסד נתונים	SELECT, WHERE, ORDER BY
API	בדיקת תקשורת בין מערכות	HTTP, GET, POST, קודי תגובה
HTML ו-CSS	הבנת מבנה ותצוגת אתר	היכרות עם אלמנטים בסיסיים
JavaScript	הבנת שגיאות והתנהגות בדפדפן	משתנים, תנאים ופונקציות בסיסיות
Git	היכרות עם ניהול גרסאות	הבנת Repository ו-Commit

SQL לבודקי תוכנה

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

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

שאילתה בסיסית עשויה להיראות כך:

SELECT order_id, status, total_amount
FROM orders
WHERE order_id = 1001;

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

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

בדיקות API

בדיקות API מאפשרות לבדוק את התקשורת בין רכיבי מערכת גם ללא שימוש בממשק המשתמש.

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

מי שמעוניין להתקדם בתחום יכול ללמוד גם בדיקות תוכנה אוטומטיות ובהמשך להכיר כלי אוטומציה כמו Playwright ו-Selenium.

12. איך מתחילים ללמוד בדיקות תוכנה ידניות ללא ניסיון?

מי שמעוניין להיכנס לתחום יכול לבנות מסלול למידה מעשי הדרגתי.

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

שלב 1: ללמוד את יסודות ה-QA

יש להתחיל מהבנת מחזור חיי פיתוח התוכנה, ההבדל בין QA ל-Testing, סוגי בדיקות, תרחישי בדיקה ודיווח באגים.

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

שלב 2: לתרגל על אתר אינטרנט

בחרו אתר ציבורי או מערכת דמו שמיועדת לתרגול.

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

כתבו לפחות 15 תרחישי בדיקה, כולל תרחישים חיוביים, שליליים וערכי גבול.

שלב 3: ליצור תיק עבודות

תיק עבודות יכול לכלול:

• מסמך Test Plan קצר.
• גיליון עם תרחישי בדיקה.
• חמישה דיווחי באגים לדוגמה.
• צילומי מסך שממחישים את התוצאות.
• סיכום בדיקות שמציג את הכיסוי ואת הממצאים.

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

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

שלב 4: ללמוד כלים בסיסיים

לאחר רכישת היסודות, מומלץ להתנסות ב-Jira או בכלי דומה לניהול תקלות, להכיר את Chrome DevTools וללמוד SQL בסיסי.

בהמשך אפשר להוסיף בדיקות API באמצעות Postman.

שלב 5: להתכונן לראיונות עבודה

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

כדאי לתרגל שאלות כגון:

• איך היית בודק שדה טלפון?
• איך היית בודק מחשבון?
• מה ההבדל בין Severity ל-Priority?
• מה ההבדל בין Smoke ל-Regression?
• כיצד היית מדווח על באג שלא ניתן לשחזר בכל פעם?
• מה היית עושה אם מסמך האפיון אינו ברור?

בראיון חשוב להסביר את דרך החשיבה ולא רק למנות סוגי בדיקות.

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

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

נניח שהדרישות הן:

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

תכנון תרחישי בדיקה

מזהה	תרחיש	תוצאה צפויה
TC-01	הרשמה עם נתונים תקינים	ההרשמה מצליחה
TC-02	שליחת טופס ללא שם	מתקבלת הודעת שגיאה
TC-03	הזנת כתובת מייל לא תקינה	ההרשמה נחסמת
TC-04	סיסמה באורך שבעה תווים	מתקבלת הודעת שגיאה
TC-05	סיסמה באורך שמונה תווים	עוברת את בדיקת האורך
TC-06	אי-אישור תנאי השימוש	לא ניתן להשלים הרשמה
TC-07	לחיצה כפולה על כפתור השליחה	לא נוצרים חשבונות כפולים
TC-08	ניסיון הרשמה עם כתובת קיימת	מתקבלת הודעה מתאימה

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

הרחבת הבדיקות למצבי קצה

כדי להעמיק את הבדיקה, אפשר לבדוק גם:

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

יש להבחין בין הדרישות המפורשות לבין בדיקות חקרניות שמטרתן לגלות התנהגויות לא צפויות.

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

14. טעויות נפוצות של מתחילים בבדיקות ידניות

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

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

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

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

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

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

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

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

15. שאלות ותשובות נפוצות על בדיקות תוכנה ידניות

האם בדיקות ידניות עדיין רלוונטיות בעידן האוטומציה וה-AI?

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

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

היקף העבודה הידנית משתנה בין ארגונים ותפקידים.

האם אפשר לעבוד ב-QA בלי לדעת תכנות?

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

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

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

כמה זמן לוקח ללמוד בדיקות ידניות?

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

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

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

האם צריך תואר כדי לעבוד בבדיקות תוכנה?

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

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

מה ההבדל בין QA לבודק תוכנה?

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

בדיקות תוכנה (Testing) הן חלק מהתחום ומתמקדות בבחינת המערכת וזיהוי פערים בין ההתנהגות בפועל לדרישות.

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

האם בדיקות ידניות מתאימות למי שמגיע ללא ניסיון בהייטק?

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

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

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

סיכום: מה צריך לזכור על בדיקות ידניות?

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

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

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

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

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

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

קורס לבדיקות תוכנה מדויק

לעבוד מהבית כבודק תוכנה עם FIVERR >> לחץ כאן