השקעה והטמעה של פרוייקטי אוטומציה היא אתגר לא פשוט. ישנן חברות רבות אשר לא מכירות בחשיבותן של הבדיקות האוטומטיות וישנן כאלו שלא יודעות להעריך נכון את הגישה הנכונה ואופן הטיפול באספקטים השונים שבפרוייקט. במקרים כאלו מומלץ להתייעץ עם מומחה לתחום שייתן הכוונות והקמה של שירותי אוטומציה באירגון.
בנוסף לקורסי ההדרכות שאני מעביר, שירותיי כוללים גם הקמות והטמעות של מערכות אוטומציה לאירגונים קטנים , בינוניים וגדולים.
אשמח להפגש עמכם לשיחת היכרות בה נלמד את הסביבות שלכם והטכנולוגיות בהן אתם עובדים וביחד “לתפור” את פתרון האוטומציה המתאים ביותר לארגון.
למי השירות מיועד ?
– חברות המעוניינות בייעוץ ליווי של פרוייקט אוטומציה. – חברות המעוניינות בהקמה מ-Scratch של תשתית אוטומציה. – חברות המעוניינות בהכשרה והדרכה של צוותים קיימים. – חברות המעוניינות לגייס שכירים \ יועצים לתקופה מוגבלת בעזרה לעיבוי הטסטים (תשתית קיימת).
תיאור דוגמא של ארכיטקטורת מערכת אוטומציה:
להלן רשימת הקומפוננטות המרכיבות תשתית אוטומציה – Framework
אלו הם טכניקות עיצוב של כתיבת קוד (Design Pattern) , נעשה בהם שימוש רחב לפרוייקטי אוטומציה מפני שהם מאפשרים לנו : – שימוש חוזר בשורות קוד (Reusability) – הבנה מהירה יותר של הקוד – קריאה חכמה לפונקציות – צימצום מקום לטעויות
Error Handling
טיפול בקוד במקרים בהם התוכנית נופלת בעקבות למשל באג במוצר. במקרה כזה נרצה להטמיע תהליכים של דיווח הבעיה , המיקום שלה בקוד, הכשלת הבדיקה הנוכחית ומעבר לבדיקה הבאה.
Recovery Functionality
כאשר הבדיקה נופלת (בין אם זה בגלל באג במוצר או בין אם זה בגלל באג באוטומציה), רצוי מאוד לכתוב פונקציונליות שתזהה היכן התוכנית נמצאת באתר (המיקום שלה עד רגע הנפילה), והבאת הריצה הנוכחית אל הדף הראשי ממנו ניתן להתחיל את הבדיקה הבאה.
Reporting System
כלי דיווח למשתמשים, מריצי הבדיקות האוטומטיות וכן המנהלים אשר ירצו לראות את מצב הריצה הנוכחית (אשר רצה למשל כל הלילה), המערכת תציג דיווח עילי לעומת הלוגים (שמיועדים למפתחי האוטומציה), בה מיוצגים אלמנטים גרפיים על דוח HTML, דוגמאות כמו Allure Reports, Extent Reports, Report Portal ועוד… ניתן לגשת גם לדוחות היסטוריים על פי פילוח וסיווג של תאריכי ריצה.
Screen Shot + Screen Cast Abilities
בנוסף לדוח שנוצר, דוח המשקף לנו את סטטוס הריצה, מאוד יעזור גם להבין את מקור הבעיה על ידי צילום מסך בזמן נפילת הבדיקה, יכולת נוספת היא להוסיף גם תמיכה בהקלטת וידאו של מקרה הבדיקה.
Working with External Files (Configuration)
ישנם פרמטרים שלא משתנים לאורך כל הריצה, כמו למשל – שם המכונה עליה מריצים את הבדיקות, כתובת ה-IP שלה , שם המשתמש והסיסמא לכניסה למערכת, כתובת האתר, נתיב\מיקום קובץ הדוח, נתיב\מיקום קבצי הדרייבר (מנוע ההרצה) וכו' את כל הפרמטרים הללו מומלץ מאוד לשמור במקום אחד – בקובץ הגדרות שיישב בפרוייקט וממנו ניתן יהיה לקרוא נתונים מתוך הקוד.
Support Visual Testing (GUI Testing)
תמיכה בבדיקות GUI יאפשר בפרוייקט האוטומציה לבדוק את הממשק הויזואלי של האפליקציה, זאת ניתן לעשות על ידי מנוע השוואת תמונות אשר יזהה את העמוד בו האפליקציה נמצאת וישווה אותו לתמונה של אותו עמוד שיישמר מבעוד מועד במאגר התמונות (Base-Line Repository).
Support Multiple Browsers
פרוייקט האוטומציה לבטח לא יסתפק בהרצת סטים של בדיקות על דפדפן אחד מהסיבה הפשוטה כי הלקוחות עובדים עם מגוון רחב של דפדפנים. מומלץ כי פרוייקט האוטומציה יוכל לתמוך בהרצה על כמה דפדפנים שונים.
Logging System
כלי דיווח למפתחים, מחולל לוגים אשר ייתן למפתחי האוטומציה אפשרות לשחזר את מקרה הבדיקה לפי דיווח פרטני הנכתב לקובץ חיצוני. מיועד בעיקר בשביל להתחקות אחר באגים במוצר.
Working with Object Repository
לאלמנטים שניתן לראות באפליקציה אותה אנו בודקים יש מאפיינים, כך גם האוטומציה יודעת לזהות אותם – לפי המאפיינים שלהם. לכל אלמנט יש סט של מאפיינים, רצוי שאת המאפיינים הללו ישמרו במקום אחד – מבנה של נתונים, נקרא לו Repository ובכל פעם שנרצה לזהות אלמנט, התוכנית תיגש למבנה הזה ותשלוף ממנו את הנתונים הרצויים.
Interfacing Data Base
חלק בלתי נפרד מכל מערכת של תוכנה הוא בסיס נתונים, גם לפרוייקט אוטומציה כדאי שיהיה בסיס נתונים משלו , בו נרצה לשמור פרמטרים מסויימים, למשל סיסמאות מאובטחות של משתמשים, כמובן שבשל כך, יש לכתוב תמיכה לחיבור לאותו בסיס נתונים כמו כן, עם התשתית הזו ניתן גם להתחבר לבסיס הנתונים של המוצר ומשם לשלוף מידע בכדיי לבדוק אותו אח"כ בסט הבדיקות.
Support Data Driven Testing
תמיכה ברכיב זה של Data Driven יאפשר לבצע בדיקות על שדות מסויימים תלויות נתונים. למשל שדה טקסט (סיסמא) עם אוסף של חוקים (איסור על רווח, מינימום תווים וכו'), הבדיקה הנכונה היא להכניס אל השדה את כל הפרמוטציות האפשריות שניתן להכניס באופן חוקי ובאופן לא חוקי. עדיף יהיה כי במקרה כמו זה אוסף המידע שייכנס לשדה זה יישב בקובץ חיצוני (לרוב קובץ – אקסל, CSV , XML או JSON).
Support Keyword Driven Testing
ה-Keyword Driven מאפשר להחצין את קוד האוטומציה לממשק קריא יותר (לרוב – קובץ אקסל), כך שבמקום שפת תכנות יהיה ניתן להרכיב תרחיש בדיקה על ידי שפה אנושית קריאה ומובנת. כך ניתן לאפשר לבודקים ידניים אפשרות לכתוב בדיקות אוטומטיות.
Support Parallel Execution
בשביל שניתן יהיה לכסות כמה שיותר בדיקות על כמה שיותר סביבות שונות, יהיה חכם להריץ את הבדיקות שלנו במקביל, על דפדפנים שונים, מערכות הפעלה שונות וכו'.
Interface with External APIs such as Product Server
אמנם עיקר הבדיקות באוטומציה עם סלניום\פליירייט\סייפרס מתבצעות על הקליינט (הדפדפן), אך אין זה אומר שאי אפשר גם לתמוך בפרוייקט אוטומציה בצד השרת או כל שירות אחר שהמוצר הנבדק מקבל. כאן ניתן לכתוב תמיכה לתפיסת אירועים (Events) היוצאים מן הקליינט והמתקבלים אל הקליינט מהשרת למשל.
Scheduling Your Test Suite
לא תמיד נרצה להריץ את סט הבדיקות שלנו כשאנו בעבודה, יושבים אל מול המחשב. ישנה אפשרות כמובן לתזמן את ההרצות שלנו במזנים הנוחים לנו, לדוגמא – יש לנו סביבה אחת בה אנו גם מפתחים וגם מריצים את הבדיקות האוטומטיות, בזמן שאנו בעבודה נרצה לפתח, ולאחר שנלך הביתה נרצה שהמכונה תתחיל להריץ את הבדיקות בתזמון מסויים.
Interfacing Continuous Integration
ישנם לא מעט כלים של Continues Integration, את פרוייקט האוטומציה ניתן לחבר כמובן למערכות הללו (ישנן מערכות גם שתומכות בתיזמוני ריצות, ותלויות של הרצות).
Support Mobile Apps
פרוייקט אוטומציה למכשירים סלולריים עם Appium, Selendroid או כל סביבה אחרת הינו פרוייקט בפני עצמו. כמובן שניתן יהיה לתת תמיכה לחיבור לפרוייקט כזה.
Support Desktop Apps
סביבת Selenium אינה מסוגלת להתחבר לממשקים שאינם תחת ה-Web Browser. זה יוצר לנו מגבלה מסויימת במידה והבדיקות שלנו חלים גם על אפליקציות דסקטופיות (במסגרת End to End Testing). הפתרון כאן הוא להתחבר לספריות פיתוח אשר תומכות גם ב-Windows Apps , ולחשוף API לפרוייקט הקיים שלנו.