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

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

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

he icon   en icon

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

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

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

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

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

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

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

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

בהצלחה,

קובי הלפרין

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

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

  • Day 6: Read and share an interesting blog post on API testing.

    Day 6: Read and share an interesting blog post on API testing. Yet Another Challenge! Ministry of Testing got us 30 days Testing Challenge.This time topic is on API Testing.Challenge Link:  https://www.ministryoftesting.com/dojo/lessons/30-days-of-api-testing  It has been long time I have worked on API Testing, after learning from API Testing Dojo (year 2015).Sixth Challenge is Read and share an interesting blog post on API testing.          Sharing will enrich everyone with more knowledge.I will actually share couple of posts which help in learning. a. Danny Dainton's GitHub Post on All Things Postman - https://github.com/DannyDainton/All-Things-Postmanb. Recent blogpost by Anne-Marie Charrett - https://mavericktester.com/2018/11/05/rest-apis-written-by-women/This blogpost includes collation of posts written female software craftspeople.Please do check out them, there are plenty of interesting blogposts.Ministry of Testing Discussion Thread:  https://club.ministryoftesting.com/t/30-days-of-api-testing-day-6-interesting-blog-post-on-api-testing/19595/18

    14.11.2018 | 11:23 קרא עוד...
  • 30 Days of API Testing – Mock, Stub, Fake

    Today’s challenge is about explaining mocks, stubs and fakes. I don’t know if I can pull it off. The problem is, different teams will use these words in different ways. I don’t think it makes a lot of sense to argue about what exactly each of them means and how they are distinct from each other, but there is some value in at least understanding the general idea that these terms are meant to communicate. In the broadest terms, when we talk about these things we are talking about something that is a substitute for a piece of production code. For example, we might have a database that stores some values. When running tests though, it might expensive to go retrieve those values many times, so instead we might make a local text file that has a few of the values we care about hard coded into it and just use that instead of the ‘real’ databases. No matter what term we are talking about – mocking, stubbing, faking, etc. – what we are doing is using something that is not the production code to simplify in some way what we are doing for our tests.  This helps us isolate things to just the specific part of the code we are interested in and can be used in some really powerful ways. I wouldn’t worry too much about understanding in an absolute sense what these various terms means. What matters in figuring out what they mean in your context. How[…]

    14.11.2018 | 9:48 קרא עוד...
  • Quality is the Responsibility of the Whole Team

    Originally this article was postet on trendig.com English & Deutsch Since 2001 we have the agile manifesto in place and since then the whole industry is learning to use agile principles and values in their daily work of software development.   agile manifesto One of the problems I see, is that many who claim to be … Continue reading Quality is the Responsibility of the Whole Team

    14.11.2018 | 5:23 קרא עוד...

טיפים

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