שבוע 2: אסטרטגיה ותכנון
מה קורה
על סמך ממצאי הסקר, צוות ה-QA מתכנן את אסטרטגיית הבדיקות:
- ארכיטקטורת הבדיקות: איזה יחס בין בדיקות Unit, Integration ו-E2E נכון למוצר שלכם
- בחירת כלים: לפי הטכנולוגיות שלכם, ולא לפי ההעדפה של הספק. באפליקציית Web טיפוסית: Playwright ל-E2E, Jest/Vitest ל-Unit ו-Pact לבדיקות חוזה.
- Backlog לפי עדיפות: 20 עד 30 מקרי הבדיקה הראשונים, מדורגים לפי כיסוי הסיכון, ומתחילים מהתהליכים עם ההשפעה הגבוהה ביותר
- תוכנית חיבור ל-CI/CD: איך הבדיקות נכנסות ל-Pipeline הקיים, עם הגדרה מדויקת של כל שער
- נוהל תקשורת: Standup יומי? דוח שבועי? באיזה ערוץ ב-Slack? איך מדווחים על באגים ואיך עוקבים אחריהם.
מה אתם מקבלים
מסמך אסטרטגיית QA, מסמך חי שמתעדכן לאורך הפרויקט:
- תרשים של ארכיטקטורת הבדיקות
- Backlog בדיקות לפי עדיפות, עם הערכת כיסוי לכל שבוע
- תוכנית חיבור ל-CI/CD עם לוח זמנים
- נהלי תקשורת והסלמה
- יעדי KPI לחודש 1, לחודש 3 ולחודש 6
מה אתם צריכים לאשר
לפני שמתחיל שבוע 3, עברו על הדברים האלה ואשרו אותם:
1. בחירת הכלים (ודאו שהם מתאימים ליכולות של הצוות שלכם)
2. סדר העדיפויות של כיסוי הבדיקות
3. תדירות התקשורת והפורמט שלה
4. הגדרות השערים ב-CI/CD (מה חוסם פריסה ומה רק מדווח)
שבועות 3 ו-4: בניית התשתית
מה קורה
צוות ה-QA מתחיל לבנות את תשתית הבדיקות ולכתוב את הבדיקות הראשונות:
- הקמת סביבות: סביבות בדיקה, שינויים ב-Pipeline של ה-CI/CD, ניהול נתוני בדיקה
- בדיקות Smoke ראשונות: 5 עד 10 בדיקות אוטומטיות לתהליכי המשתמש הקריטיים ביותר
- חיבור ל-Pipeline: בדיקות ה-Smoke רצות על כל PR, וחוסמות Merge כשהן נכשלות
- סבב בדיקות ידני ראשון: בדיקות חקר של התהליכים המרכזיים במוצר, ותיעוד הבאגים במערכת המעקב שלכם
מה מקבלים בכל שבוע
- דוח הרצה: מה נבדק, מה עבר, מה נכשל
- דיווחי באגים במערכת המעקב שלכם (Jira, Linear וכו׳)
- הדגמה של בדיקות אוטומטיות שרצות ב-CI/CD
- מדדי כיסוי מעודכנים
מה אתם אמורים לראות בסוף שבוע 4
- 5 עד 10 בדיקות Smoke אוטומטיות שרצות על כל Commit
- שער CI/CD ראשון פעיל (הבדיקות חוסמות Merge)
- 10 עד 20 באגים שנפתחו מבדיקות חקר, מסווגים לפי חומרה
- הצוות זמין ועונה בערוץ ה-Slack או ה-Teams שלכם בשעות העבודה הרגילות
נורות אדומות בשלב הזה
- אחרי 4 שבועות עדיין אין אף בדיקה אוטומטית שרצה
- באגים נפתחים בלי צעדי שחזור ברורים או בלי רמת חומרה
- פערי תקשורת: אתם צריכים לבקש עדכונים, במקום לקבל אותם
- הצוות משתמש בכלים שלא אישרתם במסמך האסטרטגיה
שבועות 5 עד 8: הרחבת הכיסוי
מה קורה
זה השלב עם הקצב הכי גבוה. צוות ה-QA מרחיב את הכיסוי, ובמקביל ממשיך בבדיקות חקר שוטפות:
- הרחבת האוטומציה: מ-10 בדיקות ל-50 עד 100, שמכסות נתיבי רגרסיה, חוזי API ונקודות אינטגרציה
- רגרסיה ויזואלית: השוואה אוטומטית של צילומי מסך בעמודים ובגדלי המסך המרכזיים
- מדד בסיס לביצועים: בדיקת עומס ראשונה, שקובעת מדד בסיס לזמני תגובה ולתפוקה
- חלק מהספרינט: צוות ה-QA משתתף בישיבות הספרינט, בודק שאפשר לבדוק כל Story, וכותב מקרי בדיקה כבר בתכנון הספרינט (ולא אחרי שהפיתוח נגמר)
המדדים הטיפוסיים בשבוע 8
| מדד | יעד | למה זה חשוב |
|---|
| מספר בדיקות אוטומטיות | 50 עד 100 | כיסוי של הנתיבים הקריטיים |
| זמן הרצת בדיקות | פחות מ-15 דקות | מהיר מספיק כדי לא לחסום פריסות |
| קצב גילוי באגים | 15 עד 25 באגים בשבוע | בדיקות חקר ואוטומציה פעילות |
| שיעור הדליפה ל-Production (Defect Escape Rate) | פחות מ-20% | רוב הבאגים נתפסים לפני Production |
| שערי CI/CD פעילים | כן, בכל השלבים | אכיפת איכות אוטומטית |
מה אתם צריכים לעשות
זה הזמן להתחיל לבדוק אם הפרויקט עובד:
- התקלות ב-Production יורדות?
- קצב הפיתוח של הצוות נשמר או השתפר? (QA לא אמור להאט את הפיתוח)
- דיווחי הבאגים שימושיים, ואפשר לפעול לפיהם?
- התקשורת עומדת בציפיות שלכם?
חודשים 3 עד 6: הבשלה ואופטימיזציה
מה קורה
הפרויקט עובר מבנייה לשיפור:
- אופטימיזציה של חבילת הבדיקות: הסרת בדיקות לא יציבות, זמני ריצה קצרים יותר, בחירת בדיקות לפי סיכון
- בדיקות מתקדמות: אבטחה, נגישות ובדיקות על מכשירי מובייל, לפי מה שהמוצר צריך
- שילוב AI: כלי בדיקות AI במקומות שבהם הם מוסיפים ערך (רגרסיה ויזואלית, יצירת בדיקות, API Fuzzing)
- מפגשי העברת ידע: מלמדים את הצוות הפנימי שלכם לתחזק ולהרחיב את חבילת הבדיקות
- חידוד התהליך: מעדכנים את אסטרטגיית הבדיקות לפי 3 חודשים של נתונים על המקומות שמהם הבאגים באמת מגיעים
דוח חודשי
מהחודש השלישי תקבלו דוח QA חודשי, שכולל:
- סטטיסטיקת באגים: כמה נמצאו, כמה תוקנו, כמה דלפו ל-Production
- מגמות בכיסוי הבדיקות
- מדדי ביצועים של ה-Pipeline
- המלצות לחודש הבא
- חישוב ROI: עלות הבאגים שנמנעו, מול עלות הפרויקט
השיחה על ההמשך
בסביבות החודש הרביעי או החמישי, רוב הלקוחות בוחרים באחת משלוש דרכים:
דרך א׳: ממשיכים במיקור חוץ (40% מהלקוחות). הפרויקט עובד, העלות נמוכה מגיוס, והצוות רוצה להמשיך במודל הקיים.
דרך ב׳: מודל היברידי (35% מהלקוחות). מגייסים איש QA פנימי אחד או שניים, ומצמצמים את היקף מיקור החוץ. השותף אחראי על הבדיקות המיוחדות (אבטחה, ביצועים, מכשירי מובייל), והצוות הפנימי על הרגרסיה השוטפת ועל העבודה בתוך הספרינט.
דרך ג׳: מעבר מלא פנימה (25% מהלקוחות). הצוות החיצוני בנה את תשתית הבדיקות, הקים את התהליך ותיעד הכול. הלקוח מגייס צוות פנימי, והשותף מעביר אליו את העבודה בצורה מסודרת לאורך 4 עד 6 שבועות.
שלוש הדרכים לגיטימיות. הבחירה הנכונה תלויה במורכבות המוצר, בשוק הגיוס ובתקציב.
כמה זה עולה
מחירים שקופים, כי ממילא תגלו אותם:
| מודל | עלות חודשית (שוק ישראלי) | מה כלול |
|---|
| מהנדס ייעודי אחד | בין 15,000 ל-25,000 ש״ח | איש QA אחד, 8 שעות ביום, עבודה מלאה בתוך הספרינט |
| צוות של 2 עד 3 אנשים | בין 30,000 ל-60,000 ש״ח | ראש צוות QA ומהנדסים, אסטרטגיה וביצוע, כיסוי רחב יותר |
| פרויקט מוגדר | מ-40,000 ש״ח, ויכול להגיע ל-80,000 ש״ח | היקף קבוע, תוצרים מוגדרים ולוח זמנים סגור (למשל QA לפני השקה) |
אלה הטווחים של Globalbit, ומחירי השוק משתנים. לצורך השוואה: מהנדס QA בכיר שמגייסים בישראל עולה בין 25,000 ל-40,000 ש״ח בחודש בעלות מעביד מלאה, ועוד חודשיים או שלושה של גיוס וקליטה.
איך יודעים שזה עובד
שלושת המדדים שחשובים
אחרי 90 יום, שלושה מספרים מספרים לכם הכול:
- שיעור הדליפה ל-Production: איזה אחוז מהבאגים מגיע ל-Production? הוא צריך להיות מתחת ל-15%, ובמגמת ירידה.
- זמן עד גילוי: כמה זמן אחרי פריסה מתגלים באגים? בתקלות קריטיות, פחות משעה.
- קצב הפיתוח: הצוות משחרר באותו קצב או מהר יותר? אם ה-QA מאט את הפיתוח, משהו לא עובד.
השיחה שצריך לנהל ביום ה-90
בקשו משותף ה-QA: "תראו לי את קווי המגמה." אם שיעור הדליפה לא זז, משהו לא עובד. אם הוא יורד לאט, זה יכול להיות בסדר, תלוי מאיפה התחלתם. אם הוא צנח בחודש השני והתייצב, זה סימן בריא.
שאלות נפוצות
ומה אם צוות ה-QA שקיבלנו לא מתאים לנו?
שותף טוב מחליף אנשים כשההתאמה לא עובדת. אם יש בעיה, זה צריך לקרות בשבועיים הראשונים. אם אתם צריכים לבקש יותר מפעם אחת, תחשבו מחדש על השותף.
אפשר להתחיל בפיילוט, לפני פרויקט מלא?
כן. פיילוט נפוץ: מוציאים למיקור חוץ את ה-QA של מוצר אחד או של תחום פיצ׳רים אחד, לחודשיים או שלושה. מודדים את התוצאות, ומרחיבים אם זה עובד. זה מקטין את הסיכון, ונותן לשני הצדדים לבדוק את ההתאמה.
איך מגינים על הקניין הרוחני שלנו מול צוות QA חיצוני?
NDA סטנדרטי, גישה לקוד רק במידה הנדרשת, ושיטות פיתוח מאובטחות. לכל שותף QA רציני זה כבר קיים. אם הוא לא מעלה את הנושא בעצמו, זו נורה אדומה.
כמה זמן נמשך פרויקט כזה בדרך כלל?
6 עד 12 חודשים בהתקשרות הראשונה. רוב הלקוחות שממשיכים אחרי החודש השלישי נשארים לפחות שנה. ה-ROI משתפר עם הזמן, כי הצוות מכיר את המוצר לעומק ותשתית הבדיקות מתבגרת. רוצים לראות איך זה ייראה אצלכם? בואו נדבר.
