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

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

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

he icon   en icon

ראשון, 29 יוני 2014 10:21

הכירו את לקוחותיכם

הכירו את לקוחותיכם

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

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

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

נושא זה והנושא המקביל לו "עבדו כתמיכת לקוחות לזמן מה" שהועלו ע"י Chris George – הינם 2 הנושאים הראשונים ב-eBook ולא בכדי,

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

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

אז – איך נוכל להכיר את הלקוח/ה שלנו?

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

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

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

 

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

http://www.mkltesthead.com/2013/07/99-ways-workshop-1-get-to-know-your.html 

http://www.mkltesthead.com/2013/07/99-ways-workshop-2-work-first-line.html 

http://blog.ruberto.com/2013/06/engage-customers-directly-to-build-high-quality-software

 

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

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

99 Things Testers Can Do To Become Better Testers

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

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

 

 KnowYourCustomers

 

פורסם ב טיפים

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

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

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

 

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

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

פורסם ב טיפים

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

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

 

מה זה בכלל בדיקות?

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

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

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

 

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

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

תאורטית - נדרש מעין סרטון תדמית למקצוע – אך מכיוון שלא הצלחתי לארגן הכנתו (עדיין? cool) נתחיל מתאור כתוב:

 

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

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

 

תפקיד הבודק מתחלק למספר פעילויות:

לרוב ישנן תקופות (מימים עד שבועות) בהן מתמקדים יותר בפעולה אחת מתוך אלו, אח"כ עוברים לשלב הבא וכד'.

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

2. ניתוח המידע המהווה בסיס לבדיקות,

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

   לרוב מתבצע בשני שלבים:

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

      ב. השתלבות בישיבה עם משתתפים מתפקידים שונים.

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

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

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

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

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

תוך כדי ריצה - לרוב נעדכן מסמך תוצאות והתקדמות.

7. פיתוח בדיקות אוטומטיות,

8. הרצת בדיקות אוטומטיות וניתוח תוצאותיהן,

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

10. דיווח באגים - במערכות דיווח / תוכנה לניהול באגים,

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

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

 

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

וכך חוזר חלילה...

 

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

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

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

 

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

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

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

(כמו שנאמר – "למה האחרונים תמיד בסוף" laugh )

 

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

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

http://itcb.org.il/index.php?option=com_kunena&view=category&catid=8&Itemid=632

 

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

פורסם ב בלוג

האם גם אתם כמו בת-היענה טומנים הראש בחול?

- או שאתם משתתפים בפעילויות קהילת הבודקים?

 

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

אך אני נתקל בבודקים רבים אשר נסחפים בלחץ היום-יומי,

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

 

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

בדף מעולם הבדיקות - ריכזנו עבורכם מידע רב מאתרים שונים בארץ ובעולם,

בכדי שלא תצטרכו להתרוצץ ולחפש אותו על פני אתרים רבים.

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

 

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

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

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

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

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

 

 

התחברו לרשתות החברתיות של פורום בדיקות

וחברו את חבריכם / חברותיכן

וכך תעזרו להם לגלות את עולם הבדיקות מחדש!

 

כמו כן ניתן לקבל עדכונים גם ב:

  •         פייסבוק:

https://www.facebook.com/groups/405915096141090

  •         תפוז:

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

  •         עשו Follow לדף הבית של ITCB קבלת המידע ב- LinkedIn :

http://www.linkedin.com/company/itcb---israeli-testing-certification-board?trk=top_nav_home

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

http://www.linkedin.com/profile/view?id=203904058&

  •         ב- +Google :

https://plus.google.com/u/0/b/101407766666630341390/communities/103330560020303339830

  •         לאלו מכם המעדיפים לעקוב אחר העדכונים בטוויטר...

https://twitter.com/ITCB_IL_Testers

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

https://twitter.com/ITCB_IL_Testers/lists/israeli-testers-qa

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

http://paper.li/halperinko/1325683839#

(תוכנו מופיע גם בדף מעולם הבדיקות - ובפורמטים נוספים באזור הכלים והעזרים)

 

        >>> עזרו לנו לקדם את תפוצת העדכונים ומקורות המידע לבודקים נוספים, ע"י Share/Like <<<

 

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

 

בברכה,

קובי הלפרין

 

האם גם אתם כמו בת-היענה טומנים הראש בחול?

- או שאתם משתתפים בפעילויות קהילת הבודקים?

 

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

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

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

אבל ניתן להאיץ לימוד זה ע"י קריאה ושיתוף ניסיון של אחרים -

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

 

התחברו לרשתות החברתיות של פורום בדיקות

וחברו את חבריכם / חברותיכן

וכך תעזרו להם לגלות את עולם הבדיקות מחדש!

 

כמו כן ניתן לקבל עדכונים גם ב:

  •         פייסבוק:

https://www.facebook.com/groups/405915096141090

  •         תפוז:

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

  •         עשו Follow לקבלת עדכוני המידע מ-ITCB  ב- LinkedIn:

http://www.linkedin.com/company/itcb---israeli-testing-certification-board?trk=top_nav_home

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

http://www.linkedin.com/profile/view?id=203904058

  •         ב- +Google:

https://plus.google.com/u/0/b/101407766666630341390/communities/103330560020303339830

  •         לאלו מכם המעדיפים לעקוב אחר העדכונים בטוויטר...

https://twitter.com/ITCB_IL_Testers

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

https://twitter.com/ITCB_IL_Testers/lists/israeli-testers-qa

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

http://paper.li/halperinko/1325683839#

  •         >>> עזרו לנו לקדם את תפוצת העדכונים ומקורות המידע לבודקים נוספים, ע"י Share/Like <<<

 

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

 

בברכה,

קובי הלפרין

 

חמישי, 12 ספטמבר 2013 07:54

הסבר על יתרונות ISTQB

הסבר על יתרונות ISTQB

 

פורסם ב חדשות ITCB

חשוב לנתח באגים שהתגלו ע"י הלקוח

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

כמו גם - מהיכן נבע הבאג מלכתחילה.

 

אין כאן תהליך של חיפוש אשמים - אלא תהליך של ארגון לומד ומשתפר.

 

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

ולכן חשוב מאוד לתת תשומת לב לבעיות שעלו מן השטח.

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

 

טיפים מחברי ITCB-AB

פורסם ב טיפים

הערכות זמנים הינן תהליך חשוב להצלחת הבדיקות

לא תמיד יעזור להוסיף בודקים  - זכרו "תשע נשים לא יולדות בחודש..."laugh

להוספת בודקים יש עלויות נלוות של הכשרה, ניהול ועוד.

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

טיפים מחברי ITCB-AB

פורסם ב טיפים

בדיקות מוצלחות = בדיקות בראיית לקוח -

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

טיפים מחברי ITCB-AB

פורסם ב טיפים
שישי, 19 יולי 2013 15:34

אל תפסיקו לשאול שאלות...

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

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

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

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

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

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

טיפים מחברי ITCB-AB

 

פורסם ב טיפים