אסטרטגיית בדיקות - שיטות עבודה מומלצות, יתרונות וכלים בצוות DevOps | לירן יושינסקי

ראשית מה זה DevOps?

DevOps, זו תרבות ארגונית המשלבת מתודולוגיות, פרקטיקות וכלים, במטרה לשפר את תהליכי הפיתוח והתפעול של המוצר. המונח "DevOps" משלב בין פיתוח (Development) לתפעול (Operations) ומטרתו היא לשפר את שיתוף הפעולה בין צוותי הפיתוח והתפעול על מנת לייעל תהליכי עבודה, לקצר את זמן הפיתוח ולהגיב מהר יותר לשינויים ותקלות.

צוות שכזה פועל יחד, משתף ידע ומשלב אוטומציה בתהליכי פיתוח, בדיקה, התקנה, ניהול תשתיות והפעלת התוכנה.

ה-CD  (Continue Development) וה-CI (Continue Integration) וה-CT (Continue Testing), הם הבסיס לתהליכים מהירים, בטוחים ויעילים יותר, שמאפשרים גם הפצת פיצ'רים חדשים לסביבת הייצור בקלות ובמהירות.

בצוותי DevOps תפקיד הבודקים שונה מאשר בשיטות פיתוח מסורתיות (כמו אג׳ייל ומפל מים) הבדיקות (CT) משולבות לכל אורך תהליך ה-CI/CD מה שיכול לגרום לשיטות בדיקה מסורתיות להיראות פחות מתאימות. לעיתים אנשי DevOps אינם בטוחים כיצד לשלב בדיקות בתהליך, או סבורים שהן אינן הכרחיות, משום שהגישה שלהם מתמקדת בתיקון מהיר ופריסה מחדש של התוכנה. עם זאת, התפיסה הזו השתנתה עם הזמן.

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

כיצד בודקים משתלבים בצוותי DevOps?

צוותי DevOps לא תמיד יקדישו מספיק מחשבה לבדיקות. הבודקים צריכים ליזום ולהכניס את עצמם לזרימות העבודה (workflows) זה אומר לאתר הזדמנויות ליישם בדיקות בכל שלב – לא רק בפיתוח ואינטגרציה, אלא גם בסביבת הייצור.

 כדי להיות ספציפיים יותר, בודקים בצוותי DevOps עשויים למצוא את עצמם פועלים כ:

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

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

1. יש לזהות את כל מקרי הבדיקה (Test Cases) שיש לבצע עבור כל שלב בתהליך ה-CI/CD.
2. במקרים של אזורי קוד קריטיים שעלולים להשפיע על המערכת כולה, יש לבצע בדיקות מקיפות יותר.
3. הבדיקות צריכות להיות ממוקדות ואפקטיביות – כלומר, רק הבדיקות החיוניות שיבטיחו יציבות ואיכות המערכת צריכות להתבצע, מבלי להכביד על התהליך בבדיקות מיותרות.
4. אין צורך לבצע את כל ה-Regression Test Cases כדי לבצע את הבדיקות מסעיף 2.
5. יש להטמיע Coverage tools ו-specialized code analysis כדי להבטיח שכל הקוד מכוסה.
6. אסטרטגיית בדיקות לפיצ'ר חדש צריכה להיות סטנדרטית, תוך כדי כתיבת בדיקות אוטומטיות והפעלתן על ה-build החדש.
7. תהליך הבדיקות יימשך עד שהקוד יציב וניתן לפריסה בסביבת הייצור.
8. כל הפריסות צריכות להיות אוטומטיות, תוך הגדרת סביבות בדיקה מתאימות.
9. בדיקות אוטומטיות חוצות פלטפורמות שונות צריכות להתבצע על ידי הבודקים בצוות.
10. יש לבצע בדיקות במקביל (parallel execution) על מנת לחסוך זמן.

סוגי כלי בדיקה ב-DevOps

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

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

להבא נבחן מספר כלים מרכזיים לבדיקות:

Unit-Tests
בדיקות יחידה הן הראשונות שנעשות ונכתבות כחלק מתהליך הפיתוח המונחה-מבחן (TDD - Test-Driven Development). בבדיקות אלו, כל חלק של הקוד נבדק באמצעות מבחנים שנכתבים עוד לפני שהקוד עצמו מפותח. גישת ה-TDD היא קריטית, כיוון שהיא עוזרת למפתחים לחשוב לעומק על התנהגות כל יחידה בתוכנה.

Apache JMeter

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

תכונות עיקריות הן כמפורט להלן:

• בדיקת עומס וביצועים על שרתים, יישומים ופרוטוקולי אינטרנט
• תמיכה בפרוטוקולים כמו LDAP, JDBC, FTP, ו-SOAP/REST Webservices
• משמש כ-IDE לבדיקות פונקציונליות המאפשר גם הקלטה, איתור באגים ובנייה של test plan
• יצירת דוחות HTML דינמיים
• עבודה במתכונת Multi-threading
• תמיכה ב-Continuous Integration על ידי Gradle, Maven וJenkins.

הערה:
קיימים כלים חדשים ומעניינים המתחרים ב-Jmeter לדוגמא:

K6

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

• Web - HTTP/1.1, HTTP/2 (Java, NodeJS, PHP, ASP.NET, …)
• WebSockets
• gRPC
• SOAP / REST Webservices 

Mockito

Framework המיועד ליצירת אובייקטים מדומים (Mocking) ומיועד לפרויקטים שמשתמשים ב-TDD. הוא מסייע בפישוט הבדיקות על ידי הפחתת התלות במהלך הבדיקה, וניתן להשתמש בו כדי לדמות תלות חיצונית כמו DB או Web Services למשל בודקים ב-DevOps יכולים להשתמש ב-Mockito יחד עם Junit כדי לחזק את יכולות הבדיקה.

Junit

כלי פופולרי מבוסס  Java גם הוא מעולמות ה TDD המיועד לכתיבת מקרי בדיקה חוזרים (repeatable cases) על גבי Java Virtual Machine (JVM) הכלי מספק תכונות שונות כמו test suites, fixtures, test runners, JUnit classes.

בנוסף מציע API של TestEngine כך שניתן לפתח עליו Testing frameworks. כמו כן, הוא תומך ב-Continuous Integration.

דוגמא קצרה היא בדיקת סטטוס סרוויסים במוצר תוך שימוש ב-Assertions של Junit:

 Pytest

Testing Framework חזק וקל לשימוש עבור חברינו הפייתונים. פופולרי במיוחד לבודקים ב-DevOps המשתמשים בו כדי לכתוב ולהתאים בקלות טסטים על בסיס Python CLI, כך שבעזרתו ניתן לכתוב Test cases פשוטים בבדיקות UI, DB ו-API.

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

ישנם יותר מ-1000 פרוייקטים PyPI או תוספים שיכולים לתרום הרבה בתהליך ה-TDD.

דוגמא לטסט קצר (קרדיט לאתר pytest)

NUnit

אם אתם מפתחים את הטסטים שלכם ב-.NET או שפות הנתמכות כמו F#, C#, Visual Basic  תוכלו להשתמש ב-Framework הזה.

מבחינת פיצרים:

• Nunit 3 Test Adapterמאפשר לנו להריץ טסטים של NUnit 3 בתוך VS code
• ה-NUnit Engine מאפשר להריץ טסטים שפותחו על מספר Test Framework
• VS Test Generator עוזר לייצור IntelliTests ו-Unitests.

TestNG

Framework נוסף המיועד לביצוע בדיקות מגוונות מ Unitests ועד בדיקות אינטגרציה.

הפיצ׳רים העיקריים שמבדילים אותו מ-Junit  ו-Nunit

• אנוטציה של Unitests cases
• בדיקת Multi-threading
• בדיקת מבוססת נתונים (Data-Driven)
• מגוון רחב של plug-ins וכלים עבורIDEA, Eclipse, Selenium Maven, Ant ועוד.

הרבה בודקים בצוותי DevOps משתמשים בפיתוח מונחה בדיקות קבלה ATDD (Acceptance Test-Driven Development) ופיתוח מונחה התנהגות BDD (Behavior Driven Development) שמאפשרות הרצה חוזרת ונשנית של בדיקות תוך כדי בניית רכיבי תוכנה מורכבים.

Robot Framework

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

Gauge

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

לדוגמא: בחברה שבה אני עובד, המוצר נמצא על תשתית קוברנטיקס- K3s שהיא גרסה קלה של K8s לסביבות עם משאבים מוגבלים.

בקובץ הקונספט הבא בוחנים תסריט עבור התקנה על תשתית זו

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

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

תנאי קדם ל-continuous testing ב-DevOps

במהלך השנים האחרונות, התפתחו כלים לביצוע בדיקות אוטומטיות (Automated Testing) שהפכו לפופולריים מאוד בזכות יעילותם ומהירותם.

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

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

 Continuous Testing הוא תהליך אוטומטי גם הוא, אך הוא מהווה התקדמות נוספת לעומת הבדיקות האוטומטיות. בתהליך זה, הבדיקות מתחילות לפעול מיד לאחר שהקוד שולב (Continuous Integration) כאשר כל תסריטי הבדיקות כתובים מראש.

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

 דוגמא לתהליך Continuous Testing

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

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

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

ניתן לראות בתרשים את ההבדלים

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

הבודקים הם שומרי האיכות לאורך כל תהליך ה-.SDLC ניהול איכות התוכנה כולל הרבה מעבר למשימות אוטומטיות. לכן, כישורי תקשורת הם קריטיים עבור בדיקות יעילות.

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

חשיבות התרבות הארגונית ב DevOps

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

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

למשל תנאים מוקדמים לטובת Continuous Testing שהנחלנו בצוות שלנו:

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

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

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

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

היתרונות של chaos engineering ב-DevOps

הנדסת כאוס (Chaos Engineering) הינו מושג פופולרי בעולם הפיתוח וההנדסה כיום. ארגונים ומהנדסים רבים מזהים את היתרונות שביצירת "כאוס" מבוקר, כדי לאתר כשלים בפיתוח ולדעת כיצד להתמודד איתם בסביבת הייצור.

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

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

הטכניקה הזו מהווה דרך עבור בודקים בצוותי DevOps למצוא תחום אחריות ייחודי עבורם.

לפיכך אלה הן היתרונות:

1. שיפור יכולות הבדיקה של עמידות המערכת

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

2. חשיפה מוקדמת לכשלים פוטנציאליים

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

3. בדיקות בסביבה קרובה לייצור

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

4. שיפור באיכות התשתית

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

5. הכנה טובה יותר לתרחישי כשל

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

6. העצמת שיתוף הפעולה עם צוותי DevOps

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

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

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

8. אוטומציה של בדיקות כשל

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

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

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

שימושים ב-ChatOps ב-DevOps

ChatOps הוא גישה המשתמשת בערוצי תקשורת שונים – כמו מערכות לניהול Tickets וכלים לשיתוף פעולה כמו Microsoft Teams, Slack ו-Twist כדי ליצור מסגרת לסביבת שיתוף פעולה מלוכדת. התיאור הזה אינו עושה חסד עם מערך הטכנולוגיות המיועד לפתרון מהיר של בעיות בסביבת הייצור באמצעות שיתוף פעולה.

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

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

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

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

כלי ChatOps

מוצרים כמו  Slack ו-Microsoft Teams מאפשרים למשתמשים ליצור קבוצות ולפתוח ערוצי תקשורת, על מנת להקל על תקשורת קבוצתית מתוכננת.

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

לניהול תקלות ואסקלציות, יישומים כמו Splunk On-Call ו-PagerDuty מספקים מנגנון ניתוב לניהול תקלות. יישומים אלו קובעים את סדר העדיפויות של סוגי התראות ומוודאים שההתראה מגיעה לאנשים המוסמכים ביותר לפתרון התקלה. כלים אלו משתלבים עם מערכות הודעות מיידיות ומנועי התראות ליצירת גישה אוטומטית לקבלת התראות, ניתובן, תקשורת ופתרון תקלות.

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

יופי הגענו לחלק המעניין.

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

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

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

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

1. בדיקות אוטומטיות: בודקים יכולים להגדיר ולנהל אוטומציה של תהליכים שקשורים לבדיקות דרך כלי ChatOps. למשל הם יכולים להקים תסריטים שמבצעים בדיקות אוטומטיות על פי פקודות שנשלחות דרך כלים אלו.
2. תגובה מהירה לתקלות: כאשר תקלות מזוהות במהלך הבדיקות, הבודקים יכולים להשתמש בכלי ChatOps כדי ליידע את הצוותים הרלוונטיים במהירות ולנהל את תהליך תיקון התקלות.
3. שיתוף פעולה ותקשורת: בעזרת כלים אלה, הבודקים יכולים לשתף תוצאות בדיקות, לדון בבעיות ולשתף משוב עם חברי הצוות האחרים כמו מפתחים ומנהלי פרויקטים, מה שמסייע בתיאום מהיר ויעיל.
4. מעקב וניהול משימות: הבודקים יכולים לעקוב אחרי התקדמות הבדיקות, לנהל את המטלות השונות, ולוודא שהכל מתנהל לפי התוכנית. זה כולל קביעת סטטוסים, עדכון צוותים אחרים על התקדמות והקצאת משימות חדשות.
5. אינטגרציה עם כלים נוספים: הבודקים צריכים להכיר את האינטגרציות בין כלי ChatOps לבין כלים אחרים כמו Jira Jenkins, ו-GitLab הם יכולים לנהל ולפקח על תהליכים שונים, כולל השקת בדיקות אוטומטיות, בדיקת קוד, ותיאום עם כלים אחרים.
6. אופטימיזציה ושיפור תהליכים: באמצעות ChatOps הבודקים יכולים לנתח את האופן שבו התהליכים פועלים ולהציע שיפורים או אופטימיזציות שמבוססות על הנתונים שנאספו במהלך הבדיקות.

דוגמא בחברה אצלנו היא השימוש של Channel ייעודי ב-Slack לטובת תוצאות הרצה של Jobs  ב-Jenkins  שהם למעשה E2E tests

או למשל התרעה על פתיחת טיקט במערכת ה-Jira כתוצאה מתקלה שהתקבלה במהלך בדיקות אוטומטיות

את המאמר אני מקדיש לאל״מ יצחק בן בשט (בנבה) ז״ל הי״ד שנהרג במלחמת חרבות ברזל.