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

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

סוגי בדיקות

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

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

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

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

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

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

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

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

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

בדיקת עומס ולחץ - Load/Stress Testing
בדיקת עומס בודקת איך המערכת מתפקדת תחת כמות משתמשים או בקשות גבוהה שהיא צפויה לקבל. בדיקת לחץ הולכת צעד נוסף, ובודקת מה קורה כשדוחפים את המערכת מעבר לגבולות שלה, כדי לראות איפה ואיך היא נשברת.

תהליך ומתודולוגיה

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

חבילת בדיקות - Test Suite
אוסף של מקרי בדיקה שרצים יחד, בדרך כלל כי הם קשורים לאותו פיצ'ר או אותו חלק במערכת. חבילת בדיקות להרשמה, למשל, תכלול את כל התרחישים סביב תהליך ההרשמה.

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

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

איכות מול כמות

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

באג / דיפקט - Bug/Defect
פער בין ההתנהגות הצפויה של התוכנה לבין מה שהיא בפועל עושה. כפתור שלא מגיב ללחיצה, למשל, הוא באג.

חומרת באג מול עדיפות - Bug Severity vs Priority
חומרה מתארת כמה הבאג הרסני מבחינה טכנית - האם המערכת קורסת או שזה רק פגם קוסמטי. עדיפות מתארת באיזה סדר צריך לתקן אותו. באג עם חומרה נמוכה יכול לקבל עדיפות גבוהה אם הוא נמצא בדף הבית שכולם רואים.

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

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

מושגים בסביבת הבדיקה

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

Mocking / Stub
כשבודקים חלק אחד במערכת, לפעמים לא רוצים או לא יכולים להשתמש ברכיב אמיתי, למשל שירות חיצוני שגובה כסף. Mock או Stub הם תחליפים מזויפים שמחזירים תשובה קבועה מראש, כדי שהבדיקה תישאר ממוקדת ומהירה בלי תלות בשירותים חיצוניים.

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

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

הצטרפו לקהילה בדיסקורד