QA ובקרת שחרורים

בדיקות אוטומטיות

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

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

צוותים שמבקשים מאיתנו אוטומציה

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

צוותים שמשחררים לעיתים קרובות אבל עדיין עוברים ידנית, קליק אחרי קליק, על בדיקות הרגרסיה
ראשי צוותי פיתוח שסט הבדיקות שלהם ב-CI איטי, לא יציב (flaky) או מורץ שוב ושוב עד שהוא עובר
צוותים שעובדים עם סוכני קוד מבוססי AI שפותחים Pull Requests מהר יותר ממה שאפשר לבדוק ידנית

אילו סטי בדיקות רצים ומתי

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

	בכל Pull Request	בכל לילה	לפני שחרור	אחרי פריסה
בדיקות יחידה	רץ ומהווה תנאי מעבר לשלב	לא רץ בשלב הזה	רץ ומהווה תנאי מעבר לשלב	לא רץ בשלב הזה
בדיקות API ובדיקות חוזה	רץ ומהווה תנאי מעבר לשלב	רץ ומהווה תנאי מעבר לשלב	רץ ומהווה תנאי מעבר לשלב	לא רץ בשלב הזה
בדיקות Smoke מקצה לקצה	רץ ומהווה תנאי מעבר לשלב	רץ ומהווה תנאי מעבר לשלב	רץ ומהווה תנאי מעבר לשלב	רץ ומהווה תנאי מעבר לשלב
רגרסיה מלאה מקצה לקצה	חלק מהסט, או דיווח בלבד	רץ ומהווה תנאי מעבר לשלב	רץ ומהווה תנאי מעבר לשלב	לא רץ בשלב הזה
השוואה ויזואלית	חלק מהסט, או דיווח בלבד	לא רץ בשלב הזה	רץ ומהווה תנאי מעבר לשלב	לא רץ בשלב הזה
בדיקות ב-Sandbox של צד שלישי	לא רץ בשלב הזה	רץ ומהווה תנאי מעבר לשלב	חלק מהסט, או דיווח בלבד	לא רץ בשלב הזה

רץ ומהווה תנאי מעבר לשלב
חלק מהסט, או דיווח בלבד
לא רץ בשלב הזה

אוטומציה שתופסת רגרסיות, לא רעש

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

כתיבת בדיקות בסיוע AI, בסקירת מהנדסים

איך ה-AI מסייע

מנסח טיוטות של בדיקות יחידה, API ומקצה לקצה מתוך הדרישות, מפרטי ה-API והקוד הקיים, לסקירת המהנדסים.
משווה דוחות כיסוי לתהליכים הקריטיים שלכם ולשינויים האחרונים, כדי להראות היכן חסרות בדיקות.
חוקר בדיקות לא יציבות ובדיקות שנכשלות בעזרת היסטוריית ההרצות, לוגים ועקבות (traces), ומציע סיבות סבירות.
מעדכן סלקטורים, Fixtures ונתוני בדיקה כשהממשק או ה-API משתנים, כ-Pull Requests שעוברים סקירה.

מה באחריות המומחים שלנו

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

מה תקבלו

סט בדיקות שרץ בפייפליין שלכם

אסטרטגיית אוטומציה
מה להפוך לאוטומטי, באיזו רמה ובאילו כלים, כמו Jest, Vitest, pytest, Playwright או Cypress, שנבחרים כך שיתאימו לסטאק ולצוות שלכם.
בדיקות יחידה ואינטגרציה
בדיקות מהירות לכללים עסקיים, לגישה לנתונים ולגבולות בין שירותים, עם נתוני בדיקה ו-Mocks שהמפתחים שלכם יכולים לתחזק.
בדיקות API ובדיקות חוזה
בקשות, תגובות, שגיאות והרשאות נבדקות מול מפרט ה-API שלכם, כולל החוזים שלכם מול שירותי צד שלישי.
בדיקות מסע מקצה לקצה
בדיקות בדפדפן להרשמה, לתשלום, לתפקידים ולתהליכים קריטיים אחרים, עם צילומי מסך, עקבות (traces) והשוואה ויזואלית היכן שפריסת המסך חשובה.
שילוב בפייפליין ה-CI
סטי הבדיקות רצים על Pull Requests ולפני שחרורים ב-GitHub Actions, ב-GitLab CI או בפייפליין הנוכחי שלכם, עם תנאי מעבר ונפילה ברורים.
דיווח על תקינות הבדיקות
כיסוי של תהליכים קריטיים, מעקב אחרי בדיקות לא יציבות ומגמות של כשלים, כדי שתוכלו לראות אם סט הבדיקות ראוי לאמון של הצוות שלכם.

איך אנחנו בונים את סט הבדיקות שלכם

01
בחינת הבדיקות הקיימות
סקירה של הבדיקות הקיימות, הגדרות ה-CI, הכיסוי והיסטוריית הכשלים, וזיהוי התהליכים שבהם רגרסיה תכאב הכי הרבה.
02
סיכום הגישה
בחירת רמות הבדיקה, הכלים ותנאי המעבר, סיכום מוסכמות עבודה, והקמת נתוני בדיקה וסביבות שהצוות שלכם יכול לעשות בהם שימוש חוזר.
03
בניית כיסוי קריטי
ה-AI מנסח טיוטות של בדיקות, והמהנדסים סוקרים ומשפרים אותן. המסלולים הקריטיים קודמים, ואחר כך הכיסוי מתרחב לפי סיכון.
04
הרצה, דיווח ותחזוקה
סטי הבדיקות רצים ב-CI עם דיווח. אנחנו מוסרים אותם עם תיעוד או שומרים על עדכניותם במסגרת QA שוטף.

שתי דרכים לעבוד עם כלי AI

ה-AI עוזר לנסח טיוטות לבדיקות ולחקור באגים. בחרו היכן הוא רשאי לעבד את הקוד ואת נתוני הבדיקה שלכם.

הנדסת AI פרטית / מקומית
מודלים באירוח פרטי, בתוך תשתית שבשליטתכם או בסביבה מבודדת מוסכמת.
דברו איתנו על החבילה הזו
הנדסת Claude Code / OpenAI Codex
Claude Code ו/או OpenAI Codex, עם הגדרות ענן שהארגון שלכם מאשר.
דברו איתנו על החבילה הזו

לא בטוחים? נמליץ על אחת מהן בשלב הגדרת ההיקף. השוואת אפשרויות עבודה עם AI

בקשות אוטומציה אופייניות

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

סט בדיקות לא יציב שאף אחד לא סומך עליו
בדיקות הדפדפן של צוות מסוים עוברות בהרצה אחת ונכשלות בהרצה הבאה. אנחנו מפרידים בין בעיות של נתוני בדיקה משותפים ושל תזמון לבין באגים אמיתיים, מתקנים את הבדיקות בשורש הבעיה ומסכמים אילו בדיקות רשאיות לחסום מיזוג.
ימי רגרסיה ידניים לפני כל שחרור
צוות מוצר מבלה את ימי השחרור בהקלקה ידנית על אותם תהליכים. אנחנו הופכים את המסלולים הקריטיים לאוטומטיים ברמה הנמוכה ביותר שעדיין אמינה — קודם בדיקות יחידה או API, ובדפדפן רק היכן שהמסע דורש זאת — ומריצים אותם כתנאי לשחרור.
תנאי סף ל-Pull Requests שכתבו סוכנים
צוות מאפשר לסוכן קוד מבוסס AI לפתוח Pull Requests. אנחנו מוסיפים בדיקות חובה, כך ששינויים של הסוכן עוברים את אותן בדיקות יחידה, בדיקות חוזה ובדיקות Smoke כמו שינויים של בני אדם, ואדם עדיין מאשר כל מיזוג.

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

בדיקות חוקרות וההמלצה לגבי סיכוני השחרור הן חלק משירות QA ובדיקות תוכנה; השירות הזה בונה ומתחזק את הבדיקות האוטומטיות.
הקמה או העברה של פלטפורמת ה-CI עצמה הן עבודה במסגרת שירות DevOps ו-CI/CD; אנחנו מחברים את סטי הבדיקות לפייפליין שכבר פועל אצלכם.
הרצות עומס ועמידות לאורך זמן דורשות כלים וסביבות משלהן — הן מבוצעות במסגרת שירות בדיקות ביצועים.
מתן ציון לתשובות של LLM מול מערכי נתונים להערכה הוא תחום אחר — הוא מטופל במסגרת שירות הערכה ובדיקות של AI.

איך האוטומציה משתלבת בעיצוב, ב-QA ובתפעול

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

שאלות ותשובות

שאלות נפוצות

באיזה פריימוורק בדיקות כדאי לנו להשתמש?

בדרך כלל בזה שמתאים לסטאק ולצוות שלכם: Jest או Vitest ל-JavaScript ול-TypeScript, pytest ל-Python, ו-Playwright או Cypress לבדיקות בדפדפן. אנחנו שומרים על כלים שכבר עובדים בשבילכם ומחליפים אותם רק כשיש לכך סיבה ברורה.

כמה כיסוי בדיקות אנחנו צריכים?

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

תוכלו להוסיף בדיקות לקוד מדור קודם או לקוד שנוצר בידי AI?

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

האם כלי AI רואים את קוד המקור שלנו בזמן כתיבת הבדיקות?

רק בתוך הגבולות שאתם בוחרים. בהנדסת AI פרטית / מקומית, המודלים רצים על תשתית שבשליטתכם או בסביבה מבודדת שאנחנו מסכמים איתכם. בהנדסת Claude Code / OpenAI Codex, ספקים מסחריים מעבדים את הקוד לפי תנאי חשבון, טיפול בנתונים ושמירה שמוסכמים לפני תחילת העבודה.