צוותי enterprise כמעט אף פעם לא נכשלים במעבר מ-Selenium ל-Playwright כי Playwright חלש. הם נכשלים כי הם מתייחסים למעבר כאל rewrite במקום כאל שינוי operating model.
זו טעות יקרה.
מיגרציה אמיתית משנה ארבע מערכות בבת אחת:
- runtime של הבדיקות.
- feedback loop של CI/CD.
- מודל ownership בין QA ל-development.
- הדרך שבה AI יכול להאיץ עבודה בלי לקבל סמכות מסוכנת.
אם מתייחסים לכל זה כ-framework swap, מקבלים repository יפה ו-pipeline שבור.
הפתרון שלי נקרא דוקטרינת הטטריס.
אשליית היציבות בביצת ה-legacy
ארגונים רבים מתארים את Selenium stack הישן כך:
“הוא איטי, שביר ואף אחד לא אוהב לגעת בו, אבל לפחות הוא יציב.”
בדרך כלל זו לא יציבות. זו שבירות נסבלת.
הדפוס חוזר:
- צוואר בקבוק ב-CI: feedback מגיע מאוחר מדי כדי לשנות התנהגות מפתחים.
- QA silo: קוד הבדיקות נכתב בשפה, סגנון ו-ownership שונים מה-product code.
- מס תחזוקה: יותר זמן הולך לתיקון אוטומציה מאשר ללמידה ממנה.
- AI blind spot: תהליכי triage, generation ו-RCA עובדים טוב יותר כאשר stack הוא typed, observable וידידותי לאוטומציה.
Selenium legacy שמחובר לארגון product TypeScript הוא לא רק mismatch טכנולוגי. הוא mismatch תרבותי.
Playwright עוזר כי הוא מקצר את הלולאה: traces טובים יותר, defaults חזקים יותר, ergonomics מודרני, וחיבור טבעי לעולם TypeScript. אבל framework לבד לא פותר מיגרציה. Governance כן.
מוקש המיגרציה
כאשר הנהלה מאשרת מעבר, צוותים נופלים בדרך כלל לאחת משלוש אסטרטגיות רעות.
| אסטרטגיה | למה היא מפתה | מה קורה בפועל |
|---|---|---|
| Big Bang Rewrite | סיפור נקי ומסלול אחד | coverage נעלם לחודשים |
| Parallel Maintenance | legacy ממשיך להגן | הצוות מתחזק שתי מערכות ולא מסיים אף אחת |
| Lift and Shift | קל להעריך כי זה נראה תרגום | מעתיקים בדיקות ישנות לכלי חדש |
| Tetris Doctrine | פחות נוצץ, יותר ממושמע | מודול עסקי שלם עובר, מתייצב ונמחק מהlegacy |
Big Bang הוא לרוב פנטזיית הנהלה. Parallel Maintenance שורף את הארכיטקט. Lift and Shift מעביר זבל מהר יותר.
דוקטרינת הטטריס דוחה את שלושתם.
מהי דוקטרינת הטטריס
הרעיון פשוט להסבר וקשה לביצוע:
מהגרים מודול עסקי שלם אחד בכל פעם, מוכיחים ערך, ואז מנקים את השורה לפני שממשיכים.
לא 10% login, 10% checkout ו-10% billing.
מודול אחד. End to end. גמור.
כל בלוק migration כולל:
- Playwright flows עבור הדומיין.
- data setup ו-fixtures דטרמיניסטיים.
- CI path ודיווח שמייצרים failures שימושיים.
- ownership ברור.
- תוכנית retirement ל-Selenium המקביל.
ה-legacy suite אינו נכס קדוש. הוא perimeter מצטמצם. התפקיד שלו הוא להגן על חלקי המוצר שעדיין לא עברו מודרניזציה.
בחירת ה-beachhead הראשון
לא תמיד מתחילים במודול הכי קל. מתחילים במודול שהוא חשוב מספיק כדי לייצר ROI, מורכב מספיק כדי להוכיח ארכיטקטורה, ומוגבל מספיק כדי לסיים.
מועמדים טובים:
- checkout או subscription billing.
- onboarding עם authentication ו-setup.
- workflow אדמין עם השפעה על revenue או compliance.
מועמדים גרועים:
- טופס marketing זניח.
- מודול בלי owner.
- דומיין שנמצא בעיצוב מחדש כאוטי.
שאלת המפתח היא לא “מה קל?”. השאלה היא “איזה בלוק יוכיח שהמיגרציה אמיתית?”
לבנות foundation לפני Module One
אחת הסיבות שמיגרציות נתקעות היא שהצוות מתחיל להמיר בדיקות לפני שתוכננה המערכת שבה הן יחיו.
לפני המודול הראשון צריכים להיות:
- conventions ל-repository.
- אסטרטגיית data setup.
- trace ו-artifact policy.
- PR quality gate.
- reporting ו-ownership.
- סטנדרט code review.
זה לא החלק הנוצץ. אבל זה מה שהופך את המודול הראשון לאמין. בלי foundation, הצוות יציג ריצה ירוקה אחת ואז יבזבז שישה שבועות על flakiness.
AI הוא accelerator, לא authority
AI שימושי מאוד במיגרציה, אבל לא כי הוא “כותב את הבדיקות בשבילנו”.
הוא עוזר ב:
- פירוק דרישות לתרחישים.
- ניתוח logs ו-traces.
- יצירת edge cases.
- ניסוח SQL checks.
- סיכום coverage diff בין Selenium ל-Playwright.
אבל הוא חייב להישאר בנתיב הנכון.
| תפקיד AI | שימוש טוב | מה אסור להאציל בעיוורון |
|---|---|---|
| Assistant | תכנון תרחישים, bug reports, data | אישור business correctness |
| Copilot | refactor ל-fixtures ו-page models | קבלת קוד בלי review |
| Agent | draft PRs, CI triage | merges, destructive commands |
המודל מאיץ. השער מחליט.
Analyze, Optimize, Migrate
דוקטרינת הטטריס אינה “נכתוב הכול מחדש”. היא:
1. Analyze
ממפים את הערך האמיתי של Selenium estate:
- אילו בדיקות באמת תופסות regressions?
- אילו suites נכשלות הרבה ולא מלמדות כלום?
- איפה יש duplication בין UI, API ו-contract?
- אילו failures הם locator noise ואילו product risk?
2. Optimize
לא מעבירים זבל.
מוחקים או מעצבים מחדש:
- בדיקות לפיצ’רים מתים.
- happy paths כפולים.
- UI checks ששייכים לשכבת API.
- assertions שלא מאמתים business outcome.
מיגרציה טובה יכולה להקטין את מספר הבדיקות ועדיין להעלות אמון.
3. Migrate
רק אחרי ניקוי מעבירים את התרחישים ששווים הישרדות ל-Playwright:
- fixtures ברורים.
- data יציב.
- traces שימושיים.
- semantics טובים לכישלון.
- review משותף עם dev.
Blueprint ל-90 יום
| חלון | מטרה | פלט |
|---|---|---|
| שבועות 1-2 | inventory ובחירת beachhead | migration map ו-kill list |
| שבועות 3-4 | foundation ל-Playwright | מבנה פרויקט, fixtures, reporting, CI gate |
| שבועות 5-8 | מיגרציית מודול ראשון | coverage מלא לדומיין קריטי |
| שבועות 9-10 | stabilization | flake triage, prompt library, review standards |
| שבועות 11-12 | retirement ו-ROI | הסרת Selenium מקביל ודוח ערך |
מדדי הצלחה:
- pass rate מעל 95%.
- ירידת runtime.
- ירידת flake rate.
- RCA מהיר יותר.
- השתתפות מפתחים ב-review.
- retirement אמיתי של legacy coverage.
סיכום: בלוק אחרי בלוק
דוקטרינת הטטריס עובדת כי היא הופכת migration מאמונה לשרשרת ניצחונות מבוקרים.
בוחרים בלוק עסקי. מנתחים מה שווה לשמור. מהגרים רק מה שצריך לשרוד. משתמשים ב-AI להאצה, לא לסמכות. מוכיחים ROI. מנקים את השורה. עוברים לבלוק הבא.
המטרה אינה repository מודרני על הנייר.
המטרה היא להוציא סיכון מהמערכת בלי ליצור כאוס חדש.
Architecture > Magic.