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

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

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

he icon   en icon

איך לכתוב בדיקות שישמשו אתכם גם בעתיד?

נכתב על ידי 
שני, 24 יוני 2013 07:44
דרגו כתבה זו
(3 הצבעות)

איך לכתוב בדיקות שישמשו אתכם גם בעתיד?

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

  1. הכי חשוב "מטרת הבדיקה" ו"מטרת סט הצעדים" -  >לפני< שאתם משקיעים זמן רב בתיאור מפורט של הבדיקה, ושל הפעולות שצריך לבצע בכל סט צעדים – כתבו את מטרת הבדיקה, באופן שיאפשר לבא אחריכם (או לכם בעוד מס' חודשים או שנים) להבין "למה התכוון המשורר"?
    מה אתם מתכוונים לבדוק?, כיצד אתם תוקפים זאת?, מדוע דווקא כך?, שיקולים נוספים?, מגבלות והתניות שצריך לשים אליהן לב.
  2. כאשר הבדיקה כוללת מס' רב של צעדים – ו/או הבדיקה מורכבת ממס' תת-מטרות שונות – הקפידו לכתוב לפני כל סט-צעדים את מטרתו באופן דומה ל#1 מעל.
  3. הקפידו להדגיש את מבנה הבדיקה וה"זרימה" הפנימית בבדיקה – לפני כל סט צעדים ציינו בהבלטה (Bold) כותרת קצרה וממצה המציגה את מטרתו, לעיתים כדאי אפילו להבליט חלק מן הטקסט הרלוונטי מתוך תיאור הצעד, המתאר מהי מטרת אותו הצעד.
  4. לעיתים קרובות "מרוב עצים לא רואים את היער" – ולכן אם נצלול מהר מדיי לתיאור מפורט של הבדיקה, נאבד את התמונה הכללית.
    לכן נכתוב תחילה את שלד הבדיקה, ורק אח"כ (במידת הצורך) נרחיב לצעדים מפורטים ותוצאות צפויות.
  5. מבט על – קצר יחסית זה – יאפשר גם לקבל משוב יעיל על הבדיקה בתהליכי ה"בקרה" (Review) – שהרי לעמיתינו אין זמן להתעמק במסמך בן מאות עמודים – ולכן עדיף אם נשלח להם עותק עם פירוט מטרות אך לא צעדים,
    עותק זה גם יכול להיות מוכן לפחות כשבוע לפני העותק המפורט הדורש השקעה נוספת ניכרת – כך שהרווחנו פעמיים – וגם יקל עלינו לבצע השינויים שנובעים מהמשוב, על שלד מסמך מאשר על מסמך מפורט (פחות עבודה חוזרת – ReWork)
  6. כאשר הצוות המבצע הנו מנוסה – עדיף לעיתים לא לפרט יתר על המידה – זה גורם למעקב עיוור אחר צעדי הבדיקה, מבלי שהבודק נפתח ומפעיל שיקול דעת נוסף (אשר יאפשר לו להביא מניסיונו ולזהות חסרים אפשריים בבדיקה המקורית)
    הניסיון מראה כי חזרה על אותן הנחיות (או הנחיות דומות מאוד) שוב ושוב – רק מביאה לכך שהמבצע מפסיק לקרוא ולשים לב לפרטים.
  7. מאידך – רצוי מדיי פעם לפרט את צעדי הבדיקה, על-מנת לוודא כי הבדיקה ישימה, לזהות אילו כלי עזר נדרשים, דבר שגם מאפשר ל"מבקרים" (Reviewers) להתחבר לפרטי הבדיקה ולזהות מראש כשלים אפשריים בדרך בה נכתבה.

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

תאפשרו קבלת משוב מהיר ויעיל יותר,

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

בהצלחה,

קובי הלפרין

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

חדשות מעולם הבדיקות

  • How to avoid missing a bug

    I found Kristin‘s article about how she forgot to retest a bug very funny. Not because it is a joke but because I recognised myself in her story. When others find a bug in 5 minutes, that were there just under my eyes during my one hour session, I cannot avoid feeling bad. And often, those bugs are not tricky ones, they follow a clear pattern, as if the tester would know where the bugs hide — which can be a developer, some developers are very good at testing.Bugs are gregariousWell, in fact, it is exactly how issues behave. Bugs follow predictable patterns: they like to hook to some behaviours or some modules in the product or some kind of features. When one of those actions or place reveal an unexpected behaviour, you can bet a cookie that you will find similar ones if you continue digging. And you will have a delicious breakfast next day. Same issue elsewhere, other issues near to the first one. Bugs, like zombies, feel stronger when they piece together. And when you think of it, this is obvious: the same bugged code can be called in several parts of the application. Some contexts are not well handled by some frameworks or browsers. (Please be patient, I’ll come with concrete examples in the last section.)The power of heuristicsThe fact to find patterns in bugs and to foresee, not with certainty but at least with confidence, a possible weakness in the context of an application has a name. It[…]

    19.09.2019 | 3:51 קרא עוד...
  • Five Blogs – 19 September 2019

    The (best) five blogs I read today. Check them out. How To Spot a Faker Written by: Matt Heusser If Strategy Is So Important, Why Don’t We Make Time for It? Written by: Dorie Clark 10 Brain Training Exercises To Boost Your Brain Power Written by: Michael Gornam What can testers and developers learn from each other? Written by: Lisa Crispin Testing in DevOps Written by: Matthew Bretten Quote of the day: “If you think adventure is dangerous, try routine. It is lethal.” -Paulo Coelho You can follow this page on Twitter

    19.09.2019 | 12:45 קרא עוד...
  • Don't No

    Don't No We've all been there: frustrated by a request from a stakeholder for what we take to be significant new work without regard for the scale of it, the time it would take, or the current backlog.Recently, a colleague in that situation and ready to scream "NOOOOO!!!!" asked for my advice. What I said boiled down to this: Step back and think of at least three ways that the request could be interpreted. Sketch rough ideas for how you could do each of them, at what cost, with what compromises.  Share them with your stakeholder to clarify their desires and help them to guide the next steps. This is essentially Jerry Weinberg's rule of three and orange juice test so I claim no great novelty here. What I do claim is that I feel a lot better when I follow these steps than when I instinctively reject some request based on poor assumptions and no conversation, landing myself in a needlessly defensive position.P.S. just to make this harder, don't forget that you could also be misinterpreting and underestimating requests that you say "yes!" to. It just doesn't usually feel so bad (at the time).Image: https://flic.kr/p/2etM44v

    19.09.2019 | 12:39 קרא עוד...

טיפים

לרשימה המלאה >>