1. מהן בדיקות API?

API הוא ראשי תיבות של Application Programming Interface. מדובר בממשק שמאפשר למערכות, שירותים ורכיבי תוכנה שונים לתקשר ביניהם ולהחליף מידע.

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

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

מה בודקים במסגרת בדיקות API?

• HTTP Status Codes: האם המערכת מחזירה קוד מתאים כמו 200, 201, 400, 401, 403, 404 או 500.
• תקינות נתונים: האם התשובה מכילה את השדות הנכונים ובפורמט הצפוי.
• ולידציה: מה קורה כאשר שולחים שדות חסרים, ערכים לא תקינים או נתונים מחוץ לטווח.
• לוגיקה עסקית: האם המערכת מיישמת את הכללים העסקיים שהוגדרו.
• הרשאות ואבטחה: האם משתמש יכול לגשת רק למשאבים המותרים לו.
• טיפול בשגיאות: האם מתקבלות הודעות שגיאה מתאימות ולא נחשף מידע רגיש.
• ביצועים: כמה זמן לוקח לשרת להחזיר תשובה ומה קורה תחת עומס.
• עקביות נתונים: האם פעולה שבוצעה נשמרה כראוי והאם הנתונים חוזרים בצורה נכונה בבקשה נוספת.

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

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

2. מהן בדיקות UI?

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

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

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

מה בודקים במסגרת בדיקות UI?

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

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

3. ההבדלים המרכזיים בין בדיקות API לבדיקות UI

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

האם בדיקות API תמיד מהירות יותר?

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

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

4. דוגמה מעשית: בדיקת תהליך התחברות למערכת

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

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

מה למדנו מהדוגמה?

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

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

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

5. יתרונות וחסרונות של בדיקות API לעומת בדיקות UI

יתרונות בדיקות API

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

חסרונות בדיקות API

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

יתרונות בדיקות UI

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

חסרונות בדיקות UI

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

6. מתי כדאי לבצע בדיקות API ומתי בדיקות UI?

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

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

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

7. כלים לבדיקות API ולבדיקות UI

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

כלים נפוצים לבדיקות API

כלים נפוצים לבדיקות UI

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

8. איך בונים אסטרטגיית בדיקות משולבת?

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

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

שלב ראשון: זיהוי תהליכים עסקיים קריטיים

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

לדוגמה:

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

שלב שני: חלוקת האחריות בין API ל-UI

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

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

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

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

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

לדוגמה, בעת יצירת הזמנה:

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

שלב רביעי: שילוב הבדיקות בתהליך CI/CD

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

אפשר להגדיר סדר עבודה שבו:

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

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

9. אוטומציה בבדיקות API לעומת אוטומציה בבדיקות UI

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

אוטומציית API

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

דוגמה פשוטה לבדיקת API באמצעות JavaScript ו-Playwright:

import { test, expect } from '@playwright/test';

test('Get user details', async ({ request }) => {
  const response = await request.get(
    'https://api.example.com/users/1'
  );

  expect(response.status()).toBe(200);

  const data = await response.json();

  expect(data.id).toBe(1);
  expect(data.name).toBeTruthy();
});

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

כתובת example.com היא כתובת המחשה בלבד ויש להחליף אותה בכתובת API אמיתית של סביבת הבדיקה.

אוטומציית UI

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

דוגמה פשוטה לבדיקת UI באמצעות Playwright:

import { test, expect } from '@playwright/test';

test('Login page test', async ({ page }) => {
  await page.goto('https://example.com/login');

  await page.getByLabel('Email').fill(
    'test@example.com'
  );

  await page.getByLabel('Password').fill(
    'Test123!'
  );

  await page.getByRole('button', {
    name: 'Login'
  }).click();

  await expect(page).toHaveURL(/dashboard/);
});

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

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

מה כדאי להפוך לאוטומטי?

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

10. טעויות נפוצות בבדיקות API ובדיקות UI

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

טעות 1: הסתמכות על בדיקות UI בלבד

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

טעות 2: הסתמכות על קוד HTTP בלבד

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

טעות 3: בדיקת תרחישים חיוביים בלבד

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

טעות 4: שימוש באוטומציה שאינה יציבה

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

טעות 5: בדיקת API ללא אימות נתונים

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

טעות 6: שכחת בדיקות אבטחה והרשאות

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

11. מה כדאי ללמוד כדי להתמקצע בבדיקות API ובדיקות UI?

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

שלב ראשון: יסודות בדיקות התוכנה

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

שלב שני: לימוד בדיקות API

• הבנת HTTP ופרוטוקולי תקשורת.
• היכרות עם GET, POST, PUT, PATCH ו-DELETE.
• הבנת קודי סטטוס HTTP.
• עבודה עם JSON ו-Headers.
• הבנת Authentication ו-Authorization.
• עבודה עם Postman ו-Swagger.
• בדיקת REST API וכתיבת תסריטי בדיקה.

שלב שלישי: לימוד בדיקות UI

• היכרות עם HTML ו-CSS.
• הבנת DOM ו-Selectors.
• עבודה עם DevTools של הדפדפן.
• לימוד Playwright או Selenium.
• כתיבת בדיקות אוטומטיות ב-JavaScript או בשפה אחרת.
• היכרות עם Page Object Model.

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

12. דוגמה לאסטרטגיית בדיקות במערכת מסחר אלקטרוני

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

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

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

13. שאלות ותשובות נפוצות על בדיקות API לעומת בדיקות UI