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 בזמן שאנשים עם רקע באלק' התייחסו לנושאים כמו רזולוצייה של תוצאה, השלכות של תנאי סביבה ועוד - עד כדי שהפסקתי לשאול שאלות אלו מכיוון שדרך התשובה הייתה צפוייה מראש ע"פ קו"ח...

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

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

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

טיפים

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