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

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

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

he icon   en icon

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

הקהילה

cover photo

Itay Mashiah

שלח מסר
הוסף כחבר
Itay Mashiah

אודותי

מידע בסיסי

חבר מתאריך
ראשון, 18 אוגוסט 2013 10:29
האחרון שהיה און ליין
8 שנים
  • Itay Mashiah יצר נושא חדש ' הכנה לראיון עבודה בדגש על חקירת החברה והמראיין.' בפורום.
    8 שנים

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

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

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


    הכותב עוסק בקואצ'ינג והכנה לראיונות עבודה בהייטק, ופיתח שיטה משלו להתבלט ולהיות "האחד מאלף". שיטה זו עזרה כבר לעשרות אנשים להשתלב בתעשייה (במיוחד חסרי ניסיון). פוסטים נוספים ניתן לקרוא כאן: www.facebook.com/groups/298606783582710
    קרא עוד...

  • Itay Mashiah יצר נושא חדש ' כמה מילים על בדיקות קבלה' בפורום.
    8 שנים

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

    כולם יודעים להגיד שבדיקות קבלה אלו בדיקות שעושים אצל הלקוח. האם כולם יודעים איך מבצעים את הבדיקות האלה?

    אז קודם כל אנחנו מדברים על ATP - Acceptance Test Procedure.
    וכמו כל דבר, גם את הבדיקות האלו צריך למסמך.
    אז איך ממסמכים?
    הלא כבר כתבנו STP ,STD ושאר מרעין בישין , אז מה, נכתוב עוד מסמך?
    כן. המסמך הזה מיועד עבור הלקוח.
    זה מסמך שבו נעזר הלקוח על מנת שיוכל לבדוק את המערכת לאחר שהוטמעה אצלו.

    אבל למה אנחנו (או הלקוח) צריכים לעשות בכלל בדיקות קבלה?
    הרי כבר בדקנו את המערכת מכל הכיוונים וההיבטים השונים..
    הלקוח חייב לעשות בדיקות קבלה. קודם כל בשביל להשתכנע שהמערכת אכן עובדת על פי ההגדרות שהוא ביקש. ודבר שני, את הבדיקות שביצענו במעבדת ה QA ביצענו בתנאים שלנו, כלומר השתמשנו בסרברים, ראוטרים, ושאר ציוד בקינפוגים שונים שמותאמים לצרכי מחלקת ה QA. ללקוח יש (לא בהכרח אבל בד"כ) ציוד אחר, סביבת עבודה אחרת, ציוד שמקונפג בצורה שונה, ולכן חייבים לבדוק שהמוצר שפיתחנו ובדקנו בכלל ישים אצל הלקוח. לכן נכתוב מסמך ATP (שמתאר קווים כלליים בד"כ של המערכת) על מנת שהלקוח יוכל לבדוק את המערכת בסביבה הטבעית שלו.

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

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


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

חברים

אין חברים כרגע

קבוצות

לא הצטרפת לקבוצות עדיין.

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

  • Creating Jest Unit Tests for AWS Step Functions

    Creating Jest Unit Tests for AWS Step Functions You’ve used AWS Step Functions in your code and now you want to create some nit tests for it? I’ve got just the article for you.Continue reading on Medium »

    22.06.2021 | 6:34 קרא עוד...
  • RIMGEA (2nd ed.) aka RIMGEN

    Wow, it’s been 10 years since this blog post: RIMGEA – 6 approaches to bug reporting. There I wrote about a very useful mnemonic I picked up from a bug advocacy class (it’s more about bug reporting, than loving bugs). Lately, I’m not in a role where functional testing is part of the official R&R. But I think I’m a tester through and through — I still test or review, and I still log bugs or give feedback. And I still care about how bad bug reporting can give testing a bad rap. So anyways, now’s a good time as any to retouch that post. RIMGEN (and maybe plus S) Originally, the mnemonic I picked up from the bug advocacy class was “RIMGEA“. It stood for the 6 factors or approaches to bug reporting which are: Replicate, Isolate, Maximize, Generalize, Externalize, And say it dispassionately. Then there was a suggestion in the comments before and I also found some recent BBST material that made the shift from “A” to “N” to suggest the neutrality in tone. The last letter S was from the comments, with a suggestion to spellcheck. I would generalize it as proofread but RIMGENP doesn’t roll off the tongue quite easily. Replicate it – Try to replicate the bug. If you can’t replicate it yourself, then it might be harder to persuade your developer to fix a problem that they can’t see. This also doesn’t only benefit the developer. Somewhere down the line, you or a fellow[…]

    22.06.2021 | 1:07 קרא עוד...
  • Five Blogs – 22 June 2021

    The (best) five blogs we can read today. Check them out. 3 Mindsets High-Performing Business Leaders Use to Create Growth Written by: Raj Subrameyer I Think in Flowcharts Written by: Michael Lopp How Much Testing is Enough Written by: George Pirocanac Testing, Quality, and my inability to teach Written by: Patrick Prill Automation Testing on Microservices Written by: Bishma Nishadi Quote of the day: “Change requires intent and effort. It really is that simple.” -Roxane Gay You can follow this page on Twitter

    21.06.2021 | 11:08 קרא עוד...

טיפים

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