מה זה QA? בדיקות תוכנה בשפה פשוטה

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

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

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

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

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

דוגמה: חנות אונליין

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

בדיקות ידניות ובדיקות אוטומטיות - מה ההבדל?

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

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

צוותים רבים משלבים את שתי הגישות:

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

אילו סוגי בדיקות תוכנה יש?

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

לפי מה בודקים: פונקציונליות ולא-פונקציונליות

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

לפי השלב: מהרכיב הקטן ועד המערכת כולה

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

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

לפי השיטה: קופסה שחורה וקופסה לבנה

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

מה עושה איש QA בצוות פיתוח?

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

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

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

מה זה מחזור החיים של באג (Bug Life Cycle)?

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

1. New (חדש) - הבודק פתח דיווח עם צעדים לשחזור, תוצאה צפויה ותוצאה בפועל.
2. Assigned (הוקצה) - ראש הצוות או מנהל המוצר עבר על הדיווח והעביר אותו למפתח.
3. In Progress (בטיפול) - המפתח משחזר את הבעיה ומתקן אותה.
4. Fixed (תוקן) - התיקון נכנס לגרסה חדשה.
5. Retest (בדיקה חוזרת) - הבודק מריץ שוב את אותם צעדים על הגרסה החדשה.
6. Closed (נסגר) - הבעיה לא חוזרת והבאג נסגר. אם היא עדיין קיימת, הבאג עובר למצב Reopened וחוזר למפתח.

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

איפה QA משתלב בפיתוח Agile?

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

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

• משתתף בתכנון הספרינט ושואל איך כל דרישה תיבדק, עוד לפני שמתחילים לפתח. הגישה הזאת נקראת Shift Left - להקדים את הבדיקות לשלב מוקדם יותר.
• בודק כל משימה ברגע שהיא מוכנה, ולא מחכה לסוף הפרויקט.
• עוזר להגדיר מתי משימה נחשבת גמורה (Definition of Done), למשל רק אחרי שנבדקה ועברה.
• מריץ בדיקות רגרסיה בכל ספרינט, ולכן אוטומציה חשובה במיוחד בצוותי Agile.

איך מתחילים ללמוד QA?

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

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