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

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

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

he icon   en icon

אף פעם אל תפסיקו ללמוד - בדיקות

נכתב על ידי 
שבת, 05 יולי 2014 19:36
דרגו כתבה זו
(3 הצבעות)

Learning

אף פעם אל תפסיקו ללמוד - בדיקות

" אף פעם אל תפסיקו ללמוד" – או כמו שנאמר "רק טיפשים יודעים הכל".

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

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

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

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

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

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

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

אתם מוזמנים לקרוא עוד על כך בבלוג שלנו בפוסט: איזה רקע נוסף רצוי שיהיה לבודק?

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

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

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

רצוי לנסות ולהגדיר נקודות למימוש לטווח הקרוב,

ובכדי לשפר ולהפנים את הידע – רצוי להתמודד עם הנושא ע"י כתיבה עליו ו/או דיון בנושא.

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

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

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

באתר www.itcb.org.il  תחת דף "מעולם הבדיקות" ריכזנו לכם עדכוני RSS מהארץ והעולם – בכדי להקל עליכם למצוא העדכונים המעניינים האחרונים.

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

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

http://www.mkltesthead.com/2013/07/99-ways-workshop-3-never-stop-learning.html

http://www.mkltesthead.com/2013/07/99-ways-workshop-4-and-recognize-that.html

 

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

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

99 Things Testers Can Do To Become Better Testers

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

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

LearnTogether

 

שונה לאחרונה ב ראשון, 06 יולי 2014 20:36

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

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

  • Five for Friday – January 24, 2019

    This is the special time travel edition of FfF (I lost a day – mentally – while traveling). I have read, and re-read this article on Work is Work. It’s a fantastic analysis of organizational design. I plan on reading it yet again after I post this.It’s no secret that I like Radical Candor, and in order to care personally, you need to get to know your team. Mike Cohn posted 25 Questions that Will Help You Know Your Teammates Better this weekSpeaking of feedback, Negative Feedback Rarely Leads to ImprovementTwo github links to close things out – the first is The Book of Secret KnowledgeThe second github link is a curated list of Chaos Engineering topics. This one is staying in my favorites. (potentially) related posts: Five for Friday – January 19, 2018 Five for Friday – October 4, 2019 Five for Friday – January 4, 2019

    25.01.2020 | 3:22 קרא עוד...
  • How to Stamp Out Intermittent Testing Issues With Periodic Automation

    How to Stamp Out Intermittent Testing Issues With Periodic Automation Originally published by TechBeacon.com. In the pop culture of the United States, Sasquatch (a.k.a. Bigfoot) is a legendary and elusive ape-like creature infrequently seen in the Pacific Northwest. In the software realm, we have our own version of Sasquatch: those irritating, sometimes catastrophic, issues that are hard to reproduce. So, as a test engineer, how do you track down your own elusive Sasquatch? I use an approach I call “periodic automation,” and it works quite well. Traditionally, you run your automated tests on event boundaries such as when you’ve had a successful deployment. Why? When a deployment succeeds, it was initiated because some code changed in your application. To be effective with your time, you look for problems when you think they may have been introduced. Logically, points of change are where you expect to see issues injected, so you tend to only look for issues then. Unfortunately, this approach limits your opportunities to reproduce the previously mentioned intermittent issues: hard-to-reproduce issues that don’t occur on a predictable schedule or set of events. If, however, you also run your automation periodically, in addition to your event boundaries, you’ll have additional opportunities to reproduce these types of issues. Here’s how periodic automation works. Highly connected software is prone to intermittent issues Today’s software is highly connected, both to components in your production network and to servers and components outside of it. Analytics, payment, and social media services, for example, are often external to your application’s network. Reliance on these services makes your environment harder to test. Just enumerating all[…]

    25.01.2020 | 1:00 קרא עוד...
  • Would Heu-risk it? Part 12: The Twins

    Would Heu-risk it? Part 12: The Twins Another weapon for you to weild! I have some funny stories of how wrong things can end up when this fails. First as usual, rhyme-time: “Your process might work like a charm with one clientMake sure you´re not on a single queue reliantWhat happens the day more than one person tryAnd simultaneously demand the same thing to buy” So, what does it mean? Have you ever been to a web shop, browsing through. You see something you are interested in buying and you put it in your cart. After some more shopping you try to check out – only to be told that the item is no longer available! Can you remember how annoying that was? Well, this card is about that, sort of.See, threading is something that can mess up a lot of things. In the example above, it might be a concious decision from the store to not reserve your item – more of a first come – first serve approach. Which can be ok, of course, but if it gets too common it might cost you users. So, imagine each task someone tries to do in your system as one of the clients above. They each have something they want to buy, and they all think their request is the most important one. Your application’s job is to make sure you don’t mess up their orders, while still serve everyone as quickly as possible.Imagine threading as queues in the department store. Every cashier is a separate thread[…]

    24.01.2020 | 7:00 קרא עוד...

טיפים

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