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

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

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

he icon   en icon

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

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

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

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

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

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

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

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

בהצלחה,

קובי הלפרין

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

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

  • 75: Modern Testing Principles - Alan Page

    Software testing, if done right, is done all the time, throughout the whole life of a software project. This is different than the verification and validation of a classical model of QA teams. It's more of a collaborative model that actually tries to help get great software out the door faster and iterate quicker. One of the people at the forefront of this push is Alan Page. Alan and his podcast cohost Brent Jensen tried to boil down what modern testing looks like in the Modern Testing Principles. I've got Alan here today, to talk about the principles, and also to talk about this transition from classical QA to testing specialists being embedded in software teams and then to software teams doing their own testing. But that only barely scratches the surface of what we cover. I think you'll learn a lot from this discussion. The seven principles of Modern Testing: Our priority is improving the business. We accelerate the team, and use models like Lean Thinking and the Theory of Constraints to help identify, prioritize and mitigate bottlenecks from the system. We are a force for continuous improvement, helping the team adapt and optimize in order to succeed, rather than providing a safety net to catch failures. We care deeply about the quality culture of our team, and we coach, lead, and nurture the team towards a more mature quality culture. We believe that the customer is the only one capable to judge and evaluate the quality of our[…]

    23.05.2019 | 2:00 קרא עוד...
  • Five Blogs – 23 May 2019

    The (best) five blogs I read today. Check them out. Change management in the agile world – Getting ready for WAR Written by: Dianne Inniss Product Roles, Part 6: Shorten Feedback Loops Written by: Johanna Rothman Why I Am a Tester Written by: James Bach Seven Issues Testers Experience Being Agile Written by: Thomas Cagley Defining Observability For Robotics Written by: Ian Sherman Quote of the day: “We are products of our past but we don’t have to be prisoners of it” -Rick Warren You can follow this page on Twitter

    23.05.2019 | 1:20 קרא עוד...
  • Testing Culture – Excuses, Blame and Fear

    I came across an interesting article which discussed common excuses that testers make:http://thethinkingtester.blogspot.com/2019/05/seven-excuses-software-testers-need-to.html There were 3 which I found particularly worrying: The other tester on my team missed the bug If I log the bug I found in production, I’ll be asked why I didn’t find it sooner. There wasn’t enough time to test If a tester needs to use these excuses, then the issue might not be with testing but with the company culture. A company culture where colleagues are encouraged to make excuses, attempt to shift the blame on someone else, or instil enough fear so someone is afraid to report something critical is not a good one. “There wasn’t enough time to test” This particular excuse will always exist and it is a valid one. There will be strict release deadlines which can’t always be pushed back. When the software has to be released, it has to be released. The tester has very little control over this. However, it doesn’t mean that the tester is entirely blameless if a critical bug makes its way to live. It is the testers responsibility to ensure that the tests are optimised and prioritised. Tests covering the most essential features should be run first. Tests should also be optimised so that they are run as quickly and efficiently as possible. Occasionally, the tester may be in the unfortunate situation where there isn’t enough time to test even the most essential features. It is also the testers responsibility to communicate what the[…]

    22.05.2019 | 11:30 קרא עוד...

טיפים

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