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

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

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

he icon   en icon

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

יום בחיי בודק – מהו בעצם מקצוע הבדיקות, בפן הפרקטי - יום-יומי?

נכתב על ידי 
שבת, 21 דצמבר 2013 18:46
דרגו כתבה זו
(2 הצבעות)

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

(פוסט זה נסמך בין השאר על דיונים רבים שנכתבו ע"י חברי פורום  " בקרת איכות תוכנה – QA" במהלך השנים)

 

מה זה בכלל בדיקות?

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

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

תפקיד נוסף הוא מניעת שגיאות במהלך הפיתוח ע"י בחינה מוקדמת של תכנון המוצר.

 

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

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

תאורטית - נדרש מעין סרטון תדמית למקצוע – אך מכיוון שלא הצלחתי לארגן הכנתו (עדיין? cool) נתחיל מתאור כתוב:

 

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

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

 

תפקיד הבודק מתחלק למספר פעילויות:

לרוב ישנן תקופות (מימים עד שבועות) בהן מתמקדים יותר בפעולה אחת מתוך אלו, אח"כ עוברים לשלב הבא וכד'.

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

2. ניתוח המידע המהווה בסיס לבדיקות,

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

   לרוב מתבצע בשני שלבים:

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

      ב. השתלבות בישיבה עם משתתפים מתפקידים שונים.

4. תכנון והגדרת הבדיקות - לרוב תוך כדי כתיבת מסמך בפירוט כזה או אחר (ב-וורד/אקסל או בכלי ניהול בדיקות ייעודי),

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

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

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

לרוב חלק זה תופס זמן ניכר מעבודתנו.

תוך כדי ריצה - לרוב נעדכן מסמך תוצאות והתקדמות.

7. פיתוח בדיקות אוטומטיות,

8. הרצת בדיקות אוטומטיות וניתוח תוצאותיהן,

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

10. דיווח באגים - במערכות דיווח / תוכנה לניהול באגים,

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

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

 

כשמסיימים עם תכונה אחת, עוברים לבאה אחריה, אח"כ לבדיקות מערכתיות, החלטה על שיחרור גירסה

וכך חוזר חלילה...

 

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

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

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

 

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

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

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

(כמו שנאמר – "למה האחרונים תמיד בסוף" laugh )

 

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

אתם מוזמנים לקרוא עוד בנושא הדרכות לבודקים חדשים בתת-הפורום המיועד לכך:

http://itcb.org.il/index.php?option=com_kunena&view=category&catid=8&Itemid=632

 

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

שונה לאחרונה ב ראשון, 22 דצמבר 2013 17:01

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

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

  • 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 קרא עוד...

טיפים

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