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

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

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

he icon   en icon

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

תכונות הטסט: בידול

נכתב על ידי 
חמישי, 07 אוגוסט 2014 11:57
דרגו כתבה זו
(1 הצבעה)

בידול לא בא לבד. הוא דורש קבוצה של טסטים.

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

ה- Waterfall. לפני שנים רבות, כשלא הכרתי תהליך אחר, הייתי כותב מסמכי SDD. אלו מסמכי detailed design משוקצים שכתבנו לקומפוננטות ולפיצ'רים. כמובן שאף אחד לא אהב אותם, המינוח הפורמלי, האורך, ואפילו הריח. אבל היה להם יתרון: כדי לכתוב אותם, צריך לחשוב על הבעיה קודם (כמו TDD). כשקראנו את המסמכים, הם היוו נקודת פתיחה לשאלות "מה יקרה אם..." – מה יקרה אם הקשר יתנתק? מה אם הקומפוננט לא מאותחל בזמן?

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

ובחזרה לעתיד.

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

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

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

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

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

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

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

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

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

בפעם הבאה: תחזוקה.

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

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

  • Humidifier For Home Heater

    Humidifier For Home Heater humidifier for home heater humidifier for sq ft. . . . . . . . . . . . . . .

    25.05.2019 | 11:08 קרא עוד...
  • ATA Meetup #22 - Bangalore - Amazing experience

    ATA Meetup #22 - Bangalore - Amazing experience Reached super earlyThe session was supposed to start at 9 AM and I reached by 7.45 AM. I did not want to be late. Due to weekend's minimalistic traffic and super driver, I surprised myself and I thought I can just enter and wait in the hall. The security asked me the contact person name and I told him that there is a meetup by Agile Testing Alliance - did not help. I called up Aditya Garg and somehow the security got convinced that I can at least pass the main barricade and sit on the makeshift park seats.It was nice to experience fresh air, have fruits and dive into an interesting book called "The Practicing Mind" by Thomas M. Sterner. The Practicing Mind I remembered the discussions with Shrini Kulkarni about consciousness, mind, awareness as I read the book. Around 8.40 AM, Thrivikram and Venkata P from HCL welcomed and escorted me to the induction hall where we had the meetup. The conversation between them and the security folks was an interesting one making me think of the process adherence vs value addition. Learning for me: Know the contact person in advance and keep them informed about surprises in plan. HCL ServicesThe first session was by HCL management represented by Prashantha M who highlighted the various services offered by HCL, the case studies and the learning. There were few really good questions by the audience who wanted to know more details about the insights shared to them.My tip: Knowing[…]

    25.05.2019 | 11:55 קרא עוד...
  • Performance testing (benchmarking) Java code with JMH

    Performance testing (benchmarking) Java code with JMH Contents:1) Introduction2) Is it easy?3) Common pitfalls4) Setup5) How to configure JMH?6) Configuration options7) Configuration - predefining state8) Demo9) Results10) Further reading1. IntroductionAs test engineers when we approach performance testing we usually only think about final end-to-end application verification with tools such as JMeter, Locust or Gatling. We know that such tests should run on a separate environment with conditions resembling production as close as possible. Unfortunately in some cases (especially with monolithic architecture) dedicated performance testing environment is hard to get. What to do in such cases? Should we test on common test environment? Or should we test on production? Or maybe we should change our approach to performance testing?  Each option has advantages and disadvantages.Today I'd like to describe low-level performance testing (often called benchmarking) of Java code. It does not require a separate environment. It can be executed directly from your IDE (although that's not recommended) or from the command line. Measuring the performance of critical pieces of code is essential for everyone who creates applications, frameworks, and tools. Testers are co-creators so it's also our responsibility. 2) Is it easy?Benchmarking correctly is hard. There are multiple optimizations implemented on the JVM/OS/hardware side which make it challenging. In order to measure right, you need to understand how to avoid those optimizations because they may not happen in the real production system. Thankfully, there is a tool which helps you mitigate those issues called JMH (Java Microbenchmark Harness). It was created for building, running, and analyzing nano/micro/milli/macro benchmarks written in Java[…]

    25.05.2019 | 8:10 קרא עוד...

טיפים

  • טיפים לאוטומציה יעילה - Dale Emery
    טיפים לאוטומציה יעילה - Dale Emery (How to Survive the Coming Test Automation Zombie Apocalypse (PDF slide deck By Dale Emery bit.ly/15XFGkp סט שקופיות מעולה המתאר את מרבית המחלות התוקפות פעילויות אוטומציה - ומדגיש כיצד לטפל בהן! על כל שקופית ניתן לפתוח…
    קרא עוד...
  • אל תחכה שיתנו לך הזדמנות
    אל תחכה שיתנו לך הזדמנות אם אתה רוצה להתפתח - אל תחכה שיתנו לך הזדמנות, קח אותה - למד, בצע והדגם הדבר בזמנך הפנוי - מישהו כבר יאמץ את זה וייתן לך את הקרדיט.   טיפים מחברי ITCB-AB
    קרא עוד...
לרשימה המלאה >>