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

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

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

  • TestBash Detroit MC Scholarship

    TestBash Detroit MC Scholarship Announcing Scholarship Opportunity to Attend TestBash Detroit Hi everyone, I’m Jenna Charlton and as you may or may not have seen, I’m going to be the host for the first ever TestBash Detroit! A little about me, I love testing, I love pro wrestling, I love cats, and I love punk rock and ska. I’m from Cleveland Ohio, just 3 hours south of Detroit and the rust belt region owns my heart, so getting to be a part of something as special as TestBash so close to home is really important to me. I’m passionate about testing, accessibility, and making sure that the testing community is an inclusive and welcoming space. My first TestBash was an amazing experience and each one I’ve been to since then has been equally as important in my professional and personal growth. TestBash connected me to a broader community and introduced me to people who have become close personal friends. TestBash also gave me my very first opportunity to be on stage and give a 99 second talk! The speaker lineup for Detroit is incredible and I’m so excited to learn right alongside all of you! Because the lineup is so good and because I want to make TestBash accessible to some folks who otherwise wouldn’t be able to go, I’m creating a TestBash Detroit scholarship! I’ll be offering 2 scholarships to the conference day (April 24th). Please see the requirements below to determine if you’re eligible to apply. Must live in the Detroit or[…]

    20.01.2020 | 10:24 קרא עוד...
  • Do NOT Automate regression 100%

    Automation regression percentage – The metric I hate the most.. Many times the only use of this metric is to provide false assurance that we are efficient in testing. And the ultimate goal soon becomes to automate regression 100%, which is a bad idea, And automating just UI tests makes it even worse. More on why not to use it and what should be done in the linked video #RedefiningSoftwareQuality #Automation #RegressionTesting #KPIs The post Do NOT Automate regression 100% appeared first on Quality Spectrum.

    20.01.2020 | 9:21 קרא עוד...
  • Would Heu-risk it? Part 10: Forever and never

    Would Heu-risk it? Part 10: Forever and never Today we are shifting left and looking at some static testing! Yay, so exciting! Another tool. But before we start with details, here is the rhyme for today: “Always and never are never to be trustedOnce challenged, they are quite often adjustedTo something less set in stone but easier to believeDare to challenge criteria you could never achieve” So, what does it mean? This one is inspired by both working with requirement analyisis/reviews and by The “Always and Never”-heuristic card in TestSphere. Long story short: Any time you see an absolute in a requirement, specification, user story etc. – Challenge it. Challenge it good. We humans tend to describe things in absolutes to simplify but often there is a lot of if’s and but’s in there that aren’t communicated.Absolutes are also very hard to verify (one might argue impossible since we cannot do 100% exhaustive testing) and the cost of even trying can get very high.Some examples:“A user must always be able to complete the application within 1 min”“The system must always be online”“The response time in the system must never exceed 3 seconds”“The system must be able to handle, and adapt to, every language”Let us break each of those down:“A user must always be able to complete the application within 1 min”How would you prove that? Probably by having a reference group try it out and check that they all succeed. Does that prove it? Can you know that that user group includes every possible client you have? You[…]

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

טיפים

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