- העמוד הראשי נטען בלי שגיאות
- הפעולה המרכזית של המשתמש מסתיימת (הוספה לעגלה, שליחת טופס, שליחת הודעה)
- תהליך התשלום או החיוב עובד (אם יש כזה)
- נתונים שנשלחים נשמרים, ואפשר לשלוף אותם
בחירת הכלי: Playwright ל-Web. הוא תומך בכמה דפדפנים, מהיר יותר מ-Selenium ונוח יותר לדיבאג. אל תשקיעו בהחלטה הזו יותר מיום.
ההשפעה: חמש הבדיקות האלה יתפסו את הבאגים המביכים ביותר: משתמשים רשומים שלא מצליחים להתחבר, עמוד תשלום שקורס. כל תקלה כזו שלא מגיעה ל-Production חוסכת 4 עד 8 שעות של כיבוי שריפות.
שבועות 3 ו-4: סדר בטיפול בבאגים
בצוות בלי QA, הבאגים מפוזרים בין הודעות ב-Slack, טיקטים ב-Jira בלי רמת חומרה, ופתקים בראש של המפתחים, שנעלמים ברגע שהם עוברים למשימה אחרת.
מה מקימים:
- Backlog אחד לבאגים, נפרד מה-Backlog של הפיצ׳רים
- סיווג חומרה: קריטי (חוסם הכנסות או משתמשים), גבוה (פגיעה משמעותית בחוויה), בינוני (יש דרך לעקוף), נמוך (קוסמטי)
- ישיבת Triage של רבע שעה, שלוש פעמים בשבוע, בחודש הראשון
- כלל אחד: באג קריטי מתוקן לפני שפיצ׳ר חדש עולה
זה נשמע בסיסי, וזה באמת בסיסי. אבל בצוותים בלי QA מסודר בדרך כלל אין כאן שום תהליך, והבאגים מצטברים עד שמשבר מכריח לטפל בהם.
ימים 31 עד 60: תשתית האוטומציה
שבועות 5 ו-6: ארכיטקטורת הבדיקות
פירמידת הבדיקות עדיין עובדת, אבל היחסים השתנו. זה מה שאנחנו ממליצים לצוותים שמתחילים מאפס:
| שכבה | מה היא בודקת | חלק מכלל הבדיקות | כלים |
|---|
| Unit | פונקציות ומודולים בודדים | 60% | Jest/Vitest |
| Integration | חוזי API, שאילתות למסד הנתונים, תקשורת בין שירותים | 25% | Supertest, Pact |
| E2E | תהליכי משתמש קריטיים מקצה לקצה | 15% | Playwright |
אל תהפכו את הפירמידה. צוותים בלי ניסיון ב-QA כותבים הרבה פעמים קודם בדיקות E2E, כי הן אינטואיטיביות. אבל בדיקות E2E איטיות, שבירות ויקרות לתחזוקה. התחילו מבדיקות Unit ו-Integration: הן מהירות ויציבות יותר, ותופסות באגים מוקדם יותר.
שבוע 7: חיבור ל-CI/CD
על בדיקה שמריצים ידנית מדלגים בסוף. בדיקה שמחוברת ל-CI/CD רצה כל פעם.
שלבי ה-Pipeline:
1. לפני Commit: Linting ובדיקת טיפוסים (מהיר, חוסם את ה-Commit)
2. בדיקת PR: בדיקות Unit ו-Integration (פחות מ-5 דקות, חוסם Merge)
3. אחרי Merge: כל חבילת ה-E2E (פחות מ-15 דקות, חוסם פריסה)
4. אחרי פריסה: בדיקות Smoke ב-Production (פחות מ-2 דקות, מפעיל Rollback)
הקימו את השערים האלה גם אם יש לכם רק את 5 בדיקות ה-Smoke משבוע 2. התשתית קיימת כדי שכל בדיקה חדשה שתכתבו תרוץ אוטומטית בשלב הנכון.
שבוע 8: משימה לא גמורה בלי בדיקות
עדכנו את ה-Definition of Done של משימות הפיתוח. כל טיקט של פיצ׳ר צריך לכלול:
- בדיקות Unit לפונקציות חדשות
- בדיקת Integration לכל Endpoint חדש ב-API
- עדכון של בדיקות E2E קיימות, אם תהליך המשתמש השתנה
- בדיקה בשני דפדפנים לפחות (Chrome ועוד אחד)
- בדיקת נגישות לרכיבי UI חדשים
בנקודה הזו ה-QA מפסיק להיות פעילות נפרדת, והופך לחלק מדרך העבודה של הצוות.
ימים 61 עד 90: הרחבה ומדידה
שבועות 9 ו-10: כיסוי לפי סיכון
אל תרדפו אחרי כיסוי של 100%. רדפו אחרי כיסוי של אזורי הסיכון. חזרו להערכה משבוע 1, זהו אילו חלקים בקוד גורמים להכי הרבה תקלות ב-Production, ותנו להם עדיפות בכיסוי.
יעדי כיסוי ליום ה-90:
- תהליכי משתמש קריטיים: 90% ויותר מכוסים בבדיקות E2E
- לוגיקה עסקית מרכזית: 80% ויותר כיסוי בבדיקות Unit
- חוזי API: לכל Endpoint ציבורי יש בדיקת חוזה
- כיסוי קוד כולל: 60%, כרצפה ולא כיעד
המספרים האלה מבוססים על מה שאנחנו רואים ב-Globalbit בפרויקטים מוצלחים של בניית QA. צוותים שמכוונים ל-60% כיסוי כולל ביום ה-90 ומעמיקים בתהליכים הקריטיים לעסק תופסים יותר באגים מצוותים שמכוונים ל-80% כיסוי כולל, מפוזר באופן שווה.
שבוע 11: מדדי QA
עקבו אחרי המדדים האלה, ודווחו עליהם בכל ספרינט.
| מדד | יעד ליום ה-90 | למה זה חשוב |
|---|
| שיעור הדליפה ל-Production (Defect Escape Rate) | פחות מ-15% | איזה חלק מהבאגים מגיע ל-Production במקום להיתפס בבדיקות |
| זמן עד גילוי | פחות משעה | כמה מהר מגלים באג אחרי פריסה |
| זמן הרצת הבדיקות | פחות מ-15 דקות | על בדיקות ארוכות יותר מדלגים, או שצריך להריץ אותן במקביל |
| שיעור הבדיקות הלא יציבות (Flaky) | פחות מ-5% | בדיקות לא יציבות שוחקות את האמון בכל החבילה |
| תדירות הפריסות | לא יורדת | QA לא אמור להאט את השחרורים |
שבוע 12: העברת ידע ותיעוד
בין שהתחלתם במיקור חוץ ובין שבניתם בבית, את שבוע 12 מקדישים לתיעוד של מה שבניתם:
- מסמך אסטרטגיית בדיקות (עמוד או שניים)
- Runbook לתקלות נפוצות
- נוהל כוננות QA לתקלות ב-Production
- מדריך קליטה לאנשי צוות חדשים
התיעוד הזה שומר על ה-QA גם כשאנשים מתחלפים. התהליך כתוב במסמכים, והוא לא תלוי בזיכרון של אדם אחד.
הטעויות הנפוצות ב-90 הימים הראשונים
להתחיל מהכלי הלא נכון: צוותים מבזבזים שבועיים על השוואת Frameworks, כשהיו יכולים כבר לכתוב את הבדיקה הראשונה. קחו Playwright ל-Web ו-Jest/Vitest לבדיקות Unit, והמשיכו הלאה.
לנסות לבדוק הכול בבת אחת: היעד ליום ה-90 הוא תהליך עובד, שתופס אוטומטית את הבאגים המזיקים ביותר. כיסוי מקיף יבוא אחר כך. עומק לפני רוחב.
להפוך את ה-QA למחסום: אם המפתחים רואים ב-QA את הצוות שחוסם להם PR-ים, נכשלתם. QA צריך להקל על החיים של המפתחים, ולתפוס את הבאגים לפני שהכונן יתפוס אותם ב-2 בלילה.
לשכוח את המובייל: אם יש לכם אפליקציית מובייל, תכניסו בדיקות מובייל מהיום הראשון, על מכשירים אמיתיים. בדיקות בדפדפן ובדיקות מובייל הן שני תחומים שונים, ותקצבו את שניהם. צוות ה-QA שלנו בודק על יותר מ-130 מכשירים אמיתיים, ולחצי מהצוות יש הסמכת ISTQB ברמת Foundation או Advanced.
לא למדוד: בלי מדדים לא תוכלו להוכיח שההשקעה ב-QA עובדת. עקבו אחרי שיעור הדליפה ל-Production מהיום הראשון. זה המדד החשוב ביותר.
שאלות נפוצות
את מי לגייס ראשון: בודק ידני או מהנדס אוטומציה?
מהנדס אוטומציה עם ניסיון בבדיקות ידניות. אתם צריכים מישהו שכותב קוד, מחבר את הבדיקות ל-CI/CD, וגם יודע לחקור את המוצר ידנית כשצריך. בשלב הראשון התפקיד ההיברידי שווה יותר מכל אחת מההתמחויות לבד.
כמה עולה QA בשנה הראשונה?
בסטארטאפ ישראלי: בין 400,000 ל-600,000 ש״ח למהנדס QA בכיר אחד (כולל עלות מעביד), ועוד בין 50,000 ל-100,000 ש״ח לכלים ולתשתית. ב-QA במיקור חוץ: בין 15,000 ל-30,000 ש״ח בחודש למהנדס ייעודי, עם גישה לצוות רחב יותר. אנחנו עובדים בשני המודלים. דברו איתנו ונבדוק מה מתאים לכם.
המפתחים לא יכולים לכתוב את הבדיקות בעצמם, בלי לגייס QA?
את בדיקות ה-Unit הם יכולים לכתוב, וגם צריכים. אבל מפתח שבודק את הקוד של עצמו הוא כמו כותב שמגיה את המאמר של עצמו: הוא קרוב מדי כדי לראות את הטעויות. אנשי QA באים עם הראש של מי שמנסה לשבור, ולמפתחים הוא בדרך כלל חסר. המבנה הטוב ביותר: המפתחים כותבים בדיקות Unit, וה-QA אחראי על Integration, E2E ובדיקות חקר.
ומה אם עוד לא הגענו ל-Product-Market Fit, והמוצר משתנה בכל ספרינט?
התמקדו בשכבת ה-Smoke (5 עד 10 בדיקות על התהליכים היציבים ביותר) ובבדיקות חקר. אין טעם להשקיע הרבה באוטומציה במוצר שעוד עשוי לעשות פיבוט. כשתגיעו ל-PMF והתהליכים יתייצבו, השקיעו בתוכנית המלאה של 90 יום. עזרנו לסטארטאפים לפני PMF לאזן בין מהירות לאיכות. בואו נדבר.
