LOGIN
התחברות או הרשמה
Avatar
להמשך הרשמה ידנית – לחץ על כפתור ההרשמה, להרשמה/כניסה מהירה בעזרת חשבון רשת חברתית – לחץ על הלוגו בכותרת

אפס סיסמה - שכחתי את שם המשתמש

שם משתמש
סיסמה
זכור אותי

he icon   en icon

מהו ה-Work Frame הנכון בפרויקטיי אוטומציה?

נכתב על ידי 
רביעי, 03 ספטמבר 2014 13:19
דרגו כתבה זו
(5 הצבעות)

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

Work frame נכון מורכב מהאלמנטים הבאים:

1. Code Structure – לדוגמא האם אנחנו עובדים ב Page Object mode, ואו ממפים את האפליקציה לפי שיטת השכבות (Test -> Business -> Gui)

2. Data Driven – יש כמה שיטות לעבודה עם Data חיצוני בפרויקט, עבודה עם XLS אחד וקריאה בXLS לפונקציות Business, עבודה עם XLS ובתוכו קריאה ל Sheet אחרים לצורך יצירת Data דינמי

3. Reports - אנחנו מכירים כמה סוגים של דוחות, סנכרון עם כלים לניהול בדיקות, דוחות HTML ודוחות XLS

4. Execution - ביצוע ההרצה באמצעות כלים מובנים להרצה (Jsystem, QC, MTM, etc...) ו/או באמצעות NGTest, Junit או כלי הרצה פנימיים אחרים

5. Parameterization – שימוש נכון ויעיל בפרמטרים

6. Error Handling - טיפול נכון ויעיל בשגויים (רישום ללוג ארועים, צילום מסך, הקפצת הודעה, המשך הרצה או עצירתה וכיוב')

7. Verification Points – הגדרת נקודות בדיקה איכותיות ונכונות גם מההיבט הפונקציונאלי וגם מהיבטי תחזוקה ויציבות של הסקריפט

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

הגדרת Work Frame נכון המתייחס לכל 7 האלמנטים המוזכרים למעלה ונותן מענה לפרמטרים לעיל תסלול לכם את הדרך לפרויקט אוטומציה איכותי ויציב לאורך זמן.

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

בהצלחה! 

 

ליאור כץ, Testing Automation Performance & Testing Tools CTO

טאקט בדיקות

www.tact.co.il

 

Automation Work frame TACT 3

 

 

שונה לאחרונה ב שישי, 05 ספטמבר 2014 10:14

חובה להיות משתמש רשום במערכת בכדי להגיב - ההרשמה/כניסה בכותרת האתר

חדשות מעולם הבדיקות

  • Levels of enjoyment: Finding bugs by accident vs. by design

    A tester on a community I belong to recently asked whether we find bugs by design or by accident more fulfilling. Here’s my response: I am not sure there is a “by accident” in testing. If you set out to do something, and you discover something else along the way… before you even got to the feature you set out to test, that is a valid find. And part of a failure of the preconditions for the test you expected to run (whether or not that test actually had tests formally planned). In 16 years of testing I never defined or planned HOW I was going to test, I had a vague idea of what it was meant to do and how I would get there to do it. I never wrote test cases in advance. It was contextual. And find bugs I did. In, on, and around the thing I wanted to test. None of which would have been found by code. Because code can’t explore or evaluate the importance of bugs, and would fail if the journey to the feature was unavailable. I’d say 50% of my testing experience was feature-testing related, and 50% was “stuff I found while getting to the feature or other stuff in the feature that wasn’t expected.” I didn’t answer which is more enjoyable, come to think of it, because it was all enjoyable for me, and all equally valuable.

    18.08.2022 | 8:59 קרא עוד...
  • Video of my live coding session "API Testing mit Karate" with "Never Code Alone" (German)

    Video of my live coding session "API Testing mit Karate" with "Never Code Alone" (German) The recording of my live coding YouTube stream "API Testing mit Karate (API testing with Karate)" is now available (German only)! This was a 75 minute event in collaboration with Never Code Alone. plugin:youtube

    18.08.2022 | 3:00 קרא עוד...
  • Five Blogs – 18 August 2022

    The (best) five blogs we can read today. Check them out. Meet The New Automation Question, Same As The Old Automation Question Written by: Paul Grizzaffi Customer-Centric Test Automation Approach Written by: Enrique A Decoss The Top Reason People Fall Short of Their Goals Written by: Frank Sonnenberg Microsoft Disrupts Russian Cyber-Espionage Group Seaborgium Written by: Phil Muncaster Design Patterns for QA Automation: Build effective test solutions Written by: Kostiantyn Teltov Quote of the day: “Sometimes we figure things out, and then life changes and we have to figure it all out again.” -Renee Carlino You can follow this page on Twitter

    18.08.2022 | 12:21 קרא עוד...

טיפים

  • אל תשאירו Bug validation לסוף הגירסה - טפלו מוקדם ככול האפשר
    אל תשאירו Bug validation לסוף הגירסה - טפלו מוקדם ככול האפשר אל תשאירו Bug validation לסוף הגירסה - טפלו מוקדם ככול האפשר, אח"כ הם מצטברים ולא נותר זמן לטפל. באגים נוהגים להתקבץ - גם במקרה הפחות נפוץ שהבאג אכן טופל עם כל ההשפעות שציינתם :-), דיי סביר…
    קרא עוד...
  • בדוק מוקדם ככול הניתן
    בדוק מוקדם ככול הניתן "בדוק מוקדם ככול הניתן" – אחת המטרות של הבדיקות הינה לספק כמה שיותר משוב ומידע לגבי איכות המערכת מנקודות מבט שונות (פונקציונליות ולא פונקציונליות כמו עמידה בעומסים ושאר יכולות). לעיתים בודקים נוטים בטעות לחשוב כי הדרך…
    קרא עוד...
לרשימה המלאה >>