איך כותבים תסריט בדיקה - מדריך מעשי עם דוגמאות

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

המבנה של תסריט בדיקה

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

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

דוגמה מלאה

תסריט להתחברות עם סיסמה שגויה:

• כותרת: התחברות עם סיסמה שגויה מציגה הודעת שגיאה ולא חושפת אם המשתמש קיים
• תנאי מקדים: קיים משתמש רשום ומאומת עם הכתובת
• צעדים: 1. לפתוח את עמוד ההתחברות. 2. להזין . 3. להזין סיסמה שגויה. 4. ללחוץ על התחברות.
• תוצאה מצופה: המשתמש נשאר בעמוד ההתחברות; מוצגת הודעה כללית "שם משתמש או סיסמה שגויים"; ההודעה אינה מבחינה בין משתמש לא קיים לסיסמה שגויה; שדה הסיסמה מתרוקן; שדה האימייל נשמר.
• עדיפות: גבוהה - נוגע לאבטחה

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

איך בוחרים מה לבדוק

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

• מחלקות שקילות. מחלקים את הקלט לקבוצות שהמערכת אמורה להתייחס אליהן זהה, ובודקים נציג אחד מכל קבוצה. לשדה גיל 18-120: מתחת ל-18, בטווח, מעל 120, ריק, לא מספרי.
• ערכי גבול. באגים מתחבאים בקצוות. לאותו שדה: 17, 18, 19, 119, 120, 121. זו הטכניקה עם התשואה הגבוהה ביותר ליחידת מאמץ.
• טבלת החלטות. כשיש כמה תנאים שמשפיעים יחד, בונים טבלה של כל הצירופים ובוחרים מהם. מונע את המצב שבו בודקים כל תנאי לחוד ומפספסים את השילוב.

מסלול חיובי, שלילי וקצה

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

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

חמש טעויות שחוזרות

• תוצאה מצופה מעורפלת. "המערכת מגיבה כמצופה" אינו תוצאה. מה בדיוק על המסך?
• תסריט שבודק חמישה דברים. כשהוא נכשל, לא ברור מה נשבר. בדיקה אחת, מטרה אחת.
• תלות בין תסריטים. אם תסריט 7 מניח שתסריט 6 רץ לפניו, אי אפשר להריץ אותם בנפרד או במקביל.
• הנחות סמויות. "להתחבר למערכת" - כאיזה משתמש? עם אילו הרשאות? זה חייב להיות בתנאי המקדים.
• תיאור מימוש במקום התנהגות. "לוודא שהשדה is_valid מקבל true" יישבר בכל refactor. תארו מה המשתמש רואה.

מתי תסריט הופך לאוטומציה

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

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

דוגמה שנייה: תהליך תשלום

תסריטים למסלול קריטי מורכב יותר, כדי לראות איך מפרקים תהליך רב-שלבי:

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

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

איך מנהלים מאגר תסריטים לאורך זמן

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

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

מה מבקשים מכם בראיון

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

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

מתסריט לדוח באג

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

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

תבנית Given-When-Then

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

• Given - המצב לפני. "בהינתן משתמש מחובר עם עגלה ריקה"
• When - הפעולה. "כאשר הוא מוסיף פריט שאזל מהמלאי"
• Then - התוצאה. "אז מוצגת הודעה שהפריט אינו זמין והעגלה נשארת ריקה"

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

כמה תסריטים באמת צריך

סוג הפיצ'ר	סדר גודל סביר	דגש
שדה קלט בודד	6-10	ערכי גבול וקלט לא חוקי
טופס עם כמה שדות	12-20	שילובי שדות, לא כל שדה לחוד
תהליך רב-שלבי	15-30	נפילה באמצע, חזרה אחורה, כפילות
הרשאות ותפקידים	לפי מספר התפקידים	מה כל תפקיד לא אמור לראות

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

מי כותב את התסריטים ומתי

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

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

שאלות נפוצות

מה זה תסריט בדיקה?

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

מה ההבדל בין תסריט בדיקה לתרחיש בדיקה?

תרחיש (scenario) מתאר מה בודקים ברמה גבוהה - "התחברות למערכת". תסריט (test case) הוא מקרה ספציפי בתוכו עם צעדים ותוצאה - "התחברות עם סיסמה שגויה". תרחיש אחד מכיל בדרך כלל כמה תסריטים.

כמה תסריטים צריך לכתוב לפיצ'ר?

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

איך בוחרים אילו מקרים לבדוק?

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

מה הופך תוצאה מצופה לטובה?

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