Posts

Allure Reporter - הטמעת דוחות ריצה באוטומציה

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

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

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

Stop using time.sleep everywhere!

Image
I think that almost every automation infrastructure that I have seen has the time.sleep() method at least once.
Sometimes it comes from laziness and sometimes from a lack of knowledge, but I believe that in at least 90% of the times, sleep methods should not appear in our code. Why do we need the sleep method at all? In the e2e automation world, when we try to automate the AUT (application under test), we sometimes depend on processes we do not control. For example, as automation developers, when we click on a button to switch pages in the AUT, we don't have control on the pace that the new page is loaded, it depends on many variables like the network speed and communication with third party systems (like databases and servers).
When the automation developer starts an operation that can take time (like the page loading in the example) and continues his test flow right after, the test may fail due to missing information of the application. for example, if we try to click on button…

תבניות עיצוב ואוטומציה | Template Method Pattern

Image
בתור מפתחי אוטומציה (ותוכנה בכלל) אנחנו נתקלים בלא מעט בעיות..

אנחנו לא זוכרים syntax מסוים, נזרק לנו exception שאנחנו רואים פעם ראשונה או אפילו שגיאת קומפילציה שאנחנו לא מכירים.

מה אנחנו עושים כאשר דבר כזה קורה לנו? לרוב נפנה לדר' גוגל... הרי כל דבר שקרה לנו כבר קרה למישהו אחר בעבר, ובכל בעיה בה נתקלנו, אנחנו כנראה לא הראשונים שנתקלנו בה.
ב-95% מהמקרים גוגל אכן פותר לנו את הבעיה.

מה קורה כאשר אנחנו נתקלים בבעיית Design בקוד שלנו?
אנחנו לא בטוחים כיצד לחבר את ה class-ים או שאנחנו יודעים שמה שעשינו "לא כל כך יפה" אבל אנחנו לא בטוחים כיצד לעשות זאת נכון.

לשם כך נוצרו Design Patterns!
Desing Pattens הן הפתרונות לבעיות שלנו בעיצוב התוכנה - אלו מעין תבניות פתורות וכל מה שנשאר למשתמש זה להתאים אותן למקרה שלו.

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

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

באמצעות template method pattern נוכל לבצע מספר מימושים שונים לאותו שלד של אלגוריתם.

במילים פשוטות…

3 דרכים לייצוב הבדיקות האוטומטיות שלנו

Image
כל אחד מאיתנו חווה את זה.
כתבנו test אוטומטי, דיבגנו, הכל עבד מצוין. הרצנו פעם אחת, וזה עבר באופן חלק. אבל מתי שהוא, אולי אחרי כמה פעמים שהרצנו את זה באופן ידני ואולי כשזה רץ באופן אוטומטי בתהליך CI/CD זה או אחר, הבדיקה פתאום נכשלת.
הנושא הזה עייף וגרם לייאוש של עשרות בודקים ומפתחים. למה אותה בדיקה פעם נכשלת ופעם עוברת מבלי כל סיבה הנראת לעין?
הדבר שאנחנו מדברים עליו כאן נקרא Flaky Tests והוא דבר חם מאוד בעולם האוטומציה היום. מה זה Flaky Tests? flaky tests או test flakiness הוא ביטוי המיצג חוסר יציבות של בדיקות אוטומטיות. אם אותה בדיקה, באותם תנאים פעם אחת עברה ופעם אחרי נכשלה, הבדיקה היא flaky.


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

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

אנחנו חייבים לשים לב שאיננו בודקים באמצעות בדיקת E2E לוגיקה שיכולה להבדק ברמה נמוכה י…

בדיקות לתשתית האוטומציה שלנו | סוגי הבדיקות

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

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

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


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

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

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

בדיקות לתשתית האוטומציה שלנו | למה?

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

בין השאלות היו, "מי כאן כותב אוטומציה?" (כמעט כל הקהל הרים את ידו)
"מי כאן מגדיר את עצמו כמפתח?" (ידיים בודדות)
והשאלה האחרונה הייתה - "מי כאן כותב בדיקות לתשתיות האוטומציה שלו?"

הייתה דממה בקהל. מתוך כ-60 אנשים אף לא יד אחת.

הנתון הזה לא הפתיע אותי במיוחד, שהרי זהו לא דבר טריוויאלי (לפחות לא כרגע).


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

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

אוטומציה נכונה יותר | שימוש בקבצי קונפיגורציה | קבצי Json

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

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

למה חשוב להשתמש בקבצי קונפיגורציה?המבנה של קבצי JsonFactory Design Pattern דוגמה ב C# לשימוש בקבצי Json כקונפיגורציה בדוגמה אציג מקרה עליו כבר דיברנו בעבר - החלטה של הדפדפן עליו ארצה לבצע את בדיקות האוטומציה של המערכת הנבדקת וה-URL של האתר אליו נרצה לגלוש לצורך ביצוע הבדיקות

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


1. התרחיש הראשי שלנו כאשר אני כותב תרחישי אוטומציה (וקוד בכלל) אני אוהב לכתוב את כל הקוד לפי ההתנהגות (Outside-In). זאת אומרת, שקודם כל אכתוב את התרחיש (כאשר הפעולו…

אוטומציה נכונה יותר | שימוש בקבצי קונפיגורציה | C# Settings

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

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

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

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




בתרחיש ניתן לראות שכתובת האתר אליו התרחיש גולש (http://google.com) היא "Hard Coded", זאת אומרת, כתובה ישירות אל תוך הקוד.

מה הבעיה בכתיבה Hard Coded? Hard Coding נחשב ל anti-pattern, לא יעיל ולא פרודקטיבי, והכי חשוב - עלול לגרום לנו ללא מעט בעיות עתידיות.
DRY - כאשר אנחנו כותבים משתנים וקבועים מסוימים אנחנו מסכנים את הקוד שלנו בחילול עיקרון (DRY (Do Not Repeat Yourself, שאומר שאסור לנו לחזור על עצמנו בקוד, בשום פנים ואופן! לא נרצה לכתוב שום שורה פעמיים! העיקרון מעודד אותנו להוציא כל פונקציונליות, פשוטה ככל שתהיה, לפונקציה נפרדת, וכך למנוע כתיבה חוזרת של קוד, ושל משתנים.Maintainability - …

תבניות עיצוב ואוטומציה | Factory Pattern

Image
בתור מפתחי אוטומציה (ותוכנה בכלל) אנחנו נתקלים בלא מעט בעיות..

אנחנו לא זוכרים syntax מסוים, נזרק לנו exception שאנחנו רואים פעם ראשונה או אפילו שגיאת קומפילציה שאנחנו לא מכירים.

מה אנחנו עושים כדבר כזה קורה לנו? לרוב נפנה לדר' גוגל... הרי כל דבר שקרה לנו כבר קרה למישהו אחר בעבר, ובכל בעיה בה נתקלנו, אנחנו כנראה לא הראשונים שנתקלנו בה.
ב-95% מהמקרים גוגל אכן פותר לנו את הבעיה.

מה קורה כאשר אנחנו נתקלים בבעיית Design בקוד שלנו?
אנחנו לא בטוחים כיצד לחבר את ה class-ים או שאנחנו יודעים שמה שעשינו "לא כל כך יפה" אבל אנחנו לא בטוחים כיצד לעשות זאת נכון.

לשם כך נוצרו Design Patterns!
Desing Pattens הן הפתרונות לבעיות שלנו בעיצוב התוכנה - אלו מעין תבניות פתורות וכל מה שנשאר למשתמש זה להתאים אותן למקרה שלו.

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

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


מה זה Factory Pattern? תבנית העיצוב Factory היא אחת מתבניות העיצוב הנפו…

אוטומציה זה אחלה, אבל מה עם לוגים?

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

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

תבניות עיצוב ואוטומציה | Facade Pattern

Image
בתור מפתחי אוטומציה (ותוכנה בכלל) אנחנו נתקלים בלא מעט בעיות..

אנחנו לא זוכרים syntax מסוים, נזרק לנו exception שאנחנו רואים פעם ראשונה או אפילו שגיאת קומפילציה שאנחנו לא מכירים.

מה אנחנו עושים כאשר דבר כזה קורה לנו? לרוב נפנה לדר' גוגל... הרי כל דבר שקרה לנו כבר קרה למישהו אחר בעבר, ובכל בעיה בה נתקלנו, אנחנו כנראה לא הראשונים שנתקלנו בה.
ב-95% מהמקרים גוגל אכן פותר לנו את הבעיה.

מה קורה כאשר אנחנו נתקלים בבעיית Design בקוד שלנו?
אנחנו לא בטוחים כיצד לחבר את ה class-ים או שאנחנו יודעים שמה שעשינו "לא כל כך יפה" אבל אנחנו לא בטוחים כיצד לעשות זאת נכון.

לשם כך נוצרו Design Patterns!
Desing Pattens הן הפתרונות לבעיות שלנו בעיצוב התוכנה - אלו מעין תבניות פתורות וכל מה שנשאר למשתמש זה להתאים אותן למקרה שלו.

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

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


בהמשך לסדרה שלנו שלנו על תבניות עיצוב ואוטומציה, ה Pattern…

תבניות עיצוב ואוטומציה | Page Object Pattern

Image
בתור מפתחי אוטומציה (ותוכנה בכלל) אנחנו נתקלים בלא מעט בעיות..

אנחנו לא זוכרים syntax מסוים, נזרק לנו exception שאנחנו רואים פעם ראשונה או אפילו שגיאת קומפילציה שאנחנו לא מכירים.

מה אנחנו עושים כדבר כזה קורה לנו? לרוב נפנה לדר' גוגל... הרי כל דבר שקרה לנו כבר קרה למישהו אחר בעבר, ובכל בעיה בה נתקלנו, אנחנו כנראה לא הראשונים שנתקלנו בה.
ב-95% מהמקרים גוגל אכן פותר לנו את הבעיה.

מה קורה כאשר אנחנו נתקלים בבעיית Design בקוד שלנו?
אנחנו לא בטוחים כיצד לחבר את ה class-ים או שאנחנו יודעים שמה שעשינו "לא כל כך יפה" אבל אנחנו לא בטוחים כיצד לעשות זאת נכון.

לשם כך נוצרו Design Patterns!
Desing Pattens הן הפתרונות לבעיות שלנו בעיצוב התוכנה - אלו מעין תבניות פתורות וכל מה שנשאר למשתמש זה להתאים אותן למקרה שלו.

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

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

בפוסט של היום -  Page Objects

דרישות קדם: אוטומציה באמצעות NUni…