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

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

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

he icon   en icon

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

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

נושא מה הייתם מוסיפים לתאור הבא של עבודת הבודק?

מה הייתם מוסיפים לתאור הבא של עבודת הבודק? 17 יול 2013 11:19 #733

  • halperinko
  • halperinko's Avatar
  • מנותקים
  • Administrator
  • פוסטים: 836
  • תודות שהתקבלו 35
  • קארמה: 3
מה הייתם מוסיפים לתאור הבא של עבודת הבודק?

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


בזמן שתכנתים עוסקים בעיקר בכתיבת קוד (לרוב לבד מול המחשב) ונכנסים לעומקו של הקוד אותו הם כותבים אך פחות מסתכלים על התמונה המלאה, הרי שבודקים מנסים לזהות את הכשלים בתכנון המערכת ובמימוש (בהנחה שתכנתים הם בני אדם ולכן עושים טעויות), עבודת הבודקים דורשת ראייה מערכתית של המוצר, משמעויותיו ללקוחות השונים, תאימותו לסטנדרטים בתעשייה וכד'.
לבדיקות מס' שלבים:
1. קריאה וניתוח הגדרות המערכת - במטרה לזהות חוסרים וטעויות שעשויות להשליך בהמשך על המערכת.
+ למידת הנושא ממקורות שונים.
2. תכנון הבדיקות - מה, איך וכד'.
3. כתיבת מסמכי בדיקות (מפורטים יותר או פחות בהתאם לאסטרטגיה שנקבעה).
4. ביצוע הבדיקות וניתוח התוצאות - בעיקר ניתוח תופעות שנראות כשגויות ודיווחן כבאגים.
5. כתיבת דוח סיכום תוצאות הבדיקה.
6. בדיקה חוזרת של נושאים שתוקנו.

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

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

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

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

חומר נוסף לגבי כיצד ללמוד ועוד תוכל למצוא באתר ITCB תחת:
goo.gl/CnbIr
יש להרשם בכדי לכתוב בפורום.

מה הייתם מוסיפים לתאור הבא של עבודת הבודק? 19 יול 2013 17:02 #738

  • דניאל
  • דניאל's Avatar
  • מנותקים
  • Fresh Boarder
  • פוסטים: 1
  • תודות שהתקבלו 1
  • קארמה: 0
היי קובי. בתור אדם טכני שעשה הסבה לתחום הבדיקות אני יכול לומר בביטחה שעבודת הבודק ברובה מבוססת על ידיעת שפות פיתוח וקריאת קוד. משרות רבות בתחום דורשות ידע במספר שפות פיתוח, נושא שנלמד בלימודי מדעי המחשב או הנדסת תוכנה. מעטות יותר המשרות בתחום הפונות לנושא החומרה, ציוד תקשורת וכו'.
יש להרשם בכדי לכתוב בפורום.
המשתמשים הבאים אמרו לך תודה: halperinko

מה הייתם מוסיפים לתאור הבא של עבודת הבודק? 19 יול 2013 17:51 #739

  • halperinko
  • halperinko's Avatar
  • מנותקים
  • Administrator
  • פוסטים: 836
  • תודות שהתקבלו 35
  • קארמה: 3
יש לא מעט אנשים שלא יסכימו עם האמירה "עבודת הבודק ברובה מבוססת על ידיעת שפות פיתוח וקריאת קוד.",
בודקים רבים עשויים לעבור קריירה ארוכה מבלי לראות אפילו שורת קוד אחת...
יש שטוענים כי דווקא חוסר הכרת ה"מנוע" של המוצר מאפשרת לבודקים למצוא דברים שהמפתחים לא צפו, והכרות עם תוכנה גורמת ל-bias מסויים המקרב את דרך מחשבתנו לדרך המחשבה של התכנתים.
לטעמי יש חשיבות רבה בהיכרות עם מבנה המחשב ומושגים בסיסיים בתוכנה (ולעיתים אף בחומרה) לשם השגת שפה משותפת עם שאר הגורמים במחלקת הפיתוח - והרי תקשורת הינה אלמנט מהותי בעבודת הבודק, דבר שעולה מעבר לטיעון הקודם.
אם נתעלם לרגע מהתכולה שאכן חשובה לכל משרה לעומת מה שנהוג לכתוב בתיאור המשרות, הרי שבבדיקות ידניות אין ממש צורך בידיעת "מספר שפות פיתוח" - יכולת בסיסית של קריאת קוד הינה מספקת מעל ומעבר (וברגע שיודעים שפת תכנות אחת, המעבר לאחרת הינו קל יחסית - אם לא נכנסים לדקויות).
אמנם ייתכן כי יש יותר משרות הפונות לנושא התוכנה מאשר אלו הפונות לנושא החומרה, אך:
1. לרוב משרות בתחום המשלב חומרה מספקות משכורת גבוהה יותר.
2. בלימודי אלקטרוניקה לומדים הרבה יותר על מבנה המחשב והשלכות של תנאי סביבה וכד', וגם לומדים מעט לגבי תכנות - בימינו - כאשר כל סמארטפון הנו בעצם מערכת משוכללת פי כמה מהמחשב האישי, עם תוספת לא קטנה של חומרה לצרכים שונים, התנהגות של מערכת Embedded יותר מאשר במערכות ההפעלה ל-PC, השפעות של מספר מערכות תקשורת (3-4 מערכות שידור/קליטה טלפוניה + WiFi +GPS +...), צורך בפעולה בתנאי סביבה מגוונים ועוד., הרי שלידע זה יש השפעות על יכולותיו של הבודק.

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

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

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

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

טיפים

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