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

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

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

he icon   en icon

halperinko

halperinko

שני, 03 מרס 2014 14:40

דו"ח איכות התוכנה 2013-14

דו"ח איכות התוכנה 2013-14

 

לקריאת ממצאי דו"ח איכות התוכנה 2013-14 המלאים - הכנסו ללינק הבא:

http://www.itcb.org.il/media/files/2013-14_IL-Qual_Report_Design_Final.pdf

 

 

 

תקצור סקר איכות הבדיקות 2013-14

תחרות גביע העולם בבדיקות תוכנה!

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

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

לפרטים נוספים והרשמה

 

Gil Danon

ITCB® Admin. Manager

+972-3-6176640

+972-54-3014148

מהן תכונות האופי הנדרשות מבודק?

נתחיל מבדיחה:

    בדיקות הן עבודה לפולניה –

תמיד למצוא מה אחרים לא עשו כראוי ולהעיר על כך... cool

 

ישנן תכונות שממש מזוהות עם עבודת הבדיקות:

* שיטתיות, סדר

* קפדנות – תשומת לב לפרטים - כישרון לאתר "נקודות עיוורות" שאף אחד לא חלם עליהן.

* ראייה מערכתית (ההבדל המהותי מול תכנת אשר נכנס לפרטים אך פחות רואה ההקשר)

* יכולות תקשורת/התנסחות בעברית ואנגלית, היכולת לחלץ מידע מאנשים,

* חשיבה יצירתית ומחוץ לקופסא (המתכנתים מקבלים הגדרות ומיישמים על פיהם - אנו הבודקים צריכים לנחש היכן יכלו לטעות ומה שכחו)

* סקרנות - יכולות למידה עצמית ויכולות הבנה גבוהות

* כושר ניתוח

* התמדה - היכולת להתמודד גם עם עבודות "שחורות" או "סזיפיות"

* יצר למצוא היכן המערכת תכשול, והיכולת לזכור מקרים אלו ולהקיש מהם בדיקות עתידיות.

* אמפתיה (ראו ציטוט של אבי ע. בהמשך)

 

ולעומתן אחרות אשר רצויות במקצועות רבים וגם בבדיקות:

* יחסי אנוש

* יכולות עבודה בצוות - שיתוף יידע וכלים

* עמידה בלחץ

* חריצות

* סבלנות וסובלנות

* מנהיגות יוזמה ונכונות להתחדש

 

ראו גם קובץ מצורף (יתווסף בהמשך השבוע) - מה נדרש ממהנדס בדיקות – נכתב ע"י דני אלמוג

 

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

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

(ותוספת שלי – היא חשובה גם בכדי שהבודק יבין את צרכי המשתמש ויוכל לשקפם בתהליך הבדיקות.)

 

 

איזה ידע נדרש לבודק תוכנה טוב?

מעבר לתכונות האופי, בודק זקוק גם לידע רב,

הפירוט הבא נכתב בפורום בתפוז ע"י דב צפוני  05/09/06 (והותאם מעט על ידי)

ארבעה תחומים הנדרשים לבודק התוכנה:

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

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

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

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

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

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

 

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

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

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

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

 

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

 

חומר קריאה מענין להרחבת הנושא:

http://books.google.co.il/books?vid=ISBN0471469122&id=tzI4S5x5smkC&pg=PA21&lpg=PA5&dq=the+psychology+and+economics+of+program+testing&sig=qctH-tTAF1WaPy&redir_esc=y#v=onepage&q=the%20psychology%20and%20economics%20of%20program%20testing&f=false

 

זהו המאמר השני בסדרת ההקדמה והיכרות עם מקצוע הבדיקות,

למאמר הראשון:  יום בחיי בודק – מהו בעצם מקצוע הבדיקות, בפן הפרקטי - יום-יומי?

 

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

מקווה שנהנתם והשכלתם,  (ובעיקר שהבנתם כי עליכם להמשיך וללמוד בעזרת הפורומים והכתבות)

קובי הלפרין - halperinko@

עודכן מילון המונחים, אנגלי-עברי אנגלי-עברי המפורט - מהדורת בטא 2014-01 - באתר ITCB
תודה לדר' אבי עופר על ההשקעה העצומה בתרגום :-)

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

http://goo.gl/cd7ffg

סיכום מפגש בודקים JeST3 - חלק שני

(חלק שני מתוך שניים - לחלק הראשון: http://goo.gl/jWf0ij )

 

יואל מ. – Aaaaaaa !!!    –     או מה מתסכל אתכם במקצוע?

(KH- דברים שמטריפים אותנו...)

במהלך סיכום סקר מצב הבדיקות העולמי, הופתעתי מהתגובות לשאלה זו.

 

והנה מה שהנוכחים החליטו לציין כדברים שמתסכלים אותנו במקצוע:

* אלון:  למצוא באג שכבר דווח לפני כך וכך חודשים במערכת.

* יואל ת.:  להתחיל בדיקות על מוצר שלא נבדק מעולם ואין תכנית עבודה מהעבר.

    (יונתן:  עצם הדיבור על מקרים אלו ואיך מתמודדים איתם מאפשר פיתוח עצמי.)

* ישראל:  כשמבזבזים זמן על דיון חוזר בבאג לא מהותי.

   (יואל:   האם יש באגים שעדיף לא לדווח?  - נושא לדיון נפרד)

* מיכאל:  יום שלם ללא מציאת באגים.

              חוסר בתיעוד מינימלי.

* שרה:  מפתחים שלא מבינים מה נבדוק ומספקים מידע או תכונות שגויות.

* ברק:  קבוצות שלא לומדות מההיסטוריה ומתקנות בהתאם.

           "הוצאתי גרסה שמתקנת הבאג הזה"  -  נו טוב, ומה עם השאר...?

* עדי:  שינוי בלתי מתועד במערכת ברגע האחרון "אבל זה רק תיקון קטן..."

* עמית:  מציאת בעיות טריוויאליות שברור שהמתכנת כלל לא הסתכל על התוצר.

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

* קובי: אנשים שלא מתעניינים במקצוע הבדיקות, לא למדו, לא קוראים, לא משתתפים בדיונים – בקיצור לא מתפתחים.

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

* גיל:  איך קורה ששוכחים בעיות עבר שכבר נפלנו עליהן.  (Project Memory)

* שמואל:  "בטחון מופרז" – כבודקים אנו רגילים לנפץ אשליות, אך האנשים סביבנו מאוד אופטימיים.

 

בכדי לא לתסכל כליל את תלמידי הקורס שהגיעו למפגש,

העלנו גם:   מה כיף בבדיקות?

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

* עמית:  כיף לשבור דברים של אחרים.

* אשר:  כיף שתמיד יכולים להתלונן      (בדיקות – מקצוע לפולנייה)

 

כמו כן, היה דיון מעניין לגבי תכולת הקורס,

חיה הציגה בקצרה החומר הנלמד ובעיקר ההתנסויות הכלולות בקורס,

ולפחות אני יצאתי בתחושה כי צורת הלימוד (בקורס של נס בהדרכת קובי יונסי) איכותית ויש הקפדה על תרגול וחיפוש מידע עצמאי.

 

מתנצל מראש אם שכחתי לציין אמירה כזו או אחרת - אתם מוזמנים להוסיף ולהגיב.

 

היה מפגש מעולה - נתראה במפגש הבא בסביבות אפריל,

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

שוב תודה רבה למארגנים והמארחים,

אתם מוזמנים לבקר בבלוג של JeST לעדכונים נוספים: http://www.jerwst.blogspot.co.il

וכמובן לדיון בפורום ITCB כאן באתר ולדיון בתפוז: (קישור ישיר הפעם) http://www.tapuz.co.il/forums2008/ViewMsg.aspx?ForumId=936&MessageId=173342934

 

מקווה שגם אתם נהנתם כמוני,

קובי הלפרין  halperinko@

 

סיכום מפגש JeST3 – בסיסקו (לשעבר NDS) ירושלים,

(חלק ראשון מתוך שניים)

 

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

 

המפגש החל כרגיל מסבב היכרות, ולאחריו הצעות של נושאים לדיון – כאשר השיטה היא – הצגה בת5-7דק' של הנושא (שמואל נושף בעורפם של המאריכים),

דיון "עד שעולה עשן לבן" ומעבר לנושא הבא בתור...

אחרי הצבעה זריזה קיבלנו את סדר הדיון.

הנושאים שהועלו (לא ע"פ סדר דיון) היו:

  1. Project Memory (Gil S.)
  2. Aaaaaaaa!!! (Joel M.)  (Things which make You go Ouch LJ)
  3. Data Layers in Automation (Joel T.)
  4. QA as a Job (Adi M.)
  5. Testing “State of the nation” (QA in Startups) (Jonathan R.)
  6. Testing Syllabus (Training) (Haya) (Also asked for by Barak)
  7. Combinatorial vs. Random (Michael S.)

 

עדי מור – QA as a Job

עדי מראיינת המון בשנה וחצי האחרונות (בשתי חברות שונות),

* לצערה – מרבית הבוגרים (הן של מכללות ל-QA והן בוגרי תואר אוניברסיטאי) בכלל לא מציינים רצון להשאר בתחום בעוד 3-5שנים, אלא מצפים לעבור לתפקידי תוכנה או ניהול פרוייקטים.

- תכננו כיוון קדימה 5 שנים, תדאגו להשאר בכל משרה מספיק זמן בכדי להתפתח.

 

* מרבית המכללות מדגישות מדיי מונחים בעברית על פני המונחים באנגלית, בזמן שמרבית החברות בשוק מתנהלות באנגלית.

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

עדי: גם מי שלומד למבחן בעברית – מומלץ מאוד להוריד הסילבוס באנגלית ולקרוא אותו לפני / אחרי המבחן.

(KH - אגב: בסילבוס העברי ובקורסים המאושרים מופיעים המונחים באנגלית לצד המונחים בעברית)

 

טיפים למתחילים ומראיינים:

1. לקראת ראיון עבודה – חזרו ורעננו ידע על החומר.

2. תדעו "למכור" גם ידע שהוטמע במהלך הפרוייקט (ואף עבודות קודמות)

3. תתכננו מה אתם רוצים לעשות בחיים בהמשך – אל תענו מרשימת משרות שקראתם באינטרנט.

4. תתאמנו על ראיונות – לעולם אל תלכו לחברה בה אתם באמת רוצים לעבוד כראיון הראשון בדרת חיפושי העבודה הנוכחית – לכו תחיל לחברה או שתיים שפחות מעניינות אתכם, כך תגיעו מוכנים יותר לראיונות בחברות אליהן אתם שואפים.

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

 

מישאל – מה חשוב לך בג'וניור?

תשובה: חשיבה לוגית, משיכה לצד הטכנולוגי.

(חיה: לא בטוח שזה מה שכל המראיינים יחפשו)

 

יונתן: 1. חפשו החברה והמראיין בלינקדאין.  (KH – לעיתים אף תמצאו מכרים שעובדים שם...)

2. חפשו כתובת בארץ בעזרת www.foursquare.com  , וגם בעזרת Mapped in Israel.

3. לקראת ראיון – תשאלו מי הולך לראיין אתכם ותלמדו מיהו בעזרת הרשת.

(עדי – תחומי עניין ותחביבים משותפים עוזרים לשבור הקרח)

אל תשלחו מייל לאותה המשרה כל יומיים – מצביע על עודף התלהבות / נואשות, כך גם יש לוודא שקו"ח לא יופצו לאותן חברות ע"י חברות כ"א שונות.

 

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

 

מאידך – צריך ללמוד גם מתי לעצור את הבדיקות – לעיתים זה יותר קשה.  וגם לא להעלב אם לא תיקנו את הבאגים שדיווחתם.

 

יואל:  1. מה זה בדיקות? – בדיקות זה לקוח אותו אנו מייצגים.

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

3. בחיפוש עבודה – תיזמו, תלכו ברגל בין חברות, תכירו אנשים במפגשים, ובפורומים.

(KH- תפנו לאנשים בחברות רלוונטיות דרך לינקדאין ובקשו שיעבירו קו"ח שלכם)

 

קובי: בלינקדאין – שימו לב איך הפרופיל ובעיקר כותרתו נראה למישהו שאינו מקושר עמכם.
משום מה אני מוצא בודקים רבים מדיי עם הכותרת "Computer Software Professional" – מה זה בכלל מביע ומי הציע לכם לסמן כך? , איך אתם חושבים שמגייסים יאתרו אתכם עם כותרת שאינה אומרת "Seeking Testing - QA Job"?

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

קובי: בעיה מהותית בתחום שלנו – היא כיצד מסבירים "מה זה בדיקות?", ואיך הופכים את המקצוע למשהו ששואפים אליו מלכתחילה, ולא רק למשהו שמהנדסי חשמל ואלק' או תוכנה מגיעים אליו רק כבדרך אגב או כעדיפות שנייה.

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

 

* מכיוון שסיכמתי הרבה חומר – מעבר למה שנוח לקרוא בפורום – אעלה סיכום זה לבלוג, כחלק מס' 1 – ואמשיך לגבי המשך המפגש בחלקים הבאים.

אתם מוזמנים להגיב כאן, ובהודעות הרלוונטיות בפורום בתפוז ובפורום ITCB.

http://www.tapuz.co.il/forums2008/ViewMsg.aspx?ForumId=936&MessageId=173342934

קישור לחלק 2 של הסיכוםhttp://goo.gl/3O27Wx

מקווה שתפיקו ערך מסיכומים אלו,

קובי הלפרין halperinko@

כמה מהמשתתפים בתמונה שאיסי העלה לטוויטר

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

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

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

 

תפקידי אוטומציה מתחלקים לשני תפקידים:

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

דורש יכולות תכנות, אך כמעט לא יכולות בדיקה.

  1. עבודת בדיקות, שימוש בכלים שמעל בכדי להמיר או ליצור בדיקות חדשות, להריצן ולתחקר את תוצאותיהן – להל"ן השמת אוטומציה.

דורש יכולות בדיקה, ניתוח וחקירת תוצאות ובעיות, אך מעט מאוד יכולות תכנות (כמובן בתלות באיכות התשתיות)

 

הרחבה נוספת:

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

הינם מתכנתים לכל דבר ולכן רצוי שיהיו מתכנתים מנוסים + רקע בעבודה במקום מסודר - כך שישתמשו בשיטות עבודה כמו בכל פרויקט תוכנה - תכנון, תיעוד, SVN-CM, PeerReview ...

לתפקיד זה כמעט ולא משנה אם יש רקע בבדיקות (שהרי את הדרישות למערכת הם מקבלים ממנהלי קבוצת הבדיקות).

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

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

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

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

(היתרון היחיד הוא שאולי הם בודקים את תוצריהם טוב יותר )

 

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

אלו אמורים לבקש מאנשי התשתיות את הכלים הנוחים והיעילים הנדרשים להם.

הם משתמשים בתשתיות למימוש בדיקות שכבר תוכננו לבדיקות ידניות או שמתוכננות ישירות לצרכי אוטומציה לכדי מקרי בדיקה,

הם גם מריצים ומתחקרים את התוצאות - ולמעשה הם יותר אנשי בדיקות מאשר תכנתים.

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

 

קובי הלפרין - halperinko@

 

Donald Firesmith - book, Common System and Software Testing Pitfalls,

The site which Now includes 127 pitfalls divided into 18 categories


השתתפתי ב-Review של ספר זה - חומר מעולה - שווה קריאה,
לכל קבוצה שרוצה להשתפר!
!Well worth reading

תקצור אייטמים ניתן למצוא פה:
https://sites.google.com/a/firesmith.net/donald-firesmith/home/common-testing-pitfalls

למי שרוצה להזמין הספר המלא והמפורט:
http://www.amazon.com/Common-Testing-Pitfalls-Prevent-Mitigate/dp/0133748553/ref=sr_1_5

 

 

donald-firesmith-common-system-and-software-testing-pitfalls

צוות ISTQB® Foundation Agile Tester Certification Extension  נפגש בשבוע שעבר פנים אל הפנים בפריז, למפגש פרודוקטיבי במיוחד.

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

אחד ממובילי הקבוצה הוא אלון לינצקי, סגן נשיא ®ITCB ומנהל השיווק,

,Business Outcomesאשר מוביל בקבוצת ההסמכה החדשה את ה- 

שיווק ההסמכה בעולם, והוא אחד ממחברי הסילבוס והבחינה לדוגמא של ההסמכה.

® ISTQB מתכנן להכריז על הסמכה חדשה זו בסוף מרס 2014.

אם נתקלת בבאג במקרה... או שחזרה תקלה מלקוח - חפש באגים דומים,

סביר להניח שפיקששת סדרה שלמה של באגים מאותו סגנון.

בתרגום חופשי מהמסמך הבא של Cem Kaner.

 

ראה המסמך בלינק הבא, כמו גם רשימת Checklists נוספים באזור הכלים והעזרים שלנו לזיהוי בדיקות המטפלות בבעיות אפשריות נוספות.

http://www.logigear.com/logi_media_dir/Documents/tcs_appA_bugs.pdf#!