זרימת עבודה מקצה לקצה, שילוב CI/CD, אתיקה ואבטחה: שימוש בינה מלאכותית באחריות

רווחים:

• יכולת לעצב את התפקיד של בינה מלאכותית ונקודות אישור אנושיות בזרימת QA מקצה לקצה מרעיון לשחרור בהקשר של CI/CD
• ב-CI/CD, לא מתן אישור לבינה מלאכותית "לעבור" אוטומטית את המבחן, אלא החלת מגבלות כדי להגן על נתונים ומפתחות סודיים
• יכולת לבצע בדיקות אבטחה במסגרת הרשות ולמטרות הגנתיות, ולאמץ עקרונות גילוי אחראי ושקיפות אתית.

בעשר היחידות הקודמות, השתמשנו בבינה מלאכותית במשימות בודדות: יצירת תרחישים, קוד אוטומציה, דיווח באגים, ניתוח כיסוי, בדיקת מוטציות. יחידה אחרונה זו משלבת את כולם לזרימת עבודה אחראית אחת. QA מודרני הוא לא עבודה שמסתיימת על שולחנו של אדם אחד; זהו תהליך שחי בתוך CI/CD (Intinuous Integration / Continuous Delivery — הצינור שבו הקוד משולב כל הזמן, נבדק אוטומטית ומוכן לפרסום באופן תדיר ובטוח). AI יכול לגעת בכל שלב בתהליך הזה. אבל ככל שכוחה של AI גדל, כך גדלה החשיבות של שימוש בו בצורה אחראית: פרטיות, סמכות בבדיקות אבטחה, אתיקה, והכי חשוב, שמירה על ההחלטה האיכותית לאדם. ביחידה זו תלמדו זרימה וגבולות מקצה לקצה.

זרימת QA מקצה לקצה המופעלת על ידי AI

תפקידה של בינה מלאכותית במסע של תכונה מרעיון להפצה:

1. ניתוח דרישות. AI מסמן אי בהירות בדרישה וקריטריוני קבלה חסרים ("כלל זה לא אומר כמה תווים הסיסמה המינימלית").

2. עיצוב מבחן. טיוטות תרחיש ומקרה (יחידה 2), מקרי קצה (יחידה 3) הם בין קריטריוני הקבלה.

3. אוטומציה. טיוטות קוד בדיקה של יחידה (6), API (5) וממשק משתמש (4); כל אחת מאושרת על ידי מוטציה (10).

4. שילוב CI/CD. בדיקות פועלות באופן אוטומטי עם כל מיזוג קוד. AI מנסח תצורת צינור (YAML), מסכם יומנים של בדיקות שנכשלו, מציע גורם שורש אפשרי.

5. החלטת שחרור. תוצאות ניתוח סיכונים (8) ורגרסיה (9) נאספות - אך המומחה מחליט אם זה יכול להצליח.

6. ניטור ייצור ומשוב. שגיאות בשידור חי הופכות למבחנים עתידיים; AI מציע מקרה רגרסיה מפגם בייצור.

טיפ: הגדר AI כשכבה ב-CI/CD ש"מאיץ טיוטות שנבדקו על ידי אדם" במקום "כותבת בדיקות ומקבלת החלטות". אין להיכנס לצינור ללא בדיקות שנוצרו אוטומטית מבלי שאדם יבדוק אותן ויאשר אותן.

AI ב-CI/CD: איפה כן, איפה לא

במה

התאמה של AI

האדם חיוני

בדיקת טיוטת קוד

כן

עדכון + מוטציה

טיוטת צינור YAML

כן

אימות + בדיקת מפתח סודי

סיכום יומן נכשל

כן

אישור שורש

אבחון בדיקה שביר

כן

החלטת פתרון קבוע

"יכול להיות גרסה?"

לא

שיקול דעת ואחריות מומחה

"עובר" אוטומטית את המבחן

לעולם לא

—

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

פרטיות, נתונים ואבטחה: גבולות בלתי ניתנים לשינוי

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

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

אתיקה ושקיפות. אל תציג את הבדיקות שהופקו על ידי AI כעבודה שלך; הצהרה שאתה משתמש בבינה מלאכותית בתוך הצוות היא שקיפות. אתה אחראי לאי הדיוק של פלט שיוצר בינה מלאכותית - "AI כתב את זה" אינו תירוץ.

הנחיה חלשה / הנחיה חזקה

חלש: "הגדר צינור בדיקה עבור CI."

חזק: "נסח זרימת עבודה של CI YAML עבור פעולות GitHub: הפעל בדיקות יחידה + API על כל PR, הפקת דוח כיסוי, הרץ בדיקות מוטציות (Stryker) מדי שבוע. אל תטמיע סודות בקוד; השתמש בהפניה לסודות בלבד. חסום מיזוג אם הבדיקות אדומות. זו טיוטה; אני אבדוק ולא אערוך שלב סודי ניהול או DO תיקון אוטומטי של בדיקת מפתח או DO. צעד 'הגירה'."

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

ארבע תבניות הניתנות להעתקה

1) תוכנית בדיקות מקצה לקצה:

תפקידך: מנהיג QA בכיר. נסח תוכנית בדיקה מקצה לקצה מרעיון ועד שחרור עבור התכונה הבאה: [תכונה + קריטריוני קבלה]. שלבים: ניתוח דרישות (אי ודאויות), תכנון בדיקות, שכבות אוטומציה (יחידה/API/UI), אינטגרציה של CI/CD, קריטריונים להחלטת שחרור, מעקב ייצור. ציין את התפקיד של נקודות אישור AI ו-HUMAN בכל שלב בנפרד.

2) מתווה צינור CI/CD:

טיוטת CI YAML עבור [GitHub Actions/GitLab CI/Azure Pipelines]:- יחידה + בדיקת API + היקף ב-PR- מנע מיזוג בבדיקה אדומה- ערכים סודיים רק עם סודות; הטמעה בקוד זוהי טיוטה; אסקור את שלבי הניהול והאישור העיקריים. הוספת שלב מבחן אוטומטי/עובר.

3) ניתוח יומן בדיקה נכשל:

בתדפיס ה-CI הזה, הבדיקות אדומות. בדוק את היומן; לקבץ את הכשלים, להבחין בגורם השורש האפשרי ואיזה עשוי להיות הכשל האמיתי ואשר עשוי להיות בדיקה שבירה/בעיית סביבה. אם יש נתונים אישיים, מסווה אותם. ההחלטה והתיקון יהיו שלי. יומן: [הדבק]

4) בדיקת אבטחה/פרטיות מראש:

לפני שנתוני בדיקה/יומן זה נשלחים לכלי AI, בדוק: האם הוא מכיל נתונים אישיים, מפתח API, כתובת מערכת פנימית, נתוני ייצור? רשום אילו אזורים, אם בכלל, יש להסוות/להסיר. עיבוד כמו שהוא. תוכן: [הדבק]

שלושה מיני תיקים

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

מקרה 2 - חזרה מדליפת מפתח. למפתח היה ה-AI שיצר את CI YAML, וה-AI הטמיע מפתח API בעל מראה אמיתי לתוך ה-YAML כדוגמה. שלב "בדיקת אבטחה/פרטיות מראש" תפס זאת; מפתח הומר להפניה לסודות. ללא שלב הביקורת, המפתח ידלוף לבקרת גרסאות (היסטוריית git).

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

טעויות נפוצות

• מתן AI לקבל החלטות שחרור. שואל את השאלה "האם ניתן לשחרר אותו?" ל-AI והצבת התשובה במקום החתימה.
• "עובר" את המבחן האוטומטי. ב-CI, לאחר שה-AI יצבע את הבדיקה בירוק; מחפה על טעויות.
• מתן נתונים/מפתח חסויים לרכב. שיתוף נתוני ייצור, נתונים אישיים או מפתחות API ללא פיקוח.
• בדיקות אבטחה לא מורשות. בדיקת תוקף במערכת אחרת ללא היקף והרשאה.
• הכנסת בדיקות לצינור ללא סקירה. הרץ אוטומטית את סקיצת הבינה המלאכותית ללא אישור אנושי.
• מטילים את האשמה על הבינה המלאכותית. הגנה על הפלט השגוי באמירת "AI כתב את זה".

לסיכום

QA מקצה לקצה הוא תהליך המשתרע מדרישות למעקב אחר ייצור וחיים בתוך CI/CD; בכל שלב, AI מייצר טיוטות, מסכם את היומן ומציע סיבות שורש. אבל הגבולות בלתי ניתנים לשינוי: בני אדם מקבלים החלטות בדיקה ומשחררים אישור; ל-AI לעולם לא ניתנת הסמכות "לעבור" אוטומטית את המבחן; נתונים ומפתחות חסויים אינם נכנסים לרכב; בדיקות אבטחה מבוצעות רק על המוצר שלך, במסגרת ההרשאה הכתובה וההיקף המוגדר, למטרות הגנה, והממצאים מדווחים תוך חשיפה אחראית. היה שקוף כשאתה משתמש בבינה מלאכותית; אתה אחראי על הדיוק של הפלט. AI מאיץ; אתה מבטיח איכות ואתיקה.

משימת יישום

נסח תוכנית מרעיון לשחרור עם תבנית "תוכנית בדיקה מקצה לקצה" עבור תכונה מהפרויקט שלך; סמן את התפקיד של AI ונקודות אישור אנושיות בנפרד בכל שלב. לאחר מכן צור YAML עם "מתווה צנרת של CI/CD" והחל "בדיקה מוקדמת של אבטחה/פרטיות" על YAML זה כדי לבדוק אם יש מפתח/סודי מוטבעים. לבסוף, רשום את כל נקודות "ההחלטה האנושית" בתוכנית שלך ונמק במשפט אחד מדוע לא ניתן להאציל את ההחלטות הללו ל-AI.

רשימת בדיקה

• [ ] אני מייחס החלטות שחרור ובדיקה לאישור אנושי; לא מסרתי את זה ל-AI.
• [ ] ב-CI/CD לא נתתי ל-AI אישור "לעבור/לתקן" אוטומטית את המבחן.
• [ ] בדקתי והסתרתי נתונים סודיים, נתונים אישיים ומפתחות לפני שליחתם לרכב.
• [ ] שקלתי רק בדיקות אבטחה של המוצר שלי, במסגרת ההרשאה וההיקף הכתובה.
• [ ] התייחסתי לפגיעויות שנמצאו עם עקרון החשיפה האחראית.
• [ ] הצהרתי בשקיפות שהשתמשתי בבינה מלאכותית ושמתי על עצמי אחראי לדיוק הפלט.

מבחן מודול

1. כיצד 'מעבר שקרי' מוגדר בצורה המדויקת ביותר בהקשר של QA?

• א) למרות שהבדיקה הופכת לירוקה, היא למעשה לא מאשרת התנהגות כלשהי; ✔ לא הופך לאדום גם אם הקוד פגום
• ב) הבדיקה מתנהלת לאט מאוד וזמני קצוב.
• ג) הבדיקה מזהה שגיאה אמיתית והופכת לאדום
• ד) הבדיקה פועלת רק בסביבת הייצור

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

2. מהו המיקום המדויק ביותר של בינה מלאכותית בתהליך הבדיקה וה-QA?

• א) בינה מלאכותית יכולה להחליט אם ניתן לשחרר את הגרסה ללא אישור אנושי
• ב) בינה מלאכותית היא עוזרת שמפיקה טיוטות ורעיונות; ההחלטה והאחריות של 'האם זה מוכן לפרסום' היא של המומחה ✔
• ג) בינה מלאכותית כותבת רק טקסט ואינה יכולה להתמודד עם קוד בדיקה כלל
• ד) בינה מלאכותית תמיד כותבת בדיקה נכונה מאשר אנושית, ולכן סקירה מיותרת

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

3. בהתבסס על העובדה ששגיאות מתרחשות בעיקר בערכי סף, איזו טכניקת עיצוב מבחן היא לבדוק 17, 18 ו-19 בנפרד עבור מגבלת הגיל 18?

• א) מבחן מעבר מצב
• ב) טבלת החלטות
• ג) ניתוח ערכי גבול ✔
• ד) בדיקות חקרניות

הסבר: ניתוח ערכי גבול מבוסס על תצפית שטעויות מתרחשות בתדירות הגבוהה ביותר בגבולות ובודק ערכי סף (ממש מתחת, ממש מעל ומעט מעל הגבול) בנפרד. זוהי טכניקה רבת עוצמה המשלימה שיעורי שוויון.

4. איזו גישה יש להעדיף בבחירת אלמנטים כדי להפחית את השבריריות בקוד אוטומציה של בדיקות ממשק המשתמש המיוצר עם בינה מלאכותית?

• א) שימוש בנתיב XPath הארוך ביותר האפשרי
• ב) בחירת האלמנט לפי מיקום הפיקסלים שלו על המסך
• ג) שימוש בבוררים המבוססים על שמות מחלקות CSS
• ד) שימוש בתכונות יציבות (data-testid) שנוספו לבדיקה ✔

הסבר: נתיבים ארוכים של XPath ושמות מחלקות CSS תלויים מאוד במבנה העמוד ובעיצובו; זה נשבר בשינוי הקטן ביותר בממשק. תכונות יציבות שנוספו במיוחד לבדיקה (למשל data-testid) אינן מושפעות משינויי עיצוב והופכות את הבדיקות לחזקות.

5. למה זה לא מספיק עבור בדיקת API רק לבדוק את קוד סטטוס HTTP (למשל 200)?

• א) מכיוון שנתוני גוף עם קוד סטטוס נכון עלולים להיות פגומים ובדיקת סטטוס לבדה לא תתפוס זאת (פסאודו-אמון) ✔
• ב) כי קודי סטטוס אינם אמינים כלל בבדיקות API
• ג) כי בדיקת קוד סטטוס מאטה מאוד את הבדיקה
• ד) מכיוון שקוד סטטוס לעולם אינו מוחזר בבדיקות API

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

6. מדוע זה קריטי לומר ל-AI 'לחשב באופן ידני את הערך הצפוי לפי כלל הקבלה, לא להתייחס לפלט הנוכחי של הפונקציה' בעת הדפסת בדיקות יחידה?

• א) מכיוון שחישוב ידני מריץ בדיקות מהר יותר
• ב) כי אחרת הבדיקה מקבלת את ההתנהגות הנוכחית (אולי באגי) של הקוד כ'נכונה' ומאשרת את הבאג ✔
• ג) כי בינה מלאכותית אינה יכולה לחשב מספרים עשרוניים כלל
• ד) מכיוון שלעולם לא משתמשים בכללי קבלה במבחנים

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

7. איזו מהדברים הבאים היא התכונה הבולטת ביותר של דוח באג טוב?

• א) להיות כמה שיותר ארוך וטכני
• ב) נכתב על ידי בינה מלאכותית
• ג) מכיל שלבי רפרודוקציה דטרמיניסטיים שהמפתח יכול לעקוב אחריהם באופן עצמאי ולייצר את השגיאה ✔
• ד) זה רק צילום מסך

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

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

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

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

9. מהי הפרשנות המדויקת ביותר של חבילת בדיקה עם 90% כיסוי קווים?

• א) זה מראה שהקווים מבוצעים אבל לא מוכיח שהם מתנהגים נכון; ✔ כיסוי גבוה יכול לתת ביטחון כוזב
• ב) מוכיח באופן סופי ש-90% מהתוכנה נטולת באגים
• ג) זהו מדד סופי לאיכות בדיקה מעולה.
• ד) מציין שאין צורך לכתוב עוד מבחנים נוספים

הסבר: כיסוי שורות מציין שרק שורות בוצעו; זה לא מוכיח שהוא מייצר תוצאות נכונות. אפילו עם בדיקות חסרות תוקף, ניתן להשיג 90% כיסוי. סקופ היא מפת 'אף פעם לא הסתכלתי איפה', לא הבטחה של 'הכל נבדק'; ההגנה בפועל נמדדת על ידי בדיקת מוטציות.

10. בבדיקות מבוססות סיכונים, כיצד מחושב הסיכון של תכונה לכוון מאמץ בדיקה מוגבל?

• א) רק לפי מספר שורות קוד
• ב) על ידי הכפלת ההסתברות לכישלון וההשפעה שתתרחש כאשר הוא יתקלקל ✔
• ג) רק לפי סדר פיתוח התכונה
• ד) מתן עדיפות רק לתכונה שהכי קל לכתוב לה מבחנים

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

11. מה הסיכון העיקרי בהוספת ניסיון חוזר למבחן שלפעמים עובר ולפעמים נכשל (שביר/מתקלף) למרות שהקוד לא השתנה?

• א) קיצור זמן הריצה של הבדיקה
• ב) מקטין את אחוז הכיסוי
• ג) כיסוי של שגיאת מקבילות אמיתית או סיבת שורש ודיכוי הסימפטום ✔
• ד) שינוי שם המבחן

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

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

• א) על ידי מדידת מהירות הריצה של הבדיקות
• ב) על ידי ספירה כמה שורות קוד נכתבו
• ג) על ידי הפעלת הבדיקות בסדרים שונים
• ד) על ידי יצירת הפסקות קטנות בקוד ומדידת האם המבחנים תופסים אותם ✔

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

13. מהי המגבלה העיקרית שיש להקפיד עליה בעת ביצוע בדיקות אבטחה (למשל בדיקות הרשאה/IDOR)?

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

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

14. איזו סמכות לעולם לא תינתן ל-AI בצנרת ה-CI/CD?

• א) סיכום יומני בדיקה שנכשלו
• ב) הסמכות 'לעבור' אוטומטית במבחן שנכשל (אדום) או לצבוע אותו בירוק ✔
• ג) הצעת טיוטת קוד בדיקה
• ד) ניסוח קובץ ימל בצנרת

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