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

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

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

  • Product Mapping and Quality Insight

    Product Mapping and Quality Insight Previously I talked about project management and a quality focus. Here I want to take both down a level to get a little more practical, specifically around the idea of how that quality focus strongly encourages delivery teams to create product maps. It’s those product maps that will give a team the first insights into what quality is going to look like. This notion or product mapping is where I think product management (and thus product mangers) and product development (and thus product developers) start to to intersect. Since there are many very specific ways to craft a product map in a given tool — including using no tool at all! — I’m going to remain largely agnostic of tool concerns here and instead just focus on the idea of product mapping as a technique. The product map, as an artifact, is of course also important. So what is this “product map” thing? Well, the product map is generally a high-level visual summary that maps out the vision and direction of your product over time. The goal here is to convey the strategic direction for the product and tie the product direction back to the strategy for the company as a whole. Crucially, it’s important to note that a product map is not one over-arching view of the entire product. In fact, there will likely be multiple product maps. Specifically, and I think this is a good way to frame it, you will have one product map per market promise.[…]

    1.08.2021 | 2:38 קרא עוד...
  • Creating a Quality Strategy

    Creating a Quality Strategy In my last post, I introduced the concept of the Quality Maturity Model: a series of behaviors that help teams attain various attributes of quality in their software. One of the things it’s important to note is that adopting a Quality Maturity Model requires the whole team to contribute to quality. Quality is not something to be thrown “over the wall” to testers; rather it is a goal that both developers and testers share. But how can you get the whole team to own quality? One way is through the creation of a Quality Strategy. A Quality Strategy is a document that the whole team agrees on together. It’s like a contract that describes how quality software will developed, tested, and released by the team. In this post, I’ll discuss some of the questions you may want to answer in your team’s Quality Strategy. Creating and Grooming Stories:How does the team decide what stories to work on? This could be a decision by the whole team, or by the product owner only. Or the prioritization could be done by someone outside the team. Who grooms the stories to get them ready for development? This could be the whole team or a subset of the team. Ideally, you’d want to have at least the product owner, one developer, and one tester participating. Development Process:How does the team decide who works on which story? It could be that the developers can pick any story from the board, or it could be that[…]

    1.08.2021 | 8:46 קרא עוד...
  • API Testing Challenges - How To Use Simulation Mode

    This post and video shows how to use the Simulation Mode in API Challenges. What are the API Challenges? Our API Challenges Application has a fully functional cloud hosted API, and a set of challenges to work through. Overview The API has a simulation mode, this allows you to experiment with different tools in a controlled environment. Watch on YouTube Patreon ad free version Simulation Mode The simulation mode uses hard coded data in responses, but tries to mimic some conditions. e.g. it expects you to post a specific JSON payload or XML payload and responds ‘as if’ you sent it. But… it also checks if you sent valid json, or valid xml, and responds based on your headers e.g. returning XML if you ask for it. The simulator is stateless and does not track your usage, making it deterministic for multiple users. Which means: Entities created do not show in the ‘entities’ call, but can be retrieved by a ‘GET’ Entities deleted do not show in the ‘entities’ and respond to a 404, but the delete for them will return a 200… you can only delete ‘specific’ entities, other entities will respond with a forbidden request. etc. there are ‘inconsistencies’ but they are logical based on the needs of a stateless simulator. Use the actual API that underpins the challenges if you want a ‘real’ API. Try the verbs and payloads listed below as a way of making sure your tooling is setup and you understand the absolute basics[…]

    1.08.2021 | 5:00 קרא עוד...

טיפים

  • טיפים לאוטומציה יעילה - Dale Emery
    טיפים לאוטומציה יעילה - Dale Emery (How to Survive the Coming Test Automation Zombie Apocalypse (PDF slide deck By Dale Emery bit.ly/15XFGkp סט שקופיות מעולה המתאר את מרבית המחלות התוקפות פעילויות אוטומציה - ומדגיש כיצד לטפל בהן! על כל שקופית ניתן לפתוח…
    קרא עוד...
  • אף פעם אל תפסיקו ללמוד - בדיקות
    אף פעם אל תפסיקו ללמוד - בדיקות אף פעם אל תפסיקו ללמוד - בדיקות " אף פעם אל תפסיקו ללמוד" – או כמו שנאמר "רק טיפשים יודעים הכל". מפעילותי בפורומים השונים בעולם הבדיקות בארץ ובעולם, תכופות אני רואה כיצד דווקא חסרי הניסיון, שרק…
    קרא עוד...
לרשימה המלאה >>