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

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

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

he icon   en icon

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

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

נכתב על ידי 
רביעי, 08 ינואר 2014 06:35
דרגו כתבה זו
(3 הצבעות)

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

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

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

 

תפקידי אוטומציה מתחלקים לשני תפקידים:

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

דורש יכולות תכנות, אך כמעט לא יכולות בדיקה.

  1. עבודת בדיקות, שימוש בכלים שמעל בכדי להמיר או ליצור בדיקות חדשות, להריצן ולתחקר את תוצאותיהן – להל"ן השמת אוטומציה.

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

 

הרחבה נוספת:

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

הינם מתכנתים לכל דבר ולכן רצוי שיהיו מתכנתים מנוסים + רקע בעבודה במקום מסודר - כך שישתמשו בשיטות עבודה כמו בכל פרויקט תוכנה - תכנון, תיעוד, SVN-CM, PeerReview ...

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

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

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

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

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

(היתרון היחיד הוא שאולי הם בודקים את תוצריהם טוב יותר )

 

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

אלו אמורים לבקש מאנשי התשתיות את הכלים הנוחים והיעילים הנדרשים להם.

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

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

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

 

קובי הלפרין - halperinko@

 

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

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

  • How people think programming looks vs how it really looks

    Source: Reddit The post How people think programming looks vs how it really looks appeared first on The Life Of One Man.

    9.12.2019 | 4:02 קרא עוד...
  • 7 Great Reasons to Write Detailed Test Cases

    7 Great Reasons to Write Detailed Test Cases Let’s face it, writing detailed test cases takes a lot of time and effort.  As a tester, I know this is very tedious work.  However, I know first hand there are some tremendous benefits that far outweigh the time involved.  It certainly is not easy, but if planned out properly can be done extremely efficiently.  You will probably get some push back in certain areas and using certain methodologies but it is extremely important in my opinion.  Agile for example, is not in favor over detailed documentation.     Here are 7 Great Reasons to Write Detailed Test Cases Planning :  It is important to write detailed test cases because it helps you to think through what needs to be tested. Writing detailed test cases takes planning.   That planning will result in accelerating the testing timeline and identifying more defects.  You need to be able to organize your testing in a way that is most optimal.  Documenting all the different flows and combinations will help you identify potential areas that might otherwise be missed. Offshore:  If you have an offshore team, you know how challenging that can be.  It is really important to write everything out in detail when you communicate offshore so that everyone understands.   It is critical to write detailed test cases is no different.   Without those details, the offshore team will really struggle to understand what needs to be tested.  Getting clarifications on a test case can often take a few days of back[…]

    9.12.2019 | 2:27 קרא עוד...
  • Impostor syndrome and the programmer’s brain

    Impostor syndrome and the programmer’s brain Introduction Impostor syndrome is where you feel that you are in a position that you don’t deserve because you’re not good enough at something, in contrast to everyone around you who all seem to be good enough, and one of these days someone will discover you to be the fraud or impostor that you really are.  I’ve felt it, and I know of many other programmers who also have.  It can happen despite evidence that you are good enough, and it’s this part that I want to explore in this article. Digression to pre-history If you’re like me, you sometimes get mildly annoyed when someone tries to justify their argument by referring back to pre-historic times and what people must have done to survive.  I find this mildly annoying because this is often done lazily – without any evidence or decent reasoning to show that such a claim is in any way valid, and hence the main argument is also valid. Well, that’s exactly what I’m going to do now – sorry.  Imagine one of our pre-historic ancestors waking up, going to the mouth of their cave and looking around.  Pretend that there are two possible kinds of reaction this ancestor has to looking around. In the first case, the ancestor goes “Wow!  There’s a big oak tree!  Amazing!  Next to it is an elm sapling!  Incredible!  Next to that is a gorse bush!  Look!  Behind the oak there’s a wolf!” In the other case, the ancestor sees the same[…]

    9.12.2019 | 12:40 קרא עוד...

טיפים

  • טיפ - עבודת בודקים בצמד עם המפתח
    טיפ - עבודת בודקים בצמד עם המפתח  עבודת בודקים בצמד עם המפתח "עבודה בצמד עם המפתח" – לעבודה בצמדים יתרונות רבים אך לעיתים היא נזנחת בשל "העלות הכפולה". בשנים האחרונות עם עליית שיטות אג'יליות ו- Extreme Programming צורת עבודה זו יותר נפוצה. כששני…
    קרא עוד...
  • למדו מתי להשתמש באוטומציה ומתי לא
    למדו מתי להשתמש באוטומציה ומתי לא למדו מתי להשתמש באוטומציה ומתי לא "למדו מתי להשתמש באוטומציה ומתי לא" – תחילה – חשוב ללמוד כי למרות ההבטחות של כמה ממשווקי הכלים אין אוטומציה ללא תכנות, בסופו של דבר עם כל ההקלות שחלק מן…
    קרא עוד...
לרשימה המלאה >>