שאלות ראיון עבודה לבודק תוכנה (QA) - עם תשובות

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

איך נראה ראיון עבודה ל-QA ואיך לתרגל בעמוד הזה

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

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

שאלות ראיון עבודה QA ברמה בסיסית: מושגי יסוד

שאלה 1

מה ההבדל בין QA לבין QC, ואיפה בדיקות התוכנה נכנסות?

שאלה 2

מה ההבדל בין Error, Defect ו-Failure? תנו דוגמה.

שאלה 3

מה ההבדל בין בדיקות Black Box לבין בדיקות White Box?

שאלה 4

מהן רמות הבדיקה (Test Levels), ומי מבצע כל אחת מהן בדרך כלל?

שאלה 5

ל-ISTQB יש 7 עקרונות של בדיקות תוכנה. כמה מהם אתם יכולים למנות ולהסביר?

תכנון בדיקות (Test Design)

שאלה 6

שדה גיל בטופס מקבל מספר שלם בין 18 ל-65, כולל. חלקו אותו למחלקות שקילות (Equivalence Partitioning). כמה מחלקות יש, ואיזה ערך תבדקו בכל אחת?

שאלה 7

באותו שדה גיל (18 עד 65, כולל), אילו ערכים תבדקו בבדיקת ערכי גבול דו-ערכית (Boundary Value Analysis)?

• א. 17, 18, 65, 66
• ב. 18, 65
• ג. 0, 18, 65, 100
• ד. 17, 30, 66

שאלה 8

אילו שדות יש ב-Test Case? כתבו כמה מקרי בדיקה למסך התחברות עם שם משתמש וסיסמה.

באגים: חומרה, עדיפות ומחזור חיים

שאלה 9

מה ההבדל בין Severity לבין Priority? תנו דוגמה לבאג בחומרה גבוהה ועדיפות נמוכה, ולבאג בחומרה נמוכה ועדיפות גבוהה.

שאלה 10

תארו את מחזור החיים של באג (Bug Life Cycle), מהרגע שנמצא ועד שנסגר.

שאלה 11

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

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

שאלה 12

מה ההבדל בין Waterfall לבין Agile, ואיך מקומן של הבדיקות שונה בכל אחת מהשיטות?

שאלה 13

מה זה Scrum? מהו ספרינט, אילו תפקידים ואילו אירועים יש בו?

שאלה 14

באג בטופס התשלום תוקן. מה ההבדל בין בדיקה חוזרת (Retest) לבין בדיקת רגרסיה (Regression), ומה תריצו בכל אחת?

שאלה 15

מה ההבדל בין Smoke Test לבין Sanity Test?

שאלות מעשיות: איך הייתם בודקים?

שאלה 16

איך תבדקו את שדה החיפוש באתר קניות?

שאלה 17

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

SQL ואוטומציה ברמת ג'וניור

שאלה 18

בטבלה Users יש את העמודות UserID, FullName, Email ו-City. כתבו שאילתה שמחזירה את כל המשתמשים מהעיר Haifa, ושאילתה שמוצאת כתובות מייל שמופיעות בטבלה יותר מפעם אחת. בונוס: מתי כדאי להפוך בדיקה לאוטומטית, ומה זו בדיקת API?

תשובות והסברים

תשובה 1

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

תשובה 2

אדם עושה טעות (Error, נקראת גם Mistake), למשל מפתח שהבין לא נכון דרישה. הטעות יוצרת פגם (Defect, נקרא גם Bug או Fault) בקוד או במסמך. כשהקוד הפגום רץ, הפגם עלול לגרום לכשל (Failure) - התנהגות שונה מהצפוי שהמשתמש רואה. לא כל פגם מגיע לכשל: אם החלק הפגום לא מורץ, הכשל לא יופיע.

תשובה 3

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

תשובה 4

ארבע הרמות הקלאסיות: בדיקות יחידה (Unit או Component) של רכיב בודד, בדרך כלל על ידי המפתח; בדיקות אינטגרציה של הממשקים והתקשורת בין רכיבים או מערכות; בדיקות מערכת (System) של המערכת השלמה מול הדרישות, בדרך כלל על ידי צוות הבדיקות; ובדיקות קבלה (Acceptance, למשל UAT) שבודקות שהמערכת מוכנה לשימוש ועונה על צורכי הלקוח, לרוב בידי הלקוח או נציגיו.

תשובה 5

שבעת העקרונות: (1) בדיקות מראות שיש תקלות, לא שאין תקלות; (2) בדיקה ממצה של כל האפשרויות היא בלתי אפשרית; (3) בדיקה מוקדמת חוסכת זמן וכסף; (4) תקלות נוטות להתקבץ - מעט רכיבים מכילים את רוב התקלות; (5) בדיקות נשחקות - הרצה חוזרת של אותן בדיקות מוצאת פחות תקלות חדשות (בעבר נקרא Pesticide Paradox); (6) בדיקות תלויות הקשר; (7) הטעות של היעדר תקלות - מוצר בלי תקלות ידועות עדיין יכול להיכשל אם הוא לא עונה על צורכי המשתמשים. בראיון מספיק להסביר היטב שלושה או ארבעה מהם.

תשובה 6

יש שלוש מחלקות מספריות: מתחת ל-18 (לא תקינה, למשל 10), 18 עד 65 (תקינה, למשל 40) ומעל 65 (לא תקינה, למשל 80). הרעיון: המערכת אמורה להתייחס לכל הערכים במחלקה באותה צורה, ולכן ערך מייצג אחד מכל מחלקה מספיק - כאן שלוש בדיקות. מועמד טוב יוסיף מחלקות לא תקינות נוספות: שדה ריק, אותיות ומספר עשרוני.

תשובה 7

התשובה הנכונה היא א. בבדיקה דו-ערכית בודקים כל גבול ואת השכן הקרוב שלו במחלקה הסמוכה: 17 ו-18 בגבול התחתון, 65 ו-66 בגבול העליון. ב' בודקת רק את הגבולות עצמם, ג' בודקת ערכים רחוקים מהגבולות, ו-ד' מפספסת את 18 ואת 65. בגרסה התלת-ערכית מוסיפים גם את השכן מהצד השני: 17, 18, 19, 64, 65, 66.

תשובה 8

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

תשובה 9

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

תשובה 10

מסלול טיפוסי: New (נפתח) - Assigned (שויך למפתח) - Open או In Progress (בטיפול) - Fixed (תוקן) - Retest (חוזר לבודק) - Verified ו-Closed (התיקון אומת, הבאג נסגר). אם התיקון לא עבד, הבאג עובר ל-Reopened וחוזר למפתח. סטטוסים נוספים: Rejected (לא באג), Duplicate (כפול) ו-Deferred (נדחה לגרסה אחרת). השמות משתנים בין כלים וחברות, אבל העיקרון זהה. הסבר מפורט על השלבים יש בהרצאה מחזור חיים של תקלה - Bug Life Cycle.

תשובה 11

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

תשובה 12

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

תשובה 13

Scrum היא מסגרת עבודה של Agile. יש בה שלושה תפקידים: Product Owner (קובע את סדר העדיפויות ב-Product Backlog), Scrum Master (עוזר לצוות לעבוד לפי Scrum ומסיר מכשולים) וה-Developers - כל מי שבונה את המוצר, כולל הבודקים. ספרינט הוא פרק זמן קבוע של חודש או פחות; בהרבה צוותים הוא נמשך שבועיים. האירועים: Sprint Planning, Daily Scrum (פגישה יומית קצרה), Sprint Review ו-Sprint Retrospective.

תשובה 14

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

תשובה 15

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

תשובה 16

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

תשובה 17

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

תשובה 18

השאילתה הראשונה: SELECT * FROM Users WHERE City = 'Haifa'; - WHERE מסנן שורות. השאילתה השנייה: SELECT Email, COUNT(*) FROM Users GROUP BY Email HAVING COUNT(*) > 1; - GROUP BY מקבץ לפי מייל, ו-HAVING מסנן קבוצות אחרי הספירה (WHERE לא יכול לסנן לפי COUNT). בונוס: כדאי להפוך לאוטומטיות בדיקות יציבות שרצות שוב ושוב, כמו רגרסיה ו-Smoke; פחות כדאי בבדיקה חד-פעמית, במסך שמשתנה כל הזמן ובבדיקות שימושיות. בדיקת API בודקת את השרת ישירות, בלי ממשק משתמש: שולחים בקשה ובודקים את קוד התשובה (למשל 200 להצלחה, 404 כשהמשאב לא נמצא) ואת התוכן שחזר.

איך להמשיך להתכונן לראיון

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