את הפוסט הזה – Automation Stack החלטתי לכתוב בעקבות בקשות רבות וצורך שראיתי בשיטוטיי הרבים בקבוצות ופורומים שונים, לעיתים ישנן שאלות שחוזרות על עצמן בפורומים מקצועיים או חברות בהן אני מגיע לייעוץ לגביי נושא תשתיות האוטומציה, פרוייקטים שמהם בונים טסטים אוטומטיים, כשמישהו שואל לגביי זיהוי אלמנטים בצורה חכמה וריצה על Docker באותה שאלה, זה נשמע כאילו הוא לא לגמרי מבין את ה-Stack אליו הוא רוצה להיכנס
בפוסט זה אני מעוניין לעשות קצת סדר בדברים ולהרחיב על אותו Stack של אוטומציה, נבין כיצד ארכיטקטרה אמורה להיראות ומה היא אמורה לכלול.
מכיוון שזהו נושא מאוד גדול ולא ניתן כאן לכסות את כל ההיבטים של כל אותן פלטורמות שונות (למשל ארכיטקטורת אוטומציה למערכת בנקאית לאו דווקא תהיה דומה לכזו במערכת של Cloud Services), לכן אתן הדוגמא אולי הפופולרית ביותר: Web UI Stack.
אז בואו קודם כל נבין מה זו בכלל המילה הזו – Stack שמשתמשים בה לא מעט בתעשייה שלנו (למשל Full Stack Test Automation או Full Stack Developer).
ה-Stack הוא פתרון (Solution) בפיתוח תוכנה, הוא מורכב למעשה מכמה כלים \ ספריות, יש כאלו הקוראים להם פיצ'רים, יש כאלו שקוראים להם תתי מערכות, והאוסף שלהם מייצר לנו פתרון מושלם שאינו נתמך במערכות תוכנה אחרות, מה שנקרא (Standalone).
ישנם Stacks למערכות Backend או Frontend למשל או גם Stacks לאוטומציה. כך כשמחפשים משרה לתפקיד Full Stack Test Automation הכוונה היא למישהו שיודע לפתח ב-Stacks שונים, למשל מישהו שיודע לכתוב תשתיות אוטומציה שיתמכו ב-Web UI (למשל עם Selenium או Cypress) וגם שיתמכו בקריאות API בכדיי לבדוק את צד השרת, כמו כן יכיר את העולמות של האוטומציה על אפליקציות Mobile או Desktop (למערכות Back-Office וכו')
אז כאמור הדוגמא של Stack שאציג לכם כאן הינה מעל ה-Web UI (בשל העובדה שהיא הפופולרית שקיימת כיום בתעשייה), שימו לב ל-Stack הבא:
אז בואו נפרט עליו קצת, אנו רואים ממה הוא מורכב בדוגמא הזו, מכמה קומפוננטות שמייצרות לי Stack של אוטומציה שהוא הפתרון שלנו לבדוק את האפליקצייה (ה-Web-ית במקרה שלנו).
Programming Language:
טוב, זה לא סוד כי פיתוח אוטומציה מחייב אותנו לשלוט בשפת תכנות אחת לפחות ורצוי אחת כזו שתתמוך בעקרונות תכנות המונחה עצמים (Object Oriented), בעולם האוטומציה שפות התכנות השולטות הן Java, Python, C#, Javascript , יצא לי לראות קצת בשוליים את Ruby, אבל אפשר להזניח אותה מבחינת הפופולריות. שפות התכנות הינן הבסיס לכל Stack של אוטומציה, מהן אנו מייצרים את הברזל, המלט ליצירת בטון והלבנים שיבנו לנו את הפרוייקט.
לא מעט פעמים נשאלת שאלה בקבוצות המקצועיות מצד אנשי QA שמעוניינים לללמוד אוטומציה: "איזו שפת תכנות עליי ללמוד ?", התשובה מורכבת מכמה פרמטרים:
- השפה הפופולרית ביותר בשוק – למרות שזה אינדקטור חשוב, צריך לציין כי מה שפופולרי ביותר היום (שזו java), לא בטוח שיהיה הפופולרי ביותר מחר.
- קלות למידת השפה – עיקר התחרות שאנשים מתנצחים בפורומים (לא רק בארץ) היא בין Java לבין Python כאשר חסידי Python אומרים שעדיף ללמוד שפה זו ראשונה כי היא קלה יותר מהשנייה. אני טוען הפוך, בגלל ש-Java היא שפה קשה יותר ללמידה (אבל בואו לא נגזים, לא מדובר פה במדע טילים) עדיף דווקא להתחיל איתה, כך יודעים טוב יותר לתכנת.
- טענה נוספת: "השפה בה עובדים במקום עבודתך", שזה נחמד, אבל אף אחד לא מבטיח כי אותו בן אדם ימשיך לעבוד שם גם מחר (בדומה לסעיף 1), מה גם שישנם מקומות בהם כותבים בכמה שפות צוותי פיתוח שונים.
- עוד טענה: "שפה שיש לה הרבה דוקומנטציה ודוגמאות קוד" – כיום לכל שפה יש טונות של מידע, קורסים, רפרנסים ותשובות ב-Stack Overflow, כאן לא ניתן להשוות למי יש גדול יותר.
- "לאותה שפה שיש בה פתרונות האוטומציה הרבים ביותר" , מבין את הטענה הזו, והיא גם נכונה לגמרי, העניין הוא שכמו בסעיף הקודם, לכל אותן שפות שרשמתי מעל יש הרבה פתרונות כאלו ואחרים, פתרונות שמגיעים בתצרה של Dependency ב-Java , מודולים שונים בפייתון, NPM Packages ב-Javascript ,יש Nugets ב-#C ו-Gems ב-Ruby
בסופו של דבר, אני טוען כי בחירת השפה זו לא החלטה הרת גורל. ברגע שיודעים לעבוד עם שפה אחת, לא זה כזה סיפור לעבור לשפה אחרת, אבל מצד שני גם לא מאוד טריביאלי, בכל זאת צריך להתחשב בניהול זיכרון שונה, הקצאת משאבים, סביבת פיוח וכו'.
כשבאים להטמיע פרוייקט אוטומציה בחירת שפת הפיתוח, למרות או בשל היותה הבסיס לכל ה-Stack, היא דווקא תהיה האחרונה ב"שרשרת המזון" בבחירות שלנו, כי השפה תיגזר בד"כ מאותו פריימוורק, הפריימוורק ייגזר מהצרכים, הטכנולוגיות, תמהלי הצוות ועוד.
Build / Package Manager:
ה-Package Manager זהו אותו כלי שיודע לנהל את ספריות הקוד איתם אנו נרצה לעבוד בפרוייקט שלנו, לכל שפה ולכל סביבה יש את ה-Package Manager משלה. לעיתים הכלים הללו מגיעים כחלק מחבילה גדולה יותר היודעת גם לבנות (Build) את הפרוייקט למוצר מוגמר או להרצה בסביבות שונות, דוגמא לכך הוא ה-Maven עימו משתמשים ב-Java , הוא גם בונה לנו את הפרוייקט וגם מנהל לנו את ספריות הקוד החיצוניות (Dependencies) ע"י קובץ הגדרות שנקרא: pom.xml (ה-pom הוא קיצור של Project Object Model).
אם החלטנו לכתוב את הפרוייקט ב-#C למשל, אז יש לנו את ה- NET Framework שזוהי סביבת הפיתוח ובה כלים לבניית תוכנה כמו ה-MSBuild וכן את הכלי: Nuget Package Manager שינהל לנו את ספריות הקוד החיצוניות (למשל Selenium, Appium וכו'…)
ב-Python אנחנו נעבוד עם ה-Python Package Index (או בקיצור: Pip) כדי להוריד ולשייך את ספריות הקוד אלינו לפרוייקט
וב-JS יש לנו את ה-NPM שמנהל את ספריית התוכנה הגדולה מבין כולם (לא שה עושה עלינו רושם באוטומציה :-))
לכל מנהל ספריות יש מנוע חיפוש למציאת הספרייה עימה נרצה לעבוד, ישנם כאלו חיצוניים, כמו עם Maven אשר משתמש בממשק web וכאלו עם מנועי חיפוש פנימיים, כמו ה-Nuget Package Manager שהוא לטעמי הנוח מבין כולם (מייקרוסופט, נו מה ?)
מנהל הספריות אחראי לא רק למצוא עבורינו את ספריות הקוד הרלוונטיות, איתו אנחנו יכולים גם די בקלות לנהל את גרסאות הספריות הללו, למשל Selenium גרסת 4.0 הייתה גרסה מלאת בעיות, לא פלא שמיד אח"כ הויאו גרסאות נוספות אחריה, המעבר בין גרסה לגרסה וניהול קבצי המקור (jars ב-Java או dll ב-#C וכו')הוא קל ופשוט עם מנהל הספריות
Testing Framework:
את ה-Testing Framework או בשמו המלא: Unit Testing Framework אנו נבחר בהתאם לשפה שאנו נבחר בה, אותו פריימוורק ייתן לנו לכתוב את המחלקות של הבדיקות בצורה נוחה (הרבה) יותר, לפריימוורקים הללו יש יתרונות עצומים לעבודה כשאנו באים לכתוב בדיקות אוטומטיות והם חלק בלתי נפרד כל Stack של אוטומציה, הנה כמה יכולות שה-Testing Frameworks נותנים לנו ולא משנה באיזו שפה בחרנו לעבוד:
- ע"י שימוש ב- Annotations / Attributes ניתן להגדיר מתודות ברות הרצה (Test) על ידי מנוע ההרצה של אותו פריימוורק, מתודות שירוצו לפני כל הטסטים, אחרי כל הטסטים, לפני כל טסט, אחרי כל טסט ועוד.
- פריימוורקים אלו יאפשרו לנו להגדיר בדיקות בשיטת ה-Data Driven Testing כאשר יחזרו שוב ושוב על אותו Test ויכניסו אליו כל פעם Data אחר
- עם הפריימוורקים הללו נוכל להריץ שוב טסטים שנכשלו לפי מספר פעמים שנגדיר מראש,
- הם יספקו לנו דוח ריצה (אמנם לא מספיק מופרט לטעמי אבל בכל זאת)
- איתם נוכל להכניס בדיקות (Assertions) לאותן פעולות אוטומטיות שיגיעו מספריות קוד אחרות כמו Selenium / Appium /. REST API וכו'
- על ידי הפריימוורק ניתן לשלוט בכל נושאי ההרצה, את מי אנו נריץ, את מי לא, נוכל לחלק לקבוצות של הרצה ולהגדיר טסטים תחת תגיות
- נוכל לעבוד עם Event Listeners באותם פריימוורקים כי הרבה מהם תומכים בזה
- עם אותו Test Framework נוכל להריץ את סוויטות הבדיקה שנרצה דרך ה-CMD או דרך כלי CI/CD כזה או אחר כמו כן יש את היכולת כאן להגדיר (בין היתר) לרוץ באופן מקבילי (כמה instances באותו פרק זמן)
לכל שפת תכנות יש את הפריימוורקים משלה וכולם טובים !
ל-Java יש את ה-TestNG שהוא מאוד פופלרי בקרב מפתחי האוטומציה, ואת ה-Junit הפופולרי בקרב מפתחי מוצר שעובדים איתו בעיקר עם Unit Testing
ל-#C יש את MSTest שמגיע כבר Built in בתוך פרוייקט ה-Unit Testing , כמו כן את ה-NUnit הפופורלי ביותר (שבגרסת ה-VS האחרונה כגם מגיע כחלק אינטגרלי מפרוייקט Testing) והשלישי הוא ה-xUnit הוורסיטלי
ל-Javascript יש את ה-Jasmine הוותיק, ה-Mocha הפופולרי וה-Jest החדש (יחסית)
ל-Python יש את ה- Unittest החביב ואת ה-PyTest הפופולרי יותר עם מגוון עצום של פיצ'רים
Code Libraries
ספריות הקוד הנמנות כאן הן ספריות של Selenium, של Appium, של WinAppDriver, של Restsharp או HttpClient וכו', באופן מצחיק, ספריות אלו זוכות לתשומת הלב הרבה ביותר בקרב מפתחי אוטומציה, וזה למרות שב-Stack של אוטומציה שבנוי כהלכה, ספריות אלו אמורות להוות בין 10% ל-15% מכלל הפרוייקט.
ספריות אלו נועדו לחסוך לנו עבודה רבה, ובמקום להמציא את הגלגל מחדש בכל פעם, אנו פשוט נשתמש במימושים שונים שכתבו לנו אנשים (מוכשרים) אחרים.
ישנן ספריות אשר תומכות במגוון של שפות (כמו ה-Selenium או ה-Playwright ואחרים) וישנן כאלו שהן ממומשות ספציפית לשפה מסויימת, למשל ה-Restsharp הוא לשפת #C ואילו המקבילה שלה: Rest Assured היא ל-Java
ה-Final Four הזה של Programming Language, Package Manager, Testing Framework , Code Libraries הוא למעשה ה-Core Stack שלנו, ע"י שילוב של כל ארבעת אלו נוכל באופן אינטילגנטי ומקורי לבנות את ה-Stack שלנו שיכתב בהתאם לצרכים שלנו ויהיה לחלוטין תפור על מידתינו.
Test Data
את הקומפוננטה הזו אינני רואה הרבה בפרוייקטי אוטומציה וזה קצת חבל לטעמי, אחד מה-Best Practices שאני מאמין בהם הוא להריץ בדיקות כם Data שונה, Data שיהיה רנדומלי. כאשר הנתונים יישארו אותם נתונים לאורך כל ההרצות, הסיכויים למצוא בעיות קטנות משמעותית.
עם יצירת Test Data בפרוייקט שלנו אנחנו יכולים להגיע די בפשטות לווליומים (volume) גדולים של מידע שנרצה להעמיס על המערכת ולבדוק אותה בזמני עומס למשל (נקראים Volume Testing).
כלים ליצירת Data עוזרים לנו גם לבדוק את ה-Database ולא רק את הפונקציונליות של השרת, ג'ינרוט של מידע כזה יכול להתבצע באופן ידני – מה שיגזול מאיתנו המון משאבים ועצבים, ע"י כלים מתוכננים כמו למשל ה-Mockaroo הנפלא ניתן ליצור את המידע במגוון רחב של פורמטים: CSV, SQL, JSON, Excel, XML ועוד הרבה… שירותים אלו גם מספקים לנו API כך שאפילו את הפעולה של יצירת המידע (הגדרות כמות השורות, עמודות, פורמט…) ניתן לבצע בעזרת קוד ולהתייחס לזה בפרוייקט שלנו.
Logging / Reporting
בואו נשים את הקלפים על השולחן, פרוייקט אוטומציה המבוסס על דיווחים ישירות מהפריימוורק של הבדיקות (Jest / Pytest / Nunit, TestNG…) הוא מעפאן. חסרים פיצ'רים רבים שכל כך הכרחיים בבואינו לחקור את כשלונות הבדיקות שלנו לאחר ריצה לילית.
תראו, אחד הדברים הכי מעצבנים שיש לנו באוטומציה הוא להגיע בבוקר למקום העבודה ולהתחיל לחקור את הנפילות שהיו בזמן הריצה הלילית. הרעיון והאתגר הוא לצמצם את זמני החקירה. מקרה בדיקה שנכשל יכול להיכשל בגלל באג במערכת (יייישששש מצאנו באג), בגלל בעיה סביבתית או באג אצלינו בקוד של האוטומציה, כשאנו מקבלים Report המציג את כל הכשלונות מריצת הלילה נתחיל לחקור, ככל ש-Report יהיה איכותי יותר, כך נצמצם את זה החקירה. עם הזמן נוצרים פיצ'רים חדשים כל הזמן למערכות הדוחות, כאלו שבסופו של דבר מקלים עלינו את החיים וחוסכים לנו זמן יקר. אם בעבר התלהבנו מזה שהצלחנו לחבר צילום מסך בזמן כישלון או לכידת וישאו של הרצת מבקרה הבדיקה, אז כיום ישנם כלים הלוכדים את העמוד עצמו (DOM Snapshot) בזמן כישלון, ראוי לציון ה-snapshot המובנה של Cypress וה-trace של Playwright המצויין.
עם התפתחות ה-AI וה-Machine Learning אנחנו רואים יותר ויותר מערכות דוחות אשר יודעים כבר לסמן לנו מקרי בדיקה שבירים (Flaky Tests) ומציעים דרכים לתיקון.
חלק מכלי אוטומציה גם מגיעים עם מרכות של דוחות המספקים אנליטיקות מורכבות וחיתוכים שונים של הרצות, ראוי לציון כאן ה-Katalon Analytics וכן הכלי המובנה של TestProject
Execution Platform
החלק הזה של ה-Stack אמנם פחות קשור ישירות לפרוייקט האוטוציה ויותר אל הסביבה עליה אנחנו הולכים להריץ את הבדיקות שלנו, אך הוא חשוב מעין כמוהו, בחלק הזה, מפתחי האוטומציה יכולים לתת את המפתחות לאנשים ה-DevOps שיטפלו בסביבת ההרצה, או שיעשו זאת בעצמם (או שילוב של השניים), תלוי חברה, תלוי צוות, תלוי הדינמיקה הבין צוותית במחלקת ה-R&D
הרצה מקומית של הבדיקות שלנו תתבצע רק למטרת הפיתוח (טסטים חדשים למשל) או למטרת ה-Debug, אחרת אין שום טעם להריץ את האוטומציה על אותו מחשב מקומי בו אנו מפתחים, עונים למיילים, ומזמינים בתןביס…
ניתן להריץ את כל סוגי הבדיקות שלנו (Health Check, Sanity, Regression…) על מחשבים מרוחקים פיזיים, וכל על סביבות ווירטואליות.
בנושא הווירטואליזציה, ניתן להשתמש בטכנולוגיות (יחסית) ישנות כמו ב-HypreV , VMWare , VirtualBox וכו'… או להשתמש בטכנולוגיות החמות יותר בשוק שיש בשוק היום Docker , Kubernetes עם יצירת Image משל עצמנו או שימוש בכאלו מוכנים (דוגמת ה-Zalenium) מהם ניתור קונטיינרים עליהם נריץ את הבדיקות.
חושב גם לציין כי פרוייקט האווטמציה שלנו לא יהיה שונה משאר הפרוייקטים בצוות ה-R&D אליו אנו משוייכים, ועל כן גם הפרויקט שלנו יהיה חלק מה-Continuous Integration Pipeline של האירגון ועל כן job או task חדש יהיה רשום על שמנו בין היתר…
לסיכום,
ממה שיצא לי לחוות, בחברות שונות וצוותים שונים, ה-Automation Stack משתנה, ולעיתים (בעיקר באירגונים גדולים) הצוותים עובדים בכמה Stacks ולעיתים גם יש לא מעט בלגאן שם, עד שמגיע מנהל QA ועושה שם סדר בדברים. ארכיטקטורת האוטומציה שלנו אמורה לכלול Stack שאנו נבחר בקפידה עוד לפני כתיבת שורת קוד אחת, וזה לאחר מחקר והתייעצויות של הכלים המתאימים לנו ביותר, שימו לב, לא רשמתי כאן הכלים הטובים ביותר כי אין דבר כזה, יש משהו שהכי מתאים לנו ולאחרים אלו יהיו כלים אחרים ב-Stack
בהצלחה
סאיד
