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

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

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

he icon   en icon

רביעי, 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

איך להתכונן לבחינת ההסמכה של ISTQB Foundation Level

על מנת להתכונן לבחינת ההסמכה, טוב קודם כל להבין את מבנה הבחינה.

המבנה מוסבר באתר של ITCB,
בדף הזה: http://www.itcb.org.il/index.php?option=com_k2&view=item&layout=item&id=11&Itemid=430

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

אני מחכה...

חזרתם? יופי. אפשר להמשיך.

קצת תוספות מידע על ההסבר שבאתר ITCB, ועל הסילבוס:

תוכנית הלימודים להסמכה בסיסית (Foundation Level)

נתחיל בסילבוס.

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

שמעתי לא מעט טענות נגד זה: מה חשוב כל כך לדעת מה כל מושג אומר? למה אני צריך לזכור את זה בעל-פה?

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

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

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

 

K-Levels

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

זה אומר שכדי לענות בהצלחה על שאלות K1 צריך לזכור חומר.

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

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

http://www.itcb.org.il/index.php?option=com_k2&view=item&layout=item&id=10&Itemid=429

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

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

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

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

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

דוגמה אחרת היא הדרישה שנבחנים ידעו לכתוב דו"ח פגמים (bug report). גם כאן לא תדרשו לכתוב כלום – אלא לבחור איזה מארבע דוחו"ת הוא הטוב ביותר. כתיבת דוחו"ת פגמים (bug reports) בעבודה היום יומית תוך העזרות בחומר הנלמד על מנת שלא לשכוח פרטים נדרשים, תעזור להפנים איך לכתוב נכון דו"ח כזה.

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

סוג נוסף של שאלות K4 הן אלה המתייחס לרמת כיסוי של קוד. ברוב השאלות האלה ניתן קטע קוד קצר ומקרי בדיקה, והשאלה היא איזה רמת כיסוי הושגה. זה אומר שיש ציפייה שתדעו לקרוא קוד. השאלות לא כתובות בשפת תכנות מסויימת אלא בסגנון שקרוי "פסבדו קוד" (pseudo code). כלומר, כללית זה נראה כמו קוד, אבל אין שום מאמץ לשמור על syntax נכון; או שבמקום לכתוב שורות קוד אמיתיות כתוב "do something". מן הסתם, מי שלא למד תכנות אף פעם יתקשה יותר בשאלות אלה. אני מציע לכם (א) תלמדו תכנות בשפה כלשהיא. ידע בסיסי בתכנות זה די דרישת סף בימינו לקבלת עבודה כבודק מקצועי. ו – (ב) תתאמנו קצת על שאלות מסוג זה. אם אין לכם מספיק דוגמאות – תשבו יחד כמה אנשים ותייצרו דוגמאות אחד לשני. זה גם ייתן לכם השתפשפות בקריאת פסבדו-קוד וגם יכין אתכם לשאלות מסוג זה.

 

יעדי הלימוד

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

עוד דבר הקשור ליעדי הלימוד: השאלות בבחינה נכתבות כך שיהיו ברמה של יעד הלימוד (מבחינת K-level). כלומר שאם יעד הלימוד סומן כ – K2, לא תשאל עליו שאלה מסוג
K3, ועקרונית גם לא K1. אני אומר "עקרונית" כי מניסיוני רב השנים בכתיבת וסקירת שאלות, לעיתים קשה מאוד לקבוע אם שאלה מסוימת היא K1 או K2 ואפשר לנהל על זה ויכוח ארוך ומיותר אל תוך הלילה. בקיצור – אם כתוב K2, כדאי לא להזניח את ההגדרות שמופיעות בפרק; וממילא הבנה של נושא מצריכה ידיעה של המושגים המסבירים את אותו נושא.

 

שאלות דוגמה

כתיבת שאלות בחירה היא משימה לא קלה.

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

בקיצור – לא פשוט.

מה שאומר שהרבה מהשאלות שמסתובבות באינטרנט הן ברמה נמוכה יותר ממה שתתקלו בבחינה (קלות מידי; לא מכסות את ה-K level המתאים וכו').

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

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

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

 

ספרים מומלצים

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

http://itcb.org.il/index.php?option=com_k2&view=item&id=151:רשימת-ספרי-בדיקות-מומלצים&Itemid=757

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

 

המלצות כלליות

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

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

- לא להיתקע על שאלה. המבחן אורך 60 דקות (בשפת-אם) או 75 דקות (בשפה שאינה שפת-אם). זה אומר בין דקה או שתיים לשאלה. נתקלתם בשאלה קשה? תדלגו הלאה ותחזרו אליה אחר כך.

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

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

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

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

 

בחינות של ITCB

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

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

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

 

לסיכום: איך להתכונן לבחינה:

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

- לקרוא (רצוי ספר או שניים!)

- לקרוא את הסילבוס יותר מפעם אחת (יש תרגום לעברית!)

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

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

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

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

 

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

http://www.itcb.org.il/index.php?option=com_k2&view=item&layout=item&id=11&Itemid=430 
(שווה לבדוק מידי פעם אם יש משהו חדש גם ב ISTQB - באתר  http://www.istqb.org/downloads/category/14-exam-documents.html )

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

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

פורום ITCB:

http://itcb.org.il/index.php?option=com_kunena&view=category&catid=1&layout=list&Itemid=379

פורום תפוז:

http://www.tapuz.co.il/Forums2008/forumpage.aspx?forumid=936

וב – Facebook:

https://www.facebook.com/groups/IL.Testing.QA 

 

ITCB-SampleExam1

 

אז שיהיה בהצלחה!

מיכאל שטאל

אחראי על הבחינות ב - ITCB

 

הערה: פוסט זה הוא דעתי הפרטית ואינו מחייב את ITCB או את ISTQB. הוא מפורסם מתוך רצון טוב לעזור, אך אינו התחייבות מבחינת ITCB או ISTQB לפרטי הבחינות.

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

פורסם ב בלוג

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

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

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

ב. זה לא משהו שאתה מתעסק איתו ביום יום, המערכת קיימת וזהו

 

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

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

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

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

Automation Framework

התמונה לקוחה מהאתר: http://www.zenqconnect.com/images/Automation-Framework.png

 

Application Under Test (או - System Under Test) – זהו המוצר שעליו אנחנו מריצים את הבדיקות.

 

Object Repository – בסיס נתונים השומר בתוכו מידע על אובייקטים לבדיקות המבוססות GUI. כל שינוי באובייקטים הללו מצד המוצר יגרור שינוי מרכזי כאן , ללא נגיעה בקוד. למשל האובייקט שנקרא כפתור ישמר ב-OR ואיתו ביחד כל המאפיינים שלו כמו גודל, צבע, רקע , ID , שם Class, וכו'.

 

Config & Global Variables – בסיס נתונים המיוצג בדרך כלל כקובץ אשר מכיל בתוכו משתנים גלובאליים שהם בד"כ אינם משתנים לאורך הריצה (לדוגמא: מיקום ספרייה מסויימת שם יושבים קבצי הלוג) הם ישמשו אותנו בכל איזור בקוד בו אנו נמצאים וכן פרמטרים משתנים (כמו למשל שם המכונה, שם המשתמש, שם גרסה וכו').

 

Common Business Automation Scripts – אני לא כל כך מסכים עם שם הקומפוננטה הזו, הייתי קורא לה Function Library והיא באה לאגד את פונקציות הבסיס (Building Blocks) השימושיות ביותר במוצר, כמו למשל – לחיצה על כפתור. כאן יושב הלב הפועם של הבדיקות האוטומטיות.

 

Input Data – כאן יושב ה-Data של מקרי הבדיקה, בשיטת ה-Data Driven Testing, היינו מחליפים בקומפוננטה הזו את הקישור לבסיס מידע אחר, בסיסי נתונים יכולים להיות מיוצגים כקבצי XML , Excel, Access, NotePad , קובץ Dump ועוד.

 

Execution – החץ המופנה אל עבר ה-AUT למעשה בא להגיד לנו שפה יושב כלי ההרצה איתו אנו עובדים, כלי כמו AutoIT או Selenium, הקוד נכתב ב-IDE של הכלי ואילו הריצה מתבצעת במנוע ההרצה שלו (Parser + Test Runner).

 

Automation Test Scripts – קומפוננטה זו תכיל אוסף של טסטים ביזנסיים הכתובים כסקריפטים, היא תכיל את הלוגיקה בקוד שמבצעת את מקרי הבדיקה, היא יושבת מעל ה-Function Library ואליה היא קוראת מספר רב פעמים, למשל: לחיצה על כפתור עם סט של פרמטרים נלווים כמו מזהה ייחודי, כמה פעמים ללחוץ, אורך זמן הלחיצה וכו'. אם ה-Function Library הוגדר כ-לב הפועם, הרי שקומפוננטה זו תוגדר כ-מוח של כל המערכת.

 

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

 

Reporting – קומפוננטה שאמורה לקחת את תוצאות הריצה כולל הצלחות, כשלונות ו-exceptions למיניהם ולהציג אותן למשתמש, הכלל החשוב כאן הוא שהנתונים צריכים להיות הכי ברורים שאפשר, במיוחד אם בודקים כאן מוצר גדול ומורכב. הדוחות אמורים לכלול, בנוסף לתוצאות הריצה הכלליות, גם מידע על תוצאות verification points וכן של זמנים. כדאי מאוד שיילקח Screen Shot ויצורף לכל אחד מן הסטפים של ההרצה. מומלץ גם שלקומפוננטה תהיה היכולת להפיץ את ה-reports בצורה נוחה (כמו למשל שליחת מייל תפוצתי).

 

Common Library– בנוסף ליכולת הסקריפטים האוטומטיים לקרוא מתוך ה-Function Library, יש גם את האפשרות לקרוא מתוך ספריות חיצוניות שלא קשורות בהכרח לפרוייקט האוטומציה שלנו, כמו למשל פונקציות מתמטיות, עבודה עם קבצים וכו'.

 

Driver Script – יכיל בתוכו את ה-Clean Up Scripts שתפקידם יהיה לנקות את סביבת ההרצה (קבצים, DB) לפני כל הרצה או כמה הרצות וכן את ה-Scheduler שאיתו נוכל לתזמן הרצות בצורה אוטומטית, ניתן יהיה לקבוע יום ושעה , לקבוע מתי אסור לרוץ (למשל כשרץ במערכת פרוסס End of Day) וכן לקבוע תלויות בין הרצות, כמו למשל שטסט 2 לא ירוץ עד אשר טסט 1 לא סיים את הרצתו בהצלחה.

 

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

 

תוספות ושינויים:

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

ה-Keyword Driven testing (KDT) תיתן לנו את היכולת לבנות טסטים אוטומטיים גם מבלי לדעת קוד.

מעל שכבת ה-Function Library ניצור קומפוננטה חדשה שתיקרא: KDT Engine, השכבה הזו תדע לקשר בין הפונקציות הקיימות במערכת לבין שכבה עליונה יותר שתהווה את ה-GUI למשתמש.

KDT GUI – יציג לאותו בודק ידני \ מיישם אוטומציה חלון ובו הוא יוכל לבנות (בין אם זה לגרור, לבחור או לכתוב) אובייקטים שונים עליהם ניתן לבצע אוסף פעולות, זה בנוסף ללוגיקה ביזנסית ייצרו מקרה בדיקה, ה-GUI יכול להיות מיוצג כאפליקציה דסקטופית, מסמך אקסל או אפילו web page. קומפוננטה זו תהיה מקבילה ל-Automation test Scripts.

 

-----------------------------------------------------------------

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

היכנסו לאתר שלי: http://atidcollege.co.il

יוני פלנר.

 

 

פורסם ב בלוג
שבת, 16 אוגוסט 2014 12:22

בדוק מוקדם ככול הניתן

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

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

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

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

באג'ייל השתמרו תהליכי התנעה – רק שעכשיו הם אינם במסגרת תכונה אלא במסגרת סיפור – Story Kick-Off, וגם כאן נהוג להפגש ולדון בהגדרות הסיפור בפגישות דומות הנקראות: Three Amigos Meetings(קראו לגביהן עוד במאמר של מיכאל בלינק למטה).

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

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

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

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

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

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

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

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

http://www.mkltesthead.com/2013/07/99-ways-workshop-9-test-as-early-as.html

 

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

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

99 Things Testers Can Do To Become Better Testers

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

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

 

Early Testing 2

Early Testing 1

 

 

פורסם ב טיפים

 עבודת בודקים בצמד עם המפתח

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

בשנים האחרונות עם עליית שיטות אג'יליות ו- Extreme Programming צורת עבודה זו יותר נפוצה.

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

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

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

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

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

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

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

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

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

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

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

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

http://www.mkltesthead.com/2013/07/99-ways-workshop-8-pair-with-developers.html

 

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

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

99 Things Testers Can Do To Become Better Testers

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

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

 Pair testing

 

פורסם ב טיפים

בודק - בחן את דרך פעולתך מידיי יום

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

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

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

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

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

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

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

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

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

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

מהיכן מגיעים רעיונות לשינוי?

מהתחושה כי משהו אינו נוח / חסר / לא יעיל.

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

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

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

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

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

http://www.mkltesthead.com/2013/07/99-ways-workshop-6-question-way-you.html

 

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

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

99 Things Testers Can Do To Become Better Testers

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

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

 

Paths1

פורסם ב טיפים
חמישי, 10 יולי 2014 05:57

אתר קהילה חדש בשם TEST Huddle

אתר קהילה חדש בשם
TEST Huddle
מחליף את אזור המידע באתר של EuroStarConferences.com
מומלץ להרשם


http://testhuddle.com

 

TestHuddle-Icon

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

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

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

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

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

 

Determined Dog

פורסם ב בלוג

Learning

אף פעם אל תפסיקו ללמוד - בדיקות

" אף פעם אל תפסיקו ללמוד" – או כמו שנאמר "רק טיפשים יודעים הכל".

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

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

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

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

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

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

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

אתם מוזמנים לקרוא עוד על כך בבלוג שלנו בפוסט: איזה רקע נוסף רצוי שיהיה לבודק?

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

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

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

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

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

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

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

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

באתר www.itcb.org.il  תחת דף "מעולם הבדיקות" ריכזנו לכם עדכוני RSS מהארץ והעולם – בכדי להקל עליכם למצוא העדכונים המעניינים האחרונים.

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

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

http://www.mkltesthead.com/2013/07/99-ways-workshop-3-never-stop-learning.html

http://www.mkltesthead.com/2013/07/99-ways-workshop-4-and-recognize-that.html

 

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

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

99 Things Testers Can Do To Become Better Testers

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

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

LearnTogether

 

פורסם ב טיפים
עמוד 4 מתוך 6