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

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

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

he icon   en icon

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

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

נושא Sample question on LO 1.1.2

Sample question on LO 1.1.2 15 מאי 2015 15:20 #3360

  • Michael Stahl
  • Michael Stahl's Avatar
  • מנותקים
  • Fresh Boarder
  • פוסטים: 3
  • קארמה: 0
LO-1.1.2: Distinguish between the root cause of a defect and its effects (K2)


A program calculates exchange rates between Shekels and other currencies. The program gets every morning a file with a list of currencies and their current exchange rates. The file is created by another system and received over the network. The file overwrites the file that the program received the day before. The program knows the conversion rates by reading this file.
One morning, the received file was empty. As a result, when the system was used to convert Shekels to Dollars, the system crashed.

Which of the following could be a description of the root cause of this defect?

A. The program fails to check if the file is empty before using it
B. An attempt to convert Shekels to any currency crashes the program
C. The program crashes in case the conversion file is missing or empty
D. Overwriting the previous file with a new file



The correct answer is A.

Reason: "Root cause" is defined in the Glossary as: "A source of a defect such that if it is removed, the occurrence of the defect type is decreased or removed". If the program would check for empty file and report an error instead of trying to use this empty file, the crash would have been avoided. Moreover, if the error message was clear enough, it would also be very easy to fix the problem.

B is incorrect - it just describes the effect of the bug.

C is incorrect - it too describes the effect of the bug.

D is incorrect since it describes the behavior of the system on any day - not just days when the file was empty.
עריכה אחרונה: 15 מאי 2015 15:23 ע"י Michael Stahl.
יש להרשם בכדי לכתוב בפורום.

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

  • X Things I’ve Learned about Contract Testing with Pact

    A couple of weeks ago, while at TestBash Manchester, I attended the “Contract Testing in Practice with Pact” workshop led by Pierre Vincent. I had some knowledge of the topic but the workshop helped me get some concepts straight, that either I was not familiar with or I had all wrong. Here are some of the things I’ve learned. Hopefully I got them right. Purpose The aim of contract tests should be to check if there are any changes in the structure of an API (renamed fields, change of type of data, etc.) and not its business logic. As an API consumer You provide the contract, stating your expectations of what a call to an API should return. Contract tests serve as unit tests of the structure of your request. Contract tests should respect the tolerant reader pattern. As the post says, you should “only take the elements you need, ignore anything you don’t.” Running the contract tests you created doesn’t inform you of any changes from the provider’s side. If you are consuming external APIs contract testing won’t really work for you. Unless you have a way of ensuring that the external providers will execute the contracts you supply them with. As an API provider Running contract tests lets you know if you still respect the way your consumers use your API. In case a contract test fails, you should either fix it or start discussions with the consumers about mutually changing the contract. As a provider of an external service[…]

    15.10.2019 | 7:37 קרא עוד...
  • Meme of the Day: Bug Reports

    The post Meme of the Day: Bug Reports appeared first on The Life Of One Man.

    15.10.2019 | 4:32 קרא עוד...
  • Five Blogs – 15 October 2019

    The (best) five blogs I read today. Check them out. How to Apply Shift-Left Testing in Continuous Testing? Written by: Katalon Studio Team Lessons Learned about Cloud Written by: Srinivas Kadiyala Working with People Who Aren’t Self-Aware Written by: Tasha Eurich Things You Should Know About IoT Testing Written by: TestingWhiz How to Move from Stupid to Smart when You’re Stressed Written by: Dan Rockwell Quote of the day: “There are certain things, no matter what, you have to keep inside.” -Haruki Murakami You can follow this page on Twitter

    15.10.2019 | 12:33 קרא עוד...

טיפים

  • בודק - השאר ממוקד מטרה
    בודק - השאר ממוקד מטרה בודק - "השאר ממוקד מטרה / Keep Your Eye on the Ball - The End Goal " – כבודקים בעלי יכולת מיקוד וירידה לפרטים, לעיתים אנו מאבדים את התמונה הכוללת וצוללים יתר על המידה בבדיקת נושאים…
    קרא עוד...
  • בדוק מוקדם ככול הניתן
    בדוק מוקדם ככול הניתן "בדוק מוקדם ככול הניתן" – אחת המטרות של הבדיקות הינה לספק כמה שיותר משוב ומידע לגבי איכות המערכת מנקודות מבט שונות (פונקציונליות ולא פונקציונליות כמו עמידה בעומסים ושאר יכולות). לעיתים בודקים נוטים בטעות לחשוב כי הדרך…
    קרא עוד...
לרשימה המלאה >>