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

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

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

he icon   en icon

halperinko

halperinko

חמישי, 22 ינואר 2015 12:18

!State of Testing Survey 2015 is Live

State of Testing Survey 2015 is Live!

http://qablog.practitest.com/state-of-testing

השתתפו בסקר והשפיעו

 

State of testing 2015

 

והזוכים בפרס לעידוד מצוינות ולתרומה לקהילת הבודקים בישראל 2014 הם:

 

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

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

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

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

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

פרטים נוספים בטופס ההגשה של Cisco

במסלול התהליכי זכתה חברת "נייס אקטימייז" בפרויקט "QA Dashboard" – הפרויקט הוגש ע"י עמיר ישראלי שהציג פתרון תהליכי הנתמך בכלי פנימי הנותן מענה לטיפול בבאגים שדווחו ע"י לקוחות (Escaped Defects) . הפתרון כלל אנליזה איכותית, הגדרת התיקון והצגה בזמן אמת על מצב הבאגים והאזורים עליהם יש להשים דגש. התהליך גרם לשיפור משמעותי בכמות התקלות שדווחו ע"י הלקוחות (ירידה  של כ 30% שנה אחר שנה), שיפר את איכות המוצרים , הווה בסיס למיקוד נקודות החולשה והפך לסטנדרט בהנהלת החברה.

פרטים נוספים בטופס ההגשה של NICE Actimize

 

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

לנוחיותכם, מצורפים טפסי ההגשה של שני הזוכים.

בברכה,

יגאל לוי

יו"ר הוועדה

 

לצפייה בפרטי התחרות:

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

 

ההזמנה להגשת מועמדות לפרס 2014

 

And the winners of the Testing Excellence Award for 2014 are:

Every year the ITCB (Israeli Testing Certification Board) encouraging the testing community to submit project for the Testing Excellence competition.

A committee on behalf of ITCB reviews a large number of presented projects along the year and examines the projects according to many criteria, verifying the quality of the project as well as the contribution to the organization and the testing community.

The final candidates present the project in front of the committee, and asked to present relevant materials to comply the requested criteria.

Due to the high quality of projects presented this year, the committee has decided to share the first place between 2 candidates.

 

In the Technological track won Cisco company in the "Phoenix" project –

The project was submitted by Ouriel Gottlieb who presented an Automation solution

This answers the needs of testing many platforms within a short period of time, with high coverage, low maintenance and high quality.

Additional details in Cisco registration form.

 

In the Procedural track won Nice Actimize company in the "QA Dashboard" project –

The project was submitted by Amir Israeli who presented a procedural solution supported by an internal tool,

Which answers the need to handle bugs reported by clients (Escaped Defects).

The solution included high quality analysis, definition of required remedy, and live presentation of the status of the bugs and areas which should be focused on.

The process made a major improvement in amount of failures reported by the clients (Around 30% drop year after year),

Improved the quality of the products, served as basis for focusing on the weak-points and became a standard in the company management.

Additional details in Nice Actimize registration form.

 

It is important to note that the two projects which won can be assimilated in other organizations with just minor changes and by that contribute to the Israeli Testers and Testing Community.

For you convenience, we attach here the registration forms of both winners.

Best Regards,

Igal Levi

Committee chairman

 

במסלול הטכנולוגי זכתה חברת "סיסקו"  בפרויקט "פניקס"– הפרויקט הוגש ע"י אוריאל גוטליב:

CiscoTeam 2014 Award 2 

 

במסלול התהליכי זכתה חברת "נייס אקטימייז" בפרויקט "QA Dashboard":

במסלול הטכנולוגי זכתה חברת "סיסקו"  בפרויקט "פניקס"– הפרויקט הוגש ע"י אוריאל גוטליב

 

 

 

 

בודק היה ביקורתי אך אל תעביר ביקורת -  Be Critical But do Not Criticize

בודק היה ביקורתי אך אל תעביר ביקורת או תפזר האשמות -  "Be Critical But do Not Criticize" –

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

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

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

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

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

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

בכדי להביא לפתרון הבעיות אותן אנו מזהים – עלינו ליצור אווירה של שיתוף פעולה.

ככול שנעבוד באווירה ידידותית – כך יקל עלינו להשפיע על איכות המוצר.

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

זכרו – גם כשאתם מבשרים על באגים – עשו זאת בצורה נעימה.

חומר קריאה נוסף:

http://www.mkltesthead.com/2013/07/be-critical-but-do-not-criticize-99.html

 

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

סדרת טיפים זו "כיצד להפוך לבודקים טובים יותר" מתבססת על דיון ב: Software Testing Club

99 Things Testers Can Do To Become Better Testers

ה-eBook החינמי שנוצר בעקבות דיון זה: 99ThingsEbook.pdf

וסדרת פוסטים מאת Michael Larsen בשם: Ways Workshop 99 - בה מיכאל מרחיב על כל אייטם וגם מספק הנחיות כיצד לתרגל הנושא.

מבט מערכתי לבודקים – Systems Thinking

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

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

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

מה יקרה כאשר הגישה לרשת הנתונים משובשת ובזמן עומס יתר?

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

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

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

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

חומר קריאה נוסף:

http://www.mkltesthead.com/2013/07/get-understanding-of-systems-thinking.html

 

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

סדרת טיפים זו "כיצד להפוך לבודקים טובים יותר" מתבססת על דיון ב: Software Testing Club

99 Things Testers Can Do To Become Better Testers

ה-eBook החינמי שנוצר בעקבות דיון זה: 99ThingsEbook.pdf

וסדרת פוסטים מאת Michael Larsen בשם: Ways Workshop 99 - בה מיכאל מרחיב על כל אייטם וגם מספק הנחיות כיצד לתרגל הנושא.

 

SystemThinking habitsofst

 

 

שישי, 26 דצמבר 2014 11:01

בודק - השאר ממוקד מטרה

Targetבודק - "השאר ממוקד מטרה / Keep Your Eye on the Ball - The End Goal " – כבודקים בעלי יכולת מיקוד וירידה לפרטים, לעיתים אנו מאבדים את התמונה הכוללת וצוללים יתר על המידה בבדיקת נושאים זניחים.

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

 

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

אז איך מזהים?  -  הדרך הכי פשוטה היא להבין מה ה-main system usage שלנו.

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

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

 

כלומר - חשוב לזכור איזה ערך מייצגת כל בדיקה למשתמש - ולהשקיע את מירב זמננו באזורים ובמקרי השימוש (Use Cases) החשובים למשתמש.

 

חומר קריאה נוסף:

http://www.mkltesthead.com/2013/07/keep-your-eye-on-ball-end-goal-99-ways.html

 

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

סדרת טיפים זו "כיצד להפוך לבודקים טובים יותר" מתבססת על דיון ב: Software Testing Club

99 Things Testers Can Do To Become Better Testers

ה-eBook החינמי שנוצר בעקבות דיון זה: 99ThingsEbook.pdf

וסדרת פוסטים מאת Michael Larsen בשם: Ways Workshop 99 - בה מיכאל מרחיב על כל אייטם וגם מספק הנחיות כיצד לתרגל הנושא.

רביעי, 03 דצמבר 2014 13:25

354000Certified testers world-wide

354000 certified testers world-wide!

As of June 2014, ISTQB® has issued almost 354,000 certifications in over 100 countries world-wide, with a growth rate of more than 12,000 certifications per quarter.

See more facts and figures here: http://www.istqb.org/about-istqb/facts-and-figures.html 

 

ISTQB 354K Cert

רביעי, 03 דצמבר 2014 13:14

354000-Certified testers world-wide

354 000 certified testers world-wide!

As of June 2014, ISTQB® has issued almost 354,000 certifications in over 100 countries world-wide, with a growth rate of more than 12,000 certifications per quarter.

See more facts and figures here: http://www.istqb.org/about-istqb/facts-and-figures.html 

 

ISTQB 354K Cert

בודק - הבן את המודל והאתגרים העיסקיים

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

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

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

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

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

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

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

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

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

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

חומר קריאה נוסף:

http://www.mkltesthead.com/2013/07/99-ways-workshop-13-understand-business.html

 

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

סדרת טיפים זו "כיצד להפוך לבודקים טובים יותר" מתבססת על דיון ב: Software Testing Club

99 Things Testers Can Do To Become Better Testers

ה-eBook החינמי שנוצר בעקבות דיון זה: 99ThingsEbook.pdf

וסדרת פוסטים מאת Michael Larsen בשם: Ways Workshop 99 - בה מיכאל מרחיב על כל אייטם וגם מספק הנחיות כיצד לתרגל הנושא.

ראשון, 07 ספטמבר 2014 19:44

בודק - למד להסביר

בודק - למד להסביר

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

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

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

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

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

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

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

עלינו לוודא כי למי ששומע או קורא את ההסבר יש ידע ברקע הנדרש להבנת הנושא – בשיחה פתוחה עלינו לזכור לתשאל אותו ולוודא זאת.

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

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

חומר קריאה נוסף:

http://www.mkltesthead.com/2013/07/99-ways-workshop-11-learn-to-explain.html

 

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

סדרת טיפים זו "כיצד להפוך לבודקים טובים יותר" מתבססת על דיון ב: Software Testing Club

99 Things Testers Can Do To Become Better Testers

ה-eBook החינמי שנוצר בעקבות דיון זה: 99ThingsEbook.pdf

וסדרת פוסטים מאת Michael Larsen בשם: Ways Workshop 99 - בה מיכאל מרחיב על כל אייטם וגם מספק הנחיות כיצד לתרגל הנושא.

 Explain Testing

 

שבת, 30 אוגוסט 2014 11:09

בודק - למד לשאול – Learn to Question

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

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

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

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

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

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

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

קם קאנר, ג'יימס באך, ומיכאל בולטון מדגישים את נושא החשיבה הביקורתית (Critical Thinking) – חשיבה בעלת מטרה, בקרה עצמית, המספקת פירוש, ניתוח והסבר לגבי הראיות והשיטות עליהן מתבסס שיפוטנו, והשימוש בשיטות אלו בכדי להתגבר על הטיות כתוצאה משיחוד דעתנו, עיוורון בלתי רצוני, ושימוש בהנחות שאינן מבוססות.
ג'יימס ומיכאל אף כתבו על כך מצגת מעניינת:
 http://www.developsense.com/presentations/2012-11-EuroSTAR-CriticalThinkingForTesters.pdf

ג'יימס נוהג לחלק את בחינת רמת הבנתנו ל-3 קבוצות:

Huh? – האם אני באמת מבין?, האם אנו מדברים על אותו הדבר?, האם הנושא מעורפל?
Really? – מה גורם לי להאמין?, איך אני יודע שמה שנאמר הוא באמת נכון?, האם זה מגובה בעובדות?

So? – האם זהו הפתרון/המסקנה היחידה?, למה זה משנה?, למי זה משנה?, עד כמה זה משנה?

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

חומר קריאה נוסף:
(שימו לב כי במקרה זה מיכאל תוקף הנושא בצורה שונה מזו בה אני הרחבתי הנושא – ולכן כדאי מאוד לקרוא בנוסף)

http://www.mkltesthead.com/2013/07/99-ways-workshop-11-learn-to-question.html

 

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

סדרת טיפים זו "כיצד להפוך לבודקים טובים יותר" מתבססת על דיון ב: Software Testing Club

99 Things Testers Can Do To Become Better Testers

ה-eBook החינמי שנוצר בעקבות דיון זה: 99ThingsEbook.pdf

וסדרת פוסטים מאת Michael Larsen בשם: Ways Workshop 99 - בה מיכאל מרחיב על כל אייטם וגם מספק הנחיות כיצד לתרגל הנושא.

 No-Comm