טיפים

לבדוק או לא לבדוק? - זאת השאלה

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

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

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

1. מתי כבר הורצה הבדיקה? – האם יש טעם להריץ אותה כעת שוב?

2. מה השתנה מאז הרצתה הקודמת?

3. האם זו בדיקה ידנית או אוטומטית?

4. כמה זמן לוקח לבצע את הבדיקה?

5. האם בדיקה זו נכשלה אי-פעם בעבר?

6. האם רבים משתמשים בתכונה הנבדקת?

7. האם יש לנו היכולת לבצע ולנתח את תוצאות הבדיקה?

8. האם יש לנו כח אדם / זמן לביצוע הבדיקה?

9. האם הבדיקה הזו עדיין רלוונטית ונכונה?

10. האם זו הדרך הנכונה להריץ הבדיקה בשלב זה?

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

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

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

טיפ זה הופיע בגיליון #1 של מגזין עולם הבדיקות - http://goo.gl/sMeEMH

פוסט זה מבוסס על רעיון שהועלה בפוסט של John Andrews :

http://testingfromthehip.wordpress.com/2014/07/15/release-testing-to-do-or-not-to-do-that-is-the-question

בודק - עקוב אחרי בודקים אחרים בטוויטר ובבלוגים

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

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

כמו שכתב מיכאל ל. : "טוויטר הנו כנס 24/7  לבדיקות ותכנות"

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

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

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

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

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

כל שנדרש הוא להיכנס ל- http://www.twitter.com  וליצור חשבון.

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

ניתן לאתר אנשים וחברות ע"י חיפוש בעזרת שמם, או לרשום את שם הזיהוי שלהם בטוויטר לדוגמה @ITCB_IL_Testers או halperinko@  , וגם לעקוב אחר רשימות מרוכזות של אנשים כגון: Israeli Testers QA  - בה אנו מרכזים רשימה של ישראלים מעולם הבדיקות הפעילים בטוויטר ומעלים הודעות בתחום זה בעיקר.

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

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

בנוסף למעקב כללי אחר הודעות של אנשים ספציפיים, טוויטר מעודד שימוש במילות מפתח hashtags – המסומנות בטוויט בעזרת # - כך שניתן לבצע חיפש מהיר של הציוצים האחרונים שנעשו בנושא #QA, #Testing, #Agile, ואף לקבל מידע ישיר לגבי המתחולל בכנס המתקיים בצדו השני של העולם, כמו #StarEast מארה"ב או EuroStar - #esconfs

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

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

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

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

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

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

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

http://www.mkltesthead.com/2013/07/follow-other-testers-on-twitter-share.html

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

ולהוסיף טיפים משלכם לרשימה משותפת זו.

 

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

99 Things Testers Can Do To Become Better Testers

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

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

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

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

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

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

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

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

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

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

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

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

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

בעבודה - ניתן להקצות 2-4 שעות שבועיות ולצפות ביחד בסרטוני ה-BBST או סרטונים דומים (קישורים וסדר לימוד עצמי ראו בהודעה הנעוצה בפורום הדרכות באתר ITCB), לעצור בנקודות הנראות מעניינות, ולדון בנושאים – מה אנו למדים מהם? האם יש בין הדברים רעיונות שנרצה לקחת לשיפור צורת העבודה הנוכחית?

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

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

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

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

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

http://www.mkltesthead.com/2013/07/take-association-for-software-testing.html

 

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

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

99 Things Testers Can Do To Become Better Testers

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

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

צור מפת חשיבה – Mind Map

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

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

(בדומה לטבלאות רבות מימדים וצבעים)

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

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

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

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

וגם כאשר נחליט לתאר בקצרה את הנושאים הנבדקים – לדוגמה לקראת ותוך כדי בדיקות חוקרות (ET).

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

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

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

http://www.mkltesthead.com/2013/07/create-mindmap-rosie-sherry-99-ways.html

התמונה מ:

https://www.examtime.com/blog/6-tips-on-how-to-create-an-online-mind-map-with-examtime

 

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

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

99 Things Testers Can Do To Become Better Testers

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

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

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

בודק היה ביקורתי אך אל תעביר ביקורת -  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 - בה מיכאל מרחיב על כל אייטם וגם מספק הנחיות כיצד לתרגל הנושא.