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

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

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

he icon   en icon

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

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

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

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

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

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

 

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

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

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

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

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

 

הרחבה נוספת:

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

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

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

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

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

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

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

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

 

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

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

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

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

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

 

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

 

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

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

  • A matrix for when a bug only reproduces in one environment

    A matrix for when a bug only reproduces in one environment This year, at several conferences, i did a talk on troubleshooting tips and techniques. One slide in particular seemed to be very much of interest for the attendees, so i decided to elaborate on it with a blog post. In the talk, i was describing what to try to look for when an undesired behavior appears in the system under test, whose root cause is not very obvious. I also encouraged testers to participate in the process of finding the root cause of this bug, by providing a few tips and techniques that can be used. The slide of interest presented a matrix with 5 things to look for, when the bug you are dealing with reproduces on one environment but does not reproduce on another one: The 5 things i mention here are: the build number of the software you are working on. This is the software that exhibits the bug you are trying to figure out the root cause for. I will refer to it as the ‘software’ during this article the configuration of the software you are working on. This can be any flag or property that needs to be set that is not part of the code. It is probably stored in a different file. It can easily be changed, to apply the desired properties on the software, without needing to change the code. For example, such configuration can include: having the software run in debug or normal mode; settings a timeout value up to which[…]

    21.11.2019 | 9:31 קרא עוד...
  • Further reading for Contest NYC 2019

    Materials used for the talk and workshop at Contest NYC 2019: TUTORIAL: Getting the Test Strategy Right for the Context Leading when the subject matter experts test One page test plan https://ministryoftesting.com/dojo/lessons/the-one-page-test-plan? https://www.userfocus.co.uk/articles/usability_test_plan_dashboard.html Wardley Maps https://medium.com/tag/wardley-maps https://medium.com/@chrisvmcd/mapping-maturity-create-context-specific-maturity-models-with-wardley-maps-informed-by-cynefin-37ffcd1d315 https://jlottosen.wordpress.com/2019/04/20/broaden-the-scope-of-sut https://jlottosen.wordpress.com/2019/04/21/innovationintesting Research: Frederiksen, DJ 2018, We are in this together: A qualitative exploration of organisational, relational and personally experienced differences between paid public sector work and volunteer third sector work. Aalborg Universitet. Det Humanistiske Fakultet. Ph.D.-Serien, Aalborg Universitetsforlag. https://vbn.aau.dk/da/publications/vi-er-sammen-om-det-her-en-kvalitativ-udforskning-af-organisatori Daniel Pink: Drive https://www.danpink.com/books/drive/ Helle Hein: Primadonnaledelse https://www.saxo.com/dk/primadonnaledelse_helle-hedegaard-hein_haeftet_9788702101126 https://hbr.org/2017/07/being-the-boss-in-brussels-boston-and-beijing Weinberg 1997 in Making Sense of Change Management: A Complete Guide to the Models, Tools and Techniques of Organizational Change https://flylib.com/books/en/2.28.1/ Motivating Danish employees: Tips for Foreign Managers https://www.howtoliveindenmark.com/stories-about-life-in-denmark/motivating-danish-employees/ Test management / Test Coach In Charge of Testing Less Test Managers, More Test Coaches The Shift-Coach Testing Trend Subject Matter Experts Who is the tester?  With A Little Help From New Friends The domain expert is the tester It all starts with an odd piece Practical tips: Expectations around Testing You don’t have to be a boss to be a leader Less Software, more Testing Asking Open Questions

    21.11.2019 | 8:14 קרא עוד...
  • Agile Testing Days 2019 - About Community, Becoming MIATPP and Keynoting as Learning Partners

    Or: A week full of surprises, wonder and joy.Or: A big, huge thank you.Returning from Agile Testing Days 2019 and a week of vacation, my heart is still full of joy and gratefulness. It was a long conference festival week. I learned a lot, I shared a lot, and we had many insightful and inspiring conversations. Brace yourself: this is going to be a long post with lots of tweets to illustrate my memory of things. Dear all, and especially dear future me: be invited to immerse yourself (again) into these wonderful Agile Testing Days 2019 as I experienced them. I'm totally biased here. I wouldn't want to miss #AgileTD! It was my very 1st conference. I met so so SO many awesome people and learned so much from them there! @tottiLFC and me got inspired there to become learning partners - and speakers! So much good came out of it. 💚🦄— Elisabeth Hocke (@lisihocke) October 31, 2019 Saturday: Back Home in Unicorn LandThe last years I used to arrive on Sunday, just before the tutorial day. The tutorials always provided lots of value to me, so I simply wouldn't miss them. This year, however, a handful of two-day tutorials had been announced, among them two that I simply couldn't resist. The "Quality Coaching Masterclass" by Anne-Marie Charrett, and "Exploring systems quality in a distributed world" by Abby Bangser and Benjamin Hofmann. Both of them were super tempting as well as fitting to my current challenges and knowledge gaps. In the end, I decided[…]

    21.11.2019 | 6:49 קרא עוד...

טיפים

לרשימה המלאה >>