יש שינוי גדול שעובר בשנים האחרונות על עולם הבדיקות.

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

המודל הזה עדיין קיים בהרבה ארגונים.

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

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

כאן נכנס לתמונה Continuous Testing – בדיקות רציפות.

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

לא בדיקה אחת גדולה בסוף.

בדיקות קטנות, חכמות וממוקדות לאורך כל הדרך.

אז מה זה בעצם Continuous Testing?

Continuous Testing הוא גישה שבה בדיקות מתבצעות באופן רציף לאורך מחזור הפיתוח והאספקה של התוכנה.

לדוגמה:

• Commit חדש יכול להפעיל בדיקות Unit.
• Pull Request יכול להפעיל בדיקות Integration.
• שינוי ב-API יכול להפעיל בדיקות API.
• Build חדש יכול להפעיל בדיקות Regression ממוקדות.
• לפני Deployment ניתן לבצע בדיקות End-to-End.
• לפני Production אפשר להוסיף בדיקות על סביבה אמיתית, מכשירים אמיתיים או תרחישים עסקיים מורכבים.

המטרה אינה "לעשות יותר בדיקות".

המטרה היא לקבל פידבק מוקדם יותר.

וזה הבדל משמעותי.

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

---

Continuous Testing אינו רק Test Automation

זו אחת הטעויות הנפוצות ביותר.

הרבה אנשים שומעים Continuous Testing וחושבים שמדובר בשם אחר ל-Automation.

אבל אלה שני דברים שונים.

Test Automation היא טכניקה.

אנחנו לוקחים תרחיש בדיקה והופכים אותו לאוטומטי כך שמחשב יוכל להריץ אותו ללא התערבות ידנית.

Continuous Testing היא גישה רחבה יותר.

היא שואלת:

באיזה שלב בתהליך כדאי לבצע את הבדיקה הזאת כדי לקבל את הפידבק הכי מהר?

לכן Continuous Testing יכול לכלול:

• Unit Testing
• API Testing
• Integration Testing
• UI Automation
• Regression Testing
• Performance Testing
• Security Testing
• Manual Testing
• Exploratory Testing
• בדיקות על מכשירים אמיתיים
• בדיקות בסביבות שונות
• בדיקות מבוססות סיכון

כלומר, Automation הוא כלי בתוך המערכת.

Continuous Testing הוא האופן שבו אנחנו מנהלים את איכות המוצר לאורך כל תהליך המסירה.

---

למה זה כל כך חשוב לראש צוות QA?

כראש צוות בדיקות, קל מאוד לחשוב שהמטרה היא להגדיל את כמות הבדיקות האוטומטיות.

עוד Test Case.

עוד Script.

עוד Suite.

עוד Regression.

אבל לפעמים זה בדיוק המקום שבו אנחנו מפספסים את התמונה הגדולה.

השאלה החשובה יותר היא:

האם הבדיקות שלנו מגיעות בזמן שבו הן עדיין יכולות להשפיע על המוצר?

אם יש לנו 10,000 בדיקות אוטומטיות אבל הן רצות רק בלילה לפני Release – עדיין יש לנו צוואר בקבוק.

לעומת זאת, אם יש לנו 500 בדיקות איכותיות שמופעלות בצורה חכמה בשלבים הנכונים של ה-CI/CD, יכול להיות שהן נותנות לארגון הרבה יותר ערך.

---

10 דברים שצריך לבדוק לפני שבוחרים שירות Continuous Testing

1. עד כמה השירות באמת מתחבר ל-CI/CD שלכם?

זה אולי הדבר הראשון שהייתי בודק.

לא כמה פיצ'רים יש למערכת.

לא כמה יפה נראה ה-Dashboard.

ולא כמה AI יש בתוכה.

השאלה הראשונה היא:

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

אם הארגון עובד עם GitHub Actions, Jenkins, GitLab CI, Azure DevOps או מערכת אחרת – צריך לבדוק איך השירות משתלב בה.

לדוגמה:

מפתח עושה Commit.

ה-Pipeline מתחיל.

הבדיקות מופעלות.

התוצאות חוזרות באופן אוטומטי.

אם משהו נכשל – ה-Pipeline יודע לעצור.

אם הכל תקין – התהליך ממשיך.

זה Continuous Testing אמיתי.

אם בכל פעם שמפעילים בדיקה צריך להיכנס ידנית למערכת, לבחור Suite, להפעיל אותה ולהעתיק את התוצאות חזרה לצוות – נוצר חיכוך.

ובסוף אנשים פשוט מפסיקים להשתמש בזה.

השאלה שכדאי לשאול:

"האם אני יכול להפעיל בדיקה מתוך ה-Pipeline ולקבל את התוצאה באופן אוטומטי?"

אם התשובה מסובכת – צריך לבדוק למה.

---

2. האם המערכת יודעת גם לעזור ביצירת בדיקות?

בעבר אחת הבעיות הגדולות הייתה זמן הפיתוח של האוטומציה.

צריך להבין את המערכת.

לכתוב Test Case.

לכתוב Script.

לתחזק Locators.

לטפל ב-Test Data.

להריץ.

לתקן.

ואז המוצר משתנה.

והכל מתחיל מחדש.

AI מתחיל לשנות את התהליך הזה.

מערכות חדשות מסוגלות לייצר בדיקות מתוך מקורות כמו:

• User Stories
• API Specifications
• OpenAPI
• מסמכי דרישות
• תרחישים קיימים
• קוד
• התנהגות משתמשים

אבל חשוב מאוד לא להתלהב יותר מדי.

בדיקה שנוצרה על ידי AI אינה בהכרח בדיקה טובה.

AI יכול לכתוב Test Case שעובר בהצלחה אבל בכלל לא בודק את הדבר הנכון.

לכן AI צריך להיות מכפיל כוח למהנדס הבדיקות, לא תחליף לשיקול דעת.

הערך האמיתי הוא לא "AI כתב לי בדיקה".

הערך הוא:

"AI חסך לי שעה של עבודה ראשונית, ועכשיו אני יכול להשקיע את הזמן שלי בחשיבה על מה באמת חשוב לבדוק."

---

3. האם יש גם בדיקה של העולם האמיתי?

אוטומציה היא מדהימה.

אבל יש דברים שאוטומציה מתקשה למצוא.

לדוגמה:

האתר נראה מצוין בכרום במחשב של המפתח.

אבל משתמש באייפון ישן רואה כפתור שנחתך.

ה-API עובד.

אבל משתמש ממדינה אחרת מקבל פורמט תאריך שגוי.

ה-Payment Flow עובר בבדיקות.

אבל במכשיר מסוים המקלדת מכסה את כפתור התשלום.

המערכת עובדת.

אבל ברשת סלולרית חלשה היא הופכת לכמעט בלתי שמישה.

אלה בדיוק המקומות שבהם בדיקות על העולם האמיתי יכולות להוסיף ערך.

ולכן שירות Continuous Testing טוב לא חייב להתבסס רק על Cloud Browsers ו-Emulators.

לפעמים צריך גם:

• מכשירים אמיתיים
• מערכות הפעלה שונות
• רשתות שונות
• אזורים גאוגרפיים שונים
• משתמשים אמיתיים
• בדיקות ידניות
• Exploratory Testing

הנקודה החשובה היא לא לבחור בין Automation לבין Manual Testing.

הנקודה היא להבין איפה כל אחד מהם נותן את הערך הגדול ביותר.

---

4. האם יש Orchestration אמיתי?

ככל שהמערכת גדלה, מספר הבדיקות גדל.

ואז מתחילה הבעיה.

יש בדיקות UI.

יש API.

יש Microservices.

יש Database.

יש Mobile.

יש Integration.

יש Performance.

יש Security.

אם כל אחד מהם רץ בנפרד, קשה מאוד להבין את התמונה הכוללת.

כאן נכנסת Orchestration.

מערכת טובה צריכה לדעת לנהל את הבדיקות בצורה מרכזית:

• אילו בדיקות להפעיל
• מתי להפעיל אותן
• באיזו סביבה
• באיזה סדר
• אילו בדיקות להריץ במקביל
• אילו בדיקות לדלג עליהן
• אילו בדיקות קשורות לשינוי שבוצע

השלב המעניין יותר הוא Intelligent Test Selection.

אם המפתח שינה רק רכיב מסוים במערכת, אין תמיד סיבה להריץ את כל אלפי בדיקות ה-Regression.

אפשר לנסות לזהות אילו אזורים הושפעו מהשינוי ולהפעיל קודם את הבדיקות הרלוונטיות.

כך מקבלים פידבק מהיר יותר בלי לוותר בהכרח על כיסוי רחב בשלבים מאוחרים יותר.

---

5. האם Security הוא חלק מהתהליך?

איכות תוכנה אינה מסתיימת בשאלה:

"האם הפיצ'ר עובד?"

צריך לשאול גם:

"האם הוא בטוח?"

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

אפשר לשלב בתהליך בדיקות כמו:

• SAST
• DAST
• Dependency Scanning
• Secrets Detection
• Security Testing
• בדיקות הרשאות
• בדיקות קלט

הרעיון פשוט:

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

מבחינת מנהל QA, זה גם שינוי תפיסתי חשוב.

QA כבר לא אחראי רק ל"Functional Quality".

הוא חלק ממערך איכות רחב יותר.

---

6. איך המודל העסקי מתמודד עם קצב הפיתוח?

זו נקודה שאנשים שוכחים לבדוק.

נניח שהצוות שלכם עושה שני Deployments בשבוע.

ועכשיו, שנה לאחר מכן, אתם עוברים ל-20 Deployments ביום.

האם העלות של השירות נשארת הגיונית?

מודל שמתמחר כל הרצה בנפרד עלול להפוך ליקר מאוד כאשר קצב הפיתוח עולה.

לכן צריך להבין:

• האם משלמים לפי Test?
• לפי Execution?
• לפי משתמש?
• לפי מכשיר?
• לפי זמן?
• לפי Credits?
• לפי חבילה?
• לפי תוצאה?

המספר החשוב ביותר הוא לא המחיר היום.

המספר החשוב הוא:

כמה זה יעלה כאשר הארגון יגדל?

---

7. האם אפשר להגדיל את הקיבולת במהירות?

יש תקופות שבהן צוות QA צריך הרבה יותר כוח.

Release גדול.

מיזוג בין מערכות.

Migration.

השקת מוצר.

Black Friday.

רגולציה.

גרסה קריטית.

בדיוק ברגע הזה לא כדאי לגלות שהשירות מסוגל להריץ רק כמות מוגבלת של בדיקות.

לכן חשוב לבדוק את היכולת לגדול במהירות.

האם ניתן להוסיף:

• מכשירים?
• Testers?
• Execution Capacity?
• Environments?
• Parallel Runs?

והשאלה שאני הייתי שואל ספק היא פשוטה:

"מה קורה אם מחר אני צריך פי חמישה מהקיבולת הרגילה?"

התשובה לשאלה הזאת יכולה ללמד הרבה על השירות.

---

8. האם הדוחות באמת עוזרים לפתור באגים?

כאן הרבה מערכות נופלות.

Test נכשל.

המערכת מציגה:

FAILED

וזהו.

מבחינת המפתח, זו כמעט לא אינפורמציה.

הוא עכשיו צריך להתחיל לחקור:

מה קרה?

איפה?

באיזה Environment?

איזה Data?

איזה Request?

איזה Response?

איזה Browser?

איזה Device?

איך משחזרים?

דוח טוב צריך לקצר את הדרך בין:

"הבדיקה נכשלה"

לבין:

"אני יודע בדיוק מה קרה ואני יכול להתחיל לתקן."

לכן כדאי לחפש דוחות הכוללים:

• Steps to Reproduce
• Screenshots
• Video
• Logs
• Request / Response
• Environment
• Device
• Browser
• Timestamp
• Error Details
• Test Data
• Expected Result
• Actual Result

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

---

9. מי באמת אחראי על הבדיקות?

זו אחת השאלות החשובות ביותר לפני בחירת שירות.

יש שלושה מודלים מרכזיים.

Managed Service

הספק עושה חלק גדול מהעבודה:

• תכנון
• ביצוע
• דיווח
• לפעמים גם תחזוקה

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

Self-Service

הארגון מנהל את הבדיקות בעצמו באמצעות פלטפורמה.

זה מתאים יותר לצוותים שיש בהם Test Engineers ויכולת טכנית.

Hybrid

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

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

לדוגמה:

צוות QA פנימי מנהל את אסטרטגיית הבדיקות.

השירות החיצוני מספק Execution Capacity.

או:

הצוות כותב את הבדיקות.

הספק מריץ אותן על מגוון מכשירים.

הנקודה היא שאין מודל אחד שמתאים לכולם.

---

10. מה קורה כאשר המוצר משתנה?

זה אולי האתגר הגדול ביותר של Continuous Testing.

בהתחלה הכל נראה מצוין.

יש 1,000 בדיקות.

הכל ירוק.

כולם מרוצים.

ואז המוצר משתנה.

כפתור זז.

API משתנה.

תהליך עסקי מתעדכן.

Database משתנה.

Feature חדש נכנס.

ועכשיו חלק מהבדיקות כבר לא רלוונטיות.

חלק נשברות.

חלק ממשיכות לעבור למרות שהן כבר לא בודקות משהו משמעותי.

זה נקרא Test Suite Decay.

וזה מסוכן.

כי צוות יכול להסתכל על Dashboard ירוק ולחשוב:

"יש לנו כיסוי מצוין."

כאשר בפועל חלק מהבדיקות כבר לא מספקות ערך.

לכן Continuous Testing אינו רק תהליך של הוספת בדיקות.

הוא גם תהליך של:

• מחיקת בדיקות לא רלוונטיות
• עדכון בדיקות
• זיהוי בדיקות כפולות
• בדיקת איכות הכיסוי
• בחינת Flaky Tests
• בדיקת Test Relevance
• התאמת הבדיקות לשינויים במוצר

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

---

ומה עם הבודק הידני?

אני חושב שזו אחת הנקודות החשובות ביותר בדיון על Continuous Testing.

יש מי שחושב ש-Continuous Testing אומר:

"בואו נחליף את הבודקים באוטומציה."

אני לא חושב שזו הדרך הנכונה להסתכל על זה.

ככל שהאוטומציה משתפרת, התפקיד של הבודק יכול להפוך דווקא ליותר משמעותי.

המחשב מצוין ב:

• חזרתיות
• ביצוע מהיר
• בדיקות Regression
• בדיקות נתונים
• השוואות
• הרצות רבות
• בדיקות API
• בדיקות יציבות

אבל בני אדם טובים מאוד ב:

• סקרנות
• חשיבה ביקורתית
• הבנת משתמש
• זיהוי התנהגות מוזרה
• Exploratory Testing
• שאלת "מה אם?"
• זיהוי בעיות שלא הוגדרו מראש

לכן השאלה אינה:

Manual או Automation?

השאלה היא:

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

---

איך הייתי בונה Continuous Testing בארגון?

לא הייתי מתחיל מקניית פלטפורמה.

הייתי מתחיל מה-Pipeline.

ממפה את הדרך שבה שינוי עובר מרגע כתיבת הקוד ועד Production.

ואז שואל בכל שלב:

איזה סיכון אנחנו יכולים לזהות כאן?

לדוגמה:

Commit

בדיקות Unit מהירות.

Pull Request

בדיקות Integration ו-API.

Build

בדיקות Regression קריטיות.

Staging

בדיקות End-to-End.

לפני Production

בדיקות Smoke, Security ובדיקות עסקיות קריטיות.

לאחר Deployment

Smoke Testing וניטור התנהגות המערכת.

לאחר שינוי משמעותי

Exploratory Testing ובדיקות משתמשים אמיתיים.

כך הבדיקות הופכות ממחסום בסוף הדרך למערכת שמלווה את המוצר לאורך כל הדרך.

---

הטעות הגדולה ביותר: למדוד כמות בדיקות במקום איכות פידבק

זה משהו שאני חושב שכל מנהל QA צריך לעצור ולחשוב עליו.

קל למדוד:

"יש לנו 8,000 Test Cases."

קל להגיד:

"95% מהבדיקות אוטומטיות."

קל להגיד:

"98% מהבדיקות עברו."

אבל אלה לא בהכרח מדדים של איכות.

השאלה המעניינת יותר היא:

כמה מהר אנחנו יודעים שמשהו השתבש?

וכמה מהר אנחנו יכולים להגיב?

אפשר להסתכל על מדדים כמו:

• זמן ממוצע לגילוי Defect
• זמן ממוצע לתיקון
• אחוז בדיקות Flaky
• זמן Pipeline
• אחוז כשלונות אמיתיים לעומת False Positives
• Defects שהגיעו לייצור
• כיסוי של אזורים קריטיים
• זמן Feedback למפתח

אלה מדדים שמחברים את עולם הבדיקות ישירות לערך העסקי.

---

Continuous Testing הוא בסופו של דבר שינוי תרבותי

וזו אולי הנקודה החשובה ביותר.

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

אפשר להכניס AI.

אפשר לכתוב אלפי בדיקות אוטומטיות.

אפשר להקים Pipeline מרשים.

ועדיין להיכשל.

כי Continuous Testing אינו רק טכנולוגיה.

הוא שינוי בדרך שבה הארגון חושב על איכות.

במקום:

"QA יבדקו בסוף."

עוברים ל:

"איכות היא אחריות שמתחילה מהרגע שבו השינוי נוצר."

המפתח מקבל פידבק מוקדם.

הבודק מקבל יותר זמן לחשוב.

האוטומציה מטפלת בחזרתיות.

ה-AI יכול לעזור לייצר ולתחזק בדיקות.

והארגון מקבל החלטה טובה יותר לגבי השאלה החשובה ביותר:

האם הגרסה הזאת באמת מוכנה להגיע ללקוח?

וזה בעיניי הלב של Continuous Testing.

לא יותר בדיקות.

לא יותר Automation.

לא עוד Dashboard.

אלא פידבק נכון, בזמן הנכון, לאדם הנכון – לפני שבעיה קטנה הופכת לבעיה יקרה.

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

קורס לבדיקות תוכנה מדויק

לעבוד מהבית כבודק תוכנה עם FIVERR >> לחץ כאן