בדיקות חקר. בודק מיומן וסקרן ימצא באגים שאף חבילת בדיקות אוטומטית לא תופסת. הוא מנסה שילובי קלט מוזרים. הוא קוטע תהליכים באמצע. הוא מתנהג כמו משתמש מבולבל, משתמש חסר סבלנות, ומשתמש שקורא את הממשק בשפה אחרת. אי אפשר לכתוב סקריפט לסקרנות.
אצלנו, בודקי החקר מקדישים 20% מכל ספרינט לחקירה בלי תסריט. ב-12 החודשים האחרונים, בדיקות חקר מצאו 35% מהבאגים בדרגת החומרה הגבוהה ביותר בכל הפרויקטים שלנו, וכל אחד מהם היה באג שחבילות האוטומציה פספסו.
חוויית המשתמש בפעם הראשונה. תהליך ה-Onboarding, הרכישה הראשונה, ההגדרה הראשונית. כאן צריך עיניים טריות. בדיקה אוטומטית מוודאת שהפונקציונליות עובדת. בודק ידני מוודא שמבינים אותה. "התהליך עובד?" היא שאלה לאוטומציה. "התהליך מובן למי שרואה אותו בפעם הראשונה?" היא שאלה לבודק.
נגישות עם טכנולוגיה מסייעת. סורקים אוטומטיים תופסים בעיות כמו טקסט חלופי חסר, ניגודיות צבע נמוכה ותוויות ARIA חסרות. הם מפספסים הרבה. כששירות הדיגיטל של ממשלת בריטניה בדק 10 כלים ב-2017 על דף עם 143 כשלי נגישות שהוטמנו בו בכוונה, הכלי הטוב ביותר מצא 41% מהם. ניווט עם קורא מסך, סדר המעבר בין רכיבים במקלדת והעומס הקוגניטיבי דורשים אדם שעובד עם טכנולוגיה מסייעת.
תהליכים שחוצים מוצרים. כשהמסע של המשתמש עובר בין כמה מוצרים או שירותים (מתחיל באפליקציית ה-Web, ממשיך במייל ומסתיים במובייל), צריך אדם שיבדוק את החיבור ביניהם. כל חלק לבד יכול לעבור את הבדיקות האוטומטיות, והחוויה המחוברת עדיין תיכשל.
האמצע ש-AI הזיז
עד 2025 הקטגוריות האלה היו ידניות לגמרי. סוכני בדיקות AI הופכים אותן לאוטומטיות, לפחות בחלקן:
[רגרסיה](/he/blog/fix-slow-regression-testing) ויזואלית. סוכני AI משווים צילומי מסך בין גרסאות ומסמנים שינויים ויזואליים שלא תוכננו. כלים כמו Applitools ו-Percy עושים את זה טוב. מה שה-AI עדיין מפספס: האם שינוי ויזואלי הוא שיפור או נסיגה. הוא תופס הבדלים, ובני אדם שופטים את הכוונה.
בדיקות בין דפדפנים. סוכני AI מריצים היום את אותה חבילת בדיקות על יותר מ-20 שילובים של דפדפן ומכשיר במקביל, ומזהים הבדלי תצוגה אוטומטית. מה שה-AI מפספס: דפוסי אינטראקציה של דפדפן מסוים, שמשתמשים באמת שמים לב אליהם.
מדד בסיס לביצועים. סוכני AI קובעים מדד בסיס לביצועים ומתריעים כשזמני התגובה חורגים ממנו. הם טובים בזיהוי נסיגות, וחלשים באבחון הסיבה. האטה של 200ms ב-API של החיפוש יכולה להיות אינדקס חסר במסד הנתונים, Cache Miss או בעיית תשתית. הסוכן מסמן, ואדם חוקר.
כתיבת מקרי בדיקה מתוך הדרישות. תנו לסוכן AI User Story, והוא יכתוב 80 עד 120 מקרי בדיקה: מסלולים תקינים, מקרי קצה ותנאי גבול. אדם צריך לעבור על הבדיקות האלה. בערך 70% מהן שימושיות, 20% כפולות ו-10% בודקות את הדבר הלא נכון. ועדיין, להתחיל עם 70% בדיקות שימושיות עדיף בהרבה על דף ריק.
ארבע שאלות לכל בדיקה
על כל בדיקה, עברו על השאלות האלה:
1. הבדיקה משתנה בין הרצה להרצה? אם לא (אותו קלט, אותה תוצאה צפויה, בכל פעם): אוטומציה. אם כן (קריטריונים אחרים בכל פעם): ידני.
2. הבדיקה דורשת שיפוט של איכות? אם היא בינארית (עבר או נכשל לפי תוצאה צפויה): אוטומציה. אם היא דורשת דעה (זה מרגיש נכון? זה מבלבל?): ידני.
3. באיזו תדירות הבדיקה רצה? אם כל יום או על כל Commit, היא חייבת להיות אוטומטית. אם פעם בחודש או פעם בגרסה, שקלו בדיקה ידנית, בתנאי שהיא דורשת הרבה שיקול דעת.
4. כמה עולה באג שהבדיקה מפספסת? אם יותר מ-30,000 ש״ח: אוטומציה, ובנוסף בדיקות חקר ידניות על אותו אזור. אם פחות מ-3,000 ש״ח: אוטומציה לבד מספיקה.
כמה זה עולה בפועל
כך נראית בדרך כלל עלות הבדיקות ביחסי אוטומציה שונים, לפי הערכות התכנון שלנו:
| שיעור האוטומציה | עלות חודשית (צוות של 20 מפתחים) | שיעור הדליפה ל-Production | מהירות הגילוי |
|---|
| 0% (הכול ידני) | 55,000 עד 78,000 ש״ח | 25% עד 35% | 3 עד 5 ימים |
| 30% | 45,000 עד 60,000 ש״ח | 18% עד 25% | יום עד 3 ימים |
| 60% | 37,000 עד 50,000 ש״ח | 10% עד 15% | 4 עד 24 שעות |
| 80% | 40,000 עד 55,000 ש״ח | 8% עד 12% | שעה עד 4 שעות |
| 95% ומעלה | 50,000 עד 68,000 ש״ח | 10% עד 15% | דקות |
שימו לב לעלייה ב-95% ומעלה. 15% עד 20% האחרונים של האוטומציה הם היקרים ביותר לבנייה ולתחזוקה. אתם הופכים לאוטומטיים תרחישים מורכבים שמשתנים לעתים קרובות, דורשים השוואה ויזואלית מתוחכמת ונשברים מספיק פעמים כדי שהתחזוקה תאכל את החיסכון.
הנקודה האופטימלית לרוב הצוותים: 60% עד 70% אוטומציה. שם כל שקל שאתם משקיעים קונה את השיפור הגדול ביותר בגילוי באגים.
למה בדיקות ידניות בלבד לא גדלות עם המוצר
הבדיקות הידניות גדלות יחד עם הפיצ׳רים. אפליקציה חדשה עם 50 מקרי בדיקה צריכה בודק אחד ליום אחד בכל גרסה. שנה אחר כך, 300 מקרי בדיקה דורשים שלושה בודקים לשבוע, ואנשים עייפים מפספסים דברים. חבילות אוטומטיות לא גדלות ככה.
הנה חישוב שעשינו ללקוח ארגוני בינוני, עם 400 מקרי בדיקה וגרסה כל שבועיים:
| ידני | אוטומטי |
|---|
| הקמה | אין | 370,000 ש״ח לתשתית ולבדיקות הראשונות |
| עלות שוטפת | 3 מהנדסי QA, כל אחד ב-18,500 ש״ח בחודש, ועוד כ-12,500 ש״ח בחודש על באגים שדלפו | מהנדס אוטומציה אחד ב-23,000 ש״ח בחודש |
| שנה ראשונה | 830,000 ש״ח | 650,000 ש״ח |
| שנה שנייה ושלישית | 830,000 ש״ח כל אחת | 280,000 ש״ח כל אחת |
| סה״כ לשלוש שנים | 2.5 מיליון ש״ח | 1.2 מיליון ש״ח |
בשלוש שנים האוטומציה עלתה 52% פחות, והפער גדל בכל שנה.
איפה להשקיע את מאמץ האוטומציה
עבדו לפי פירמידת הבדיקות:
- בדיקות יחידה, כ-70% מהמאמץ. מהירות וזולות, ותופסות באגים מוקדם. כל פונקציה עם לוגיקה עסקית צריכה אותן.
- בדיקות API ואינטגרציה, כ-20%. הן תופסות את מה שבדיקות יחידה מפספסות: פורמט נתונים שגוי, נקודות קצה שהוגדרו לא נכון ותהליכי הזדהות שבורים.
- בדיקות UI ו-End-to-End, כ-10%. הכי יקרות לכתיבה ולתחזוקה. הגבילו אותן לתהליכים הקריטיים, כמו התחברות, תשלום ותהליכי הליבה.
שתי טעויות מפילות את רוב תוכניות האוטומציה. הראשונה היא אוטומציה של הכול בבת אחת: צוות כותב 500 בדיקות בחודש, ואז לא מצליח לתחזק אותן. התחילו עם 50 בדיקות קריטיות, והוסיפו 10 עד 20 בכל ספרינט. השנייה היא בעלות משותפת. כשכולם אחראים לבדיקות, אף אחד לא אחראי. מנו בעלים אחד לאוטומציה.
מ-0% ל-60% אוטומציה ב-90 יום
ימים 1 עד 14: התשתית
הקימו Framework לבדיקות (אנחנו ממליצים על Playwright ל-Web, ועל Detox או Appium למובייל) וחברו אותו ל-Pipeline של ה-CI/CD. כתבו בדיקות Smoke לחמשת תהליכי המשתמש הקריטיים ביותר. ביום ה-14, כל Commit כבר מפעיל את הבדיקות האלה אוטומטית.
ימים 15 עד 45: אוטומציה של הליבה
הפכו לאוטומטיות את בדיקות הרגרסיה של 20 הפיצ׳רים החשובים ביותר שלכם. התמקדו בפיצ׳רים שמשתנים הכי פחות (הם ייתנו את הבדיקות האוטומטיות היציבות ביותר) ושהכי כואב כשהם נשברים (שם הבדיקות יחזירו הכי הרבה).
ימים 45 עד 75: שכבת ה-API והנתונים
הוסיפו בדיקות חוזה לכל נקודות הקצה הציבוריות של ה-API, ובדיקות אימות לכל תהליך נתונים. הבדיקות האלה זולות לכתיבה, רצות מהר ותופסות קטגוריות שלמות של באגים.
ימים 75 עד 90: כיוונון ונוהל לבדיקות הידניות
בדקו אילו בדיקות אוטומטיות לא יציבות, ותקנו או מחקו אותן. קבעו קצב מסודר לבדיקות חקר: 20% מכל ספרינט, עם דגש על אזורים שהשתנו לאחרונה. הכשירו את הבודקים הידניים לתחומים החדשים, הקטגוריות ש-AI הזיז, שבהן הם צריכים להפעיל שיקול דעת במקום לבצע בדיקות שגרתיות.
שאלות נפוצות
אפשר להפוך הכול לאוטומטי ולוותר על בדיקות ידניות?
טכנית כן, בפועל לא. אוטומציה מלאה מפספסת קטגוריות שלמות של באגים: בעיות שמישות, בעיות נגישות עם טכנולוגיה מסייעת, ולוגיקה עסקית שנכונה טכנית אבל לא עונה על מה שהמשתמשים מצפים. צוותים שמנסים להגיע ל-100% אוטומציה רואים בדרך כלל עלייה בשיעור הדליפה, בדיוק מהסיבות האלה.
באיזה Framework לאוטומציה כדאי להשתמש?
ל-Web: Playwright. הוא מהיר יותר מ-Selenium, יציב יותר מ-Cypress בהיקפים גדולים ותומך בכמה דפדפנים מהקופסה. למובייל: Detox ל-React Native, XCUITest ל-iOS נייטיב ו-Espresso ל-Android נייטיב. ל-API: שילוב של Jest או Vitest עם Pact לבדיקות חוזה.
מה עושים עם בדיקות לא יציבות (Flaky)?
מכניסים אותן להסגר. העבירו אותן לחבילה נפרדת שרצה, אבל לא חוסמת פריסות. הקצו מהנדס אחד בכל ספרינט לחקור ולתקן את הבדיקות שבהסגר. בדיקה שלא יציבה כבר יותר מ-3 ספרינטים: מחקו אותה וכתבו אותה מחדש. בדיקות לא יציבות שוחקות את האמון בכל החבילה.
מתי המוצר מוקדם מדי לאוטומציה?
כשאתם עדיין מחפשים Product-Market Fit והממשק משתנה כל שבוע. התחילו באוטומציה כשתהליכי הליבה מתייצבים, בדרך כלל אחרי ה-MVP.
אין לנו אף בדיקה אוטומטית. מאיפה מתחילים?
התחילו ב-5 בדיקות Smoke לתהליכים הקריטיים ביותר: התחברות, טעינת הדף הראשי, הפעולה המרכזית, תשלום אם יש, ושליחת נתונים. הריצו אותן על כל Commit. זה לוקח למהנדס אחד בערך שבוע, ומהיום הראשון זה תופס את הבאגים שעושים את הנזק הגדול ביותר. צריכים עזרה להתחיל? עשינו את זה עם צוותים בכל גודל.
