אוטומציה בבדיקות תוכנה: מה כדאי להפוך לאוטומטי ומה לא?

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

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

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

מהי אוטומציה בבדיקות תוכנה?

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

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

כלים כמו Playwright, Selenium ו-Cypress מאפשרים לבנות בדיקות אוטומטיות עבור אפליקציות ואתרים.

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

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

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

אוטומציה יכולה לסייע במספר תחומים:

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

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

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

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

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

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

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

1. בדיקות שחוזרות על עצמן

זהו אחד המועמדים הטבעיים ביותר לאוטומציה.

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

לדוגמה:

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

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

2. בדיקות Regression

בדיקות Regression נועדו לבדוק שפונקציונליות קיימת לא נשברה בעקבות שינוי חדש.

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

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

3. בדיקות Smoke

בדיקות Smoke בודקות שהמערכת במצב בסיסי שמאפשר להמשיך לבדיקה.

לדוגמה:

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

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

4. תרחישים עם תוצאה ברורה

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

לדוגמה:

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

ככל שהתוצאה ברורה יותר, כך קל יותר לבנות Assertion יציב.

5. בדיקות עם כמויות גדולות של נתונים

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

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

6. בדיקות API

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

לדוגמה, ניתן לבדוק:

• קודי HTTP.
• מבנה JSON.
• שדות חובה.
• זמן תגובה.
• הרשאות.
• טיפול בשגיאות.
• התנהגות עבור נתונים תקינים ולא תקינים.

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

7. תרחישי E2E מרכזיים

בדיקות End-to-End בודקות תהליך שלם מנקודת מבט של המשתמש או המערכת.

לדוגמה: הרשמה → התחברות → יצירת הזמנה → תשלום → קבלת אישור.

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

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

אילו בדיקות לא כדאי למהר להפוך לאוטומטיות?

1. בדיקות חד-פעמיות

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

במקרה כזה כדאי לשאול:

• האם הבדיקה תחזור בעתיד?
• האם היא חלק מתהליך Regression?
• האם יש לה חשיבות גבוהה?
• האם הנתונים או הממשק צפויים להשתנות?

אם התשובה לרוב השאלות היא "לא", ייתכן שבדיקה ידנית תהיה הבחירה הפשוטה יותר.

2. בדיקות חקרניות

Exploratory Testing נשען במידה רבה על חשיבה, ניסיון, סקרנות ושיקול דעת של הבודק.

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

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

3. בדיקות שמטרתן להעריך חוויית משתמש

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

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

4. בדיקות במערכת שמשתנה כל הזמן

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

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

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

5. בדיקות הדורשות שיקול דעת אנושי

יש בדיקות שבהן השאלה אינה רק "האם התוצאה שווה לערך X?", אלא "האם ההתנהגות הגיונית?"

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

הטעות הנפוצה: להפוך את כל בדיקות ה-UI לאוטומטיות

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

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

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

לכן חשוב לתכנן את האוטומציה כך שתהיה יציבה ככל האפשר ולהשתמש ב-Locators מתאימים.

מי שרוצה להבין את ההבדלים בין כלי האוטומציה המרכזיים יכול לעיין במאמר Playwright לעומת Cypress לעומת Selenium.

איך מחליטים אם בדיקה מתאימה לאוטומציה?

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

עלות האוטומציה מול התועלת

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

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

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

מה לגבי בדיקות SAP?

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

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

באתר יש גם סדרת תכנים בנושא בדיקות SAP, כולל בדיקות מערכות SAP וכן בדיקות S/4HANA לפני ואחרי מעבר.

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

אוטומציה אינה תחליף לבודק תוכנה

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

בפועל, אוטומציה ובדיקות ידניות משרתות מטרות שונות.

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

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

מה כדאי ללמוד כדי להתחיל באוטומציה?

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

1. הבנת יסודות בדיקות תוכנה.
2. היכרות עם Test Cases ו-Test Scenarios.
3. הבנת Regression, Smoke ו-Sanity.
4. יסודות HTML ו-CSS.
5. JavaScript או שפת תכנות אחרת.
6. עבודה עם כלי אוטומציה.
7. הבנת Selectors ו-Locators.
8. Assertions.
9. עבודה עם API.
10. היכרות עם Git ו-CI/CD.

למתחילים ב-Playwright, אפשר להיעזר במדריך 20 דברים שחשוב לדעת על Playwright למתחילים.

Playwright, Selenium או Cypress?

בחירת הכלי צריכה להגיע אחרי הבנת צרכי הפרויקט ולא לפניה.

Playwright, Selenium ו-Cypress הם כלים מוכרים לאוטומציית בדיקות, אבל לכל אחד מהם מאפיינים, ארכיטקטורה, יכולות ודרך עבודה שונות.

לכן לא נכון לבחור כלי רק משום שהוא פופולרי. כדאי לבדוק:

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

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

איך נראה שילוב נכון בין בדיקות ידניות ואוטומטיות?

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

חמש שאלות שכדאי לשאול לפני שמפתחים אוטומציה

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

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

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

הכלי עצמו אינו האסטרטגיה.

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

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

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

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

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

המטרה היא ליצור שילוב נכון בין בדיקות אוטומטיות ובדיקות ידניות.

כדאי לשקול אוטומציה במיוחד עבור:

• בדיקות שחוזרות על עצמן.
• בדיקות Regression.
• Smoke Tests.
• בדיקות API.
• תרחישים עסקיים קריטיים ויציבים.
• בדיקות עם נתונים רבים.
• בדיקות בעלות תוצאה חד-משמעית.

כדאי להיזהר מאוטומציה עבור:

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

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

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