חברים, שיהיה לכם רבעון מוצלח ושבוע טוב לכולם.
את הטור הזה אני רוצה להקדיש בעיקר למפתחי האוטומציה שבינינו, הנתקלים בבעיות יציבות בתסריטי הבדיקות אוטומטיים שלהם.
בהזדמנות זו אני רוצה לדבר על מס' בעיות ואתגרים שעומדים בפנינו ועל דרך ההתמודדות שלנו איתם בנושא אוטומציה.
אכן, שככל שאנחנו מתפתחים וצוברים יותר ידע, וניסיון, מוצאים פתרונות שונים לבעיות בתחום האוטומציה. אבל אל תשכחו שגם הטכנולוגיה מתפתחת ולכן אנחנו תמיד צריכים להדביק את הפער.
איזו טכנולוגיה? - הכול! החל משפות, ספריות שונות, גרסאות, כלים אוטומטיים
במקרים רבים, אנשים בתעשייה שלנו וגם ואני...נתקלים בבעיות בהרצת תסריטי הבדיקות אוטומטיים ולפעמים זה קורה בגלל הסתמכותנו על Data.
כלומר, במקום לפתוח מאין Feature Fag או לשנות את ההרשאה של אותו חשבון דרך מערכת אדמיין מקומית או בסיס נתונים אנחנו מעדיפים ברמת הממשק משתמש לשלוט באזורים מוכרים היטב ונמנעים מכניסה לאזורים אחרים במערכת שירימו עלינו קשיים.
עקב כך, אנחנו מייצרים חשבונות סטטיים עם הרשאה מוגדר ראש או עם פיצ'ר מסוים שגם פתחנו מראש בבסיס
בשלב הרצת הבדיקות ידניות כמעט ולא ניתקל בשינויים בבסיס נתונים או במבנה שלו ובמקרה הצורך ניגש ידנית לבסיס נתונים או למערכת אדמיין המקומית ונגדיר מחדש מה שנצטרך לצורך הרצת תסריטי הבדיקות.
יש לציין כי בתחום האוטומציה רמת הסיכון גבוהה משמעותית מאחר שהיא עלולה להכשיל לנו חלק ניכר מתסריטי הבדיקות.
ואם לא די בכך שאנו מגדירים את החשבונות ה-סטטיים האלו מראש.. הרי שאנו גם יוצרים תסריטי בדיקות נוספים וב-flows שונים לגמרי שרצים אחרי אותם תסריטי בדיקות כאשר הם מורצים מאותו חשבון... ובכך ייווצר אפקט דומינו ומספר תסריטי בדיקות שיכשלו ויכשילו זה את זה.
לכן, מוטב שנמנע מלהתבסס על Data קיים.
מי שסבור כי במקרה זה יוכל לפנות ל-Api ובכך בכל פעם שייווצר חשבון אוטומטי בעזרת הפיצ'רים שרוצה לפתוח יתקל בבעיה במקרה ש-Api חסום ומוגן הרמטית.
במקרים מסוימים, ניתן יהיה לבצע איזשהו מעקף... ובמקרים אחרים לא יתאפשר ונאלץ לבקש מפיתוח ליצור Api' ים ייעודיים שיאפשרו את התנאים המקסימליים להרצת תסריטי בדיקות אוטומטיים ופנייה לבסיס נתונים ומערכות שונות בארגון והגדרה והדלקה של כל מה שנרצה.
זכרו – אל תקוו שזה יהיה קל יותר, תקוו שזה יהיה טוב יותר.
אני מאחל לכם המשך שבוע נעים שקט ורגוע
ושלעולם לא תצעדו לבד