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

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

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

he icon   en icon

בודק - למד להסביר

נכתב על ידי 
ראשון, 07 ספטמבר 2014 19:44
דרגו כתבה זו
(1 הצבעה)

בודק - למד להסביר

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

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

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

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

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

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

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

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

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

חשוב לא להתבדר אלא להשאר ממוקדים בהסבר.

חומר קריאה נוסף:

http://www.mkltesthead.com/2013/07/99-ways-workshop-11-learn-to-explain.html

 

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

סדרת טיפים זו "כיצד להפוך לבודקים טובים יותר" מתבססת על דיון ב: Software Testing Club

99 Things Testers Can Do To Become Better Testers

ה-eBook החינמי שנוצר בעקבות דיון זה: 99ThingsEbook.pdf

וסדרת פוסטים מאת Michael Larsen בשם: Ways Workshop 99 - בה מיכאל מרחיב על כל אייטם וגם מספק הנחיות כיצד לתרגל הנושא.

 Explain Testing

 

שונה לאחרונה ב ראשון, 31 מאי 2015 05:22

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

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

  • Tuesday Notes – Follow your processes – 28/01/2020

    Hey everyone,   Here’s a few quick points on what I've been up to: Podcast I'm listening to.. The Wolf’s Den Going from rags to riches, back to rags, and then back to riches yet again, Jordan Belfort is that rare breed of individuals who knows how to land on his feet, regardless of what life ... [Read more...] The post Tuesday Notes – Follow your processes – 28/01/2020 appeared first on The Life Of One Man.

    29.01.2020 | 2:21 קרא עוד...
  • Tuesday Design Fails: The longest list

    The post Tuesday Design Fails: The longest list appeared first on The Life Of One Man.

    29.01.2020 | 2:13 קרא עוד...
  • Taking Pleasure

    I recently had another great discussion with a developer, essentially over hot drinks in the kitchen. We covered all sorts of topics, a lot around how testers and developers can help each other when communicating in bug reports. It’s a sensible and productive conversation to have, since both sides – and maybe others on each team – can make simple changes that really benefit the other. Naturally, we also talked about those awkward bug reports – ones that are hard for either side to reproduce. The developer appreciated and understood that as testers, we don’t want to write bug reports where it’s not entirely clear, or the steps aren’t reliably reproducing the problem, or we’ve only seen it happen once – it’s really bad, but we’ve no idea what we did! These things happen. I agreed and said that I really don’t want to be raising those sorts of bugs. I’ll put an appropriate amount of time in before conceding that the benefits of raising it now outweigh the cost of pressing on. Maybe the developer can suggest a route to reproduce it, just from the vague description or error message? Maybe the developer can quickly guess what’s happened and doesn’t need lots of reproduction steps? I also said that I didn’t get any pleasure from raising bugs generally. Then had to stop myself. Wait a second… I do take pleasure from it… but from where? It’s certainly not that I’ve “broken” something that a colleague has been working on,[…]

    29.01.2020 | 11:30 קרא עוד...

טיפים

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