עולם האוטומציה הוא עולם די חדש בהייטק הישראלי, ובעקבות מגפת הקורונה, נדחף למרכז הבמה של עולם ההייטק. הרעיון של לחסוך כוח אדם ע"י תהליכים אוטומטיים קוסם לכל חברה, ובמיוחד קוסמת היכולת להריץ מספר רב של טסטים על מספר מכונות שונות וכך לקבל תשובה מהירה לגבי מצב המוצר.
אך בעולם האוטומציה, להבדיל מעולם התוכנה הקלאסי קיימת בעיה מאוד מרכזית, מחסור בידע.
בעוד בתוכנה אפשר להיכנס לכל אתר כמו Stack overflow ולמצוא פתרונות לבעיות מורכבות, בעולם האוטומציה יש קושי במציאת פתרונות לבעיות מורכבות ופשוטות כאחד. מצב זה נוצר מהרכב האנשים בעולם האוטומציה.
רוב אנשי האוטומציה מורכבים מ:
חוסר בידע גורם לחוסר יציבות של קוד האוטומציה מה שגורם לחוסר יציבות בטסטים.
בפועל, תהליכים אוטומטיים אשר אמורים לשקף מציאות, יוצרים חוסר ודאות בקרב הבודקים כי אם מריצים טסט מסוים 4 פעמים וחצי מהפעמים הוא עובר וחצי הוא נכשל, אז יש לנו בעיה כי לא ניתן להסיק מסקנות לגבי מצב המוצר.
מצב זה מקשה על תהליכים של CI/CD ועל העבודה הצמודה עם צוותי הפיתוח, במיוחד במקומות שעובדים בשיטת ה-AGILE.
הפחד מחשיפת חוסר היציבות של האוטומציה גורם ללא מעט צוותי אוטומציה לשמור את תוצאות הטסטים אוטומטיים לעצמם וכאשר טסט "נופל" פשוט מריצים אותו ידנית.
חוסר בידע גורם לחוסר יציבות של קוד האוטומציה מה שגורם לחוסר יציבות בטסטים |
בפועל עובדים כפול: גם משקיעים בכתיבת טסט אוטומטי וגם מריצים אותו ידנית.
חלק מצוותי האוטומציה שכן חושפים את תוצאות הריצות האוטומטיות עושים זאת באמצעות קבצי CSV, Excel או דוח אוטומטי כלשהו שנשלח למספר אנשים ונפתח פעם באף פעם.
עבודה בצורה זו, מקשה על השוואות בין ריצות שונות, מקשה על חקירה של בעיות, ובפועל, היא פשוט bad practice במיוחד לאנשים הנמצאים בעולם ההייטק שזהו עולם שדורש נתונים בזמן אמת וניתוחים באופן מהיר.
אז מה עושים?
ראשית אנחנו צריכים למצוא כלי שנוכל להציג בעזרתו תוצאות ואף להסיק מהם מסקנות בצורה קלה, נוחה, והכי חשוב, אוטומטית – ספויילר , זה לא EXCEL.
אחד הדברים החשובים שצריך להבין בעולם התוכנה והבדיקות, זה שבדרך כלל אין לנו צורך להמציא מחדש את הגלגל, רוב הסיכויים שמישהו כבר עשה את זה, ואפילו די טוב.
וכאן נכנסת SQL לתמונה. SQL הומצאה בשנת 1974 ולמעשה היא שפת מחשב הצהרתית לטיפול ועיבוד מידע בבסיסי נתונים יחסיים, אשר פותחה על ידי IBM והתבססה במקור על אלגברה רלציונית.
בשפה יותר פשוטה: SQL מאפשרת שליפת נתונים, עיבודם, עדכונם ויצירת טבלאות ושינוייהם.
הקמת שרת SQL וחיבור קוד האוטומציה אל מסד הנתונים, אלו הצעדים הפשוטים וישנן לא מעט דרכים וגישות כיצד לבנות מסד נתונים בצורה נכונה, אך בשלב זה נתייחס לטבלה אחת בלבד הקשורה לטסטים שלנו.
כעת נצטרך להחליט מה בעצם אנחנו רוצים לשמור: שם הטסט, ID של טסט, זמן התחלה, זמן סיום, מי הריץ, איזו מכונה, לאיזו חבילה היא שייכת, איזה סוג בדיקה היא מבצעת, שם הבראנץ'(אם יש) מספר גירסה.
בעצם כל המידע הזה הוא מידע שקל ליצור או כבר קיים לנו.
נשמור את המידע הזה במשתנים גלובליים הנשמרים ב-BeforeMethod או ב-AfterMethod ובעצם בסופה של ה-AfterMethod נשמור את המידע הזה במסד הנתונים.
אז מה יש לנו עכשיו?
בפועל יש לנו מידע, שקל לנו לגשת אליו בצורה פשוטה, מהירה, וניתן כעת לכתוב שאילתות המספקות לנו חבילות שונות של מידע כמו:
כמובן שכל הדברים שציינו זה פשוט מידע שמאוחסן בדרך אחרת, אז מה ההבדל בין אופן זה לבין השימוש ב-Excel?
ברגע שהמידע קיים ונגיש אז קל לנו לשחק איתו, קל לנו לשלוף אותו, ויותר מזה, ברגע שהוא כתוב בשפה שכיחה ובכלי אשר נמצא בשימוש רב בתעשייה, תהיו בטוחים שמישהו כבר חשב על דרך נוחה לעבוד עם המידע הזה, זוכרים מה אמרתי? לא צריך להמציא את הגלגל מחדש, אז נא הכירו - Grafana.
גרפאנה:
גרפאנה היא אפליקציה אינטרנטית לניתוח וויזואליזציה אינטראקטיבית של קוד פתוח אשר חוצה פלטפורמות.
במילים יותר פשוטות: זה כלי אינטרנטי המספק ייצוג ויזואלי למידע במסדי נתונים שונים מבוססי זמן.
בעצם זהו כלי המאפשר לקחת את המידע ששמור לכם במסד הנתונים (כמעט ולא משנה באיזה מסד נתונים) ולהציג את המידע הזה בזמן אמת, באתר אינטרנטי ע"י שאילתות.
דוגמא טובה לשימוש פשוט של גרפאנה הוא לוח ה: GAUGE שבעזרתו ניתן להראות מידע עדכני כלשהו, לדוגמא:
תוצאות הרצת אוטומציה האחרונה:
עוד מדד שניתן להציג בעזרת לוח זה, הוא מקום פנוי בכונן רשת כלשהו או זמן ממוצע לטסט, ולמעשה כל מידע שאתם חושבים שיעזור לכם להסיק מסקנות בזמן אמת על המצב של המערכת.
כאשר אנחנו מסתכלים על הלוחות שהצגתי, הם מציגים לנו מידע עכשווי, ואיתו קשה לנו בעצם לזהות טרנד, קשה לנו להבין מה זה אומר, 500 טסטים עברו? מתוך 600? מתוך 501? האם זה יותר טוב מההרצה הקודמת או פחות טוב?
למעשה אנחנו נרצה להשתמש בגרף המספק לנו את המידע של כל שאר ההרצות, בנייה של לוח כזה היא די פשוטה, אבל הניסוח של השאילתה הוא יותר קשה. מדוע זאת?
כמו שאמרתי בתחילת העמוד, גרפאנה מציג מידע מבוסס זמן, כלומר המידע בציר ה-X חייב להיות מורכב מחותמת זמן מלאה כלשהי לדוגמא: dd-mm-yyyy hh:mm:ss ולא תמיד קל להרכיב חותמת זמן ולעיתים זה דורש קצת חשיבה יצירתית.
לפניכם גרף מייצג של תוצאות ההרצות האחרונות:
בדוגמא זו, קל לראות שכמות הטסטים הכללית עלתה מ-609 ל-615 אבל יש יותר טסטים אשר נמצאים בסטטוס:To Review
מכיוון שגרפאנה עובדת עם ממשק אינטרנטי, אין צורך לשלוח דוחות קבועים, כל אחד שהמידע הזה מעניין אותו, יכול להיכנס לקישור ולראות את התוצאות העדכניות ובכך להסיק באופן מהיר מה מצב המוצר.
לגרפאנה עוד מספר רב של לוחות שונים וכלים שונים. ניתן לחבר את גרפאנה לשרת SMTP ולשלוח משם התראות לקבוצה ממוקדת של אנשים.
לדוגמא: אם נשאר לכם רק 10% מקום פנוי בכונן רשת, שלח אימייל לצוות הרלוונטי.
לגרפאנה כלים נוספים כמו LOKI העוזר לנטר, לסנן, ולהציג מידע רלוונטי מתוך קבצי לוגים שונים.
גרפאנה יכולה להיות מותקנת על ענן (בתשלום) או על מחשב ברשת הפנימית של החברה (בחינם).
בנוסף, הודיעה Grafana וAZURE- DEVOPS על שיתוף פעולה ביניהם ויצרת ממשק משותף, כך שיהיה ניתן להציג מידע מתוך המערכת לניהול באגים\טסטים\פיצ'רים של AZURE DEVOPS/TFS ישירות בגרפאנה בלי תיווך באמצע.
אז מה יש לנו כעת וכיצד זה עוזר לנו?
יש לנו מידע המאוחסן בצורה נוחה וקלה לשליפה ויש לנו כלי העוזר לנו לקחת את המידע הזה, ולהציג אותו בצורה שקל להסיק ממנה מסקנות ולזהות טרנדים.
אז מה עכשיו? כיצד זה עוזר לנו לשפר את האוטומציה שלנו?
בעולם התוכנה בכלל, ובעולם הבדיקות בפרט: אם אתה לא מנטר, אתה לא משפר ולא משתפר.
הצגה של מידע זה באופן זמן לשאר החברה, עוזרת למפתחי אוטומציה לרצות להיות יותר טובים, זיהוי מהיר של טרנדים ובעיות נזקף לזכות הצוות.
אם קוד האוטומציה שלכם יציב, והטסטים שלכם יצבים, כל שינוי המשפיע על התפקוד של המוצר, וכל באג הניתן לתפוס באמצעות אחד הטסטים האוטומטים, נתפס מיד.
אחד הדברים החושבים שצריך להבין בעולם התוכנה והבדיקות, זה שבדרך כלל אין לנו צורך להמציא מחדש את הגלגל, רוב הסיכויים שמישהו כבר עשה את זה, ואפילו די טוב.
|
כשאיש בדיקות מגיע בבוקר, פותח את המחשב נכנס לגרפאנה, ורואה שבין שתי הרצות יש הפרש של 30 טסטים, ניתן להסיק במהירות שיש בעיה, על מה היא משפיעה, וכמה היא חמורה.
הצגת היכולות של הצוות גם גורמת לצוותים שונים בחברה לרצות לעשות איתכם פרויקטים משותפים ולהיעזר ביכולת הצוות.
כיצד זה משפר אותנו בתור אנשי אוטומציה?
כאשר אנו יודעים היכן אנחנו עומדים, והיכן יש לנו בעיות, אנחנו יכולים להתחיל לנסות לפתור אותם.
ההבנה של "מהי הבעיה" היא למעשה חצי מהפתרון. זה תקף לדברים קטנים וגדולים כאחד:
פונקציה לא יציבה? פתרון לא כוללני מספיק? קוד כפול? את כל אלו ניתן לשפר ע"י בדיקה קבועה של מצב המערכת שלכם שמשקף את מצב האוטומציה.
זמן ריצה ארוך של אחד מסט הטסטים שלכם, יכול לחשוף פונקציות לא יעילות שלוקחות הרבה זמן שניתן למצוא להן תחליף יותר מהיר וטוב.
ניתן למצוא טסטים לא יציבים באופן מהיר, להבין מדוע הם לא יציבים ולשפר אותם.
אם הטסטים שלכם יציבים, אתם משקיעים פחות זמן בתיקון טסטים, וכך נוצר מצב שמתפנה לכם זמן לחקור כלים חדשים, לרכוש ידע חדש, לחשוב על טסטים חדשים ועל פרויקטים חדשים לחברה.