Coursera Quiz - KU-SKE17/Software-Process GitHub Wiki

What is a Test?

  1. The setup step for a test case is important to establish a specific state for the program to run the test.

    • True
  2. Tasks that can be part of the tear down phase are (choose two answers):

    • Remove data you added after testing is done
    • Close connection after testing is done
  3. Assessment is the phase where:

    • Software output is checked by an oracle.

Automation: Using a Test Framework

  1. Testing execution frameworks (e.g., JUnit) are important because:

    • They allow automated checks against an oracle (e.g., Do the outputs of the program match expectations?) to determine whether or not a test passes.
    • They run all test cases and provide feedback on which test cases passed and which failed.
    • They allow programmers to unit test each method.
  2. To test a main method you need to:

    • Redirect input to be entered by the test case.
    • Invoke the main method with the right parameters.
    • Redirect output to be generated by the test case.
  3. In a test framework, we write test cases:

    • In a separate class---usually, with one or more test classes per class under test.

Automation: Writing JUnit Tests

  1. Testing is all about corner cases.

    • False
    • While it is important to test corner cases, we must also check that the system functions correctly under normal use. Test cases that check the normal use of the system (called nominal test cases) are very important because they check the code that most users will regularly execute.
  2. The strategy of writing test cases before implementation is:

    • A good idea. Test cases should be built based on the expected output and should not be influenced by the implementation.
  3. When you have a new test case:

    • All test cases need to be run including the new one.
    • You need to run all the test cases even though they might have passed on a previous step because the new test case might cause other test results to change. This occurs, for example, when a test case doesn't correctly clean-up after itself causing structures to be reused across tests. This can be masked in previous test executions, but that could change with the addition of the new test case causing a test to fail. Therefore, all tests need to be rerun when a new test case is added to the test suite.

Dependability

  1. What is the time ordering (in terms of when a mistake is made or occurs in the running system) of the following: (1) an error, (2) a fault, and (3) a failure?

    • fault, error, failure
  2. Testing helps with which kind of dependability criteria?

    • error removal
  3. Availability is the same as reliability.

    • False
  4. A correct system (with respect to its requirements) will be safe.

    • False
  5. A correct system will be reliable.

    • True
  6. Robust systems are reliable.

    • False
    • Correct: the system may not crash (robust), but it still may not do the right thing (reliable)
  7. Safe systems are robust.

    • False

Testing Principles: Where

  1. Why do floating point numbers sometimes lead to erroneous code?

    • Arithmetic on floating point numbers is often approximate, so it can introduce errors
    • Floating point numbers have values that are not actually numbers, such as infinity and NaN (not a number), that can cause computations to behave strangely.
    • As floating point computations are approximate, equality comparisons fail after computations that would succeed when using real numbers
  2. Why do relational boundaries sometimes lead to erroneous code?

    • Programmers often make 'off-by-one' errors
    • Determining strict limits on ranges is difficult in requirements engineering
    • Relational boundaries define points of discontinuity for programs
  3. Why do casts sometimes lead to erroneous code?

    • When converting an integer to a smaller bit length (e.g. long to int), the value may be truncated.
    • When converting from signed to unsigned types (e.g., int to byte), negative numbers can't be represented.
    • When converting from a double to int, the value is truncated to a whole number.
    • ...

Testing Principles: How

  1. Why are we often able to test more rigorously at the unit level rather than the system level?

    • We can usually see more of the internal state at the unit level so we can build stronger oracles.
    • ...
  2. When we say that we want redundant verification, what do we mean?

    • We want several different verification techniques checking the same program or subsystem.
  3. Which of the following are good ways to work with developers to reduce systematic errors?

    • Use languages / IDEs that eliminate certain classes of errors by compile-time checks.
    • Create libraries or utility functions to encapsulate operations that developers tend to get wrong.
    • Create tools to test/verify specific kinds of common errors.
    • Create checklists for developers based on the most common errors seen in test.
  4. We state that programs, as well as tests, can be flakey. What does it mean for a program to be flakey?

    • Given the same inputs, sometimes the program fails a test and other times it does not.
  5. Why is observability an important issue in testing?

    • Often programs are stateful - that is, a test may trigger an error, but it only becomes visible as an output if a long sequence of steps are executed, whereas it might be immediately visible by examining internal state.
    • If a program error is transient (it happens and is masked out by other code), you might not be able to "see" it and the test may pass.

The V-Model

  1. The V-Model is:

    • A software development model that pairs different stages of software development with the appropriate testing procedure. These tests are later used when checking the verification of each phase of the software.
  2. The system design is tested using:

    • Module Testing.
  3. The specification of the system is tested using:

    • Verification Testing.

Validation and Verification in the "V-Model"

  1. The difference between validation and verification is:

    • Validation confirms that we are building the right product while verification confirms that we are building the product right.
    • Validation is planned during the user requirement stage in the V-model while verification is planned during the user specification stage.
  2. With respect to the V-model, a system that has passed verification testing means:

    • The system has passed all tests from unit testing through verification testing and is now ready for validation testing.
  3. With respect to the V-model, a valid system implies a verified system:

    • True

Structural Testing

  1. Structural testing is:

    • White-box testing
  2. What is not true about structural testing?

    • The goal of testing is to achieve 100% structural coverage to ensure the absence of bugs.
    • True: In most cases, it is infeasible to reach 100% structural coverage.
    • True: Structural coverage criteria use the structure of the code to measure the adequacy of tests.

Mutation Testing

  1. Which of the following is not true about mutation testing?

    • With mutation testing, you can know how much of the code structure you covered.
    • True: The mutation adequacy score tells you the quality of tests; the higher the score, the better the quality of test cases.
    • True: A mutant is killed when there exists one or more tests that can differentiate between the output of the mutant and the output of the original program.
  2. Which of the following are not true about mutation testing?

    • You only create one mutant for mutation testing.
    • The mutation operator introduces a syntactic change to the program so that the mutant cannot be compiled.
    • True: A mutant and the original program are syntactically different.
  3. Do when mutant could not find defects

    • write more test cases

What is a Test Plan?

  1. The unit testing plan that is generated is always a formal document.

    • False
  2. The kind of test that determines whether or not you built the correct thing for the customer?

    • Customer Acceptance Test
  3. System validation testing is when the system is tested for error prone constructs and low level functionality assurances.

    • False
  4. Which of the following is NOT an important component of a test plan according to the Quality Assurance Institute?

    • Reliability
    • Important: Schedule
    • Important: Entry and Exit Conditions
    • Important: Scope
    • Important: Resources and Testing Environment
  5. Which of the following traces test cases back to requirements?

    • Traceability Report

Importance of a Good Test Plan

  1. Which of the following is true about a traceability (requirements) matrix.

    • It helps identify test cases that don't tie to requirements.
    • ...
  2. When considering concerns or risks of test planning, it's important to take preventative action when possible.

    • True
  3. It is normal to accept requirements with a 'to-be-determined' in them.

    • False
    • because we do not know how the system is expected to respond.
  4. Testing is the only way to locate bugs in a system.

    • False
  5. There is always pressure on ___ to prove a product is not ready for release (especially in the Waterfall Method).

    • Testers

Stages of Software Testing Process

  1. Unit testing is usually white box testing done by the developer on a small piece of code (a function or class).

    • True
  2. Which of these should NOT be included in unit testing?

    • Module integration testing
    • Should: Testing array bounds
    • Should: Test loop boundaries for off-by-one errors
    • Should: Error prone constructs
  3. Design Verification Testing has two aspects: Integration testing and Functional testing.

    • True
  4. Testing modules to ensure they work together properly occurs at which stage of software testing process?

    • Design Verification Testing
  5. System validation testing occurs once the full system is complete.

    • False
    • You can't do a full system test without a full system.
  6. System validation testing will test the system for quality of behavior delivery on many aspects. Which of the following is not one of those aspects?

    • Loop Invariants
    • Following Aspects: Performance, Security, -ability

Test (Status) Reports

  1. Which of the following is NOT part of the test (status) report.

    • Test case code
    • Following: Open defects
    • Following: What was tested
    • Following: What was not tested
  2. The only test report is the final report and is sent only when all testing is complete.

    • False
  3. Test (status) reports are important because:

    • Allows management to better manage risk.
    • Allows marketing to provide to the customers updates and manage customer expectations.
    • Assists in process improvement through postmortem evaluations.
  4. Testing is ___ but not ___ from development.

    • Independent, Isolated

Risk Based Test Planning

  1. The act of reducing risk is known as:

    • Risk mitigation
  2. The risk equation is:

    • risk = impact * likelihood
  3. The amount of loss management is willing to accept is known as:

    • Risk appetite
  4. In terms of risk impact, depth of impact refers to:

    • Severity of damage
  5. When considering risk, it is important to consider categories of impact. Which of the following is NOT given as an example in the lecture slides.

    • Motivation
    • Following: Reputation
    • Following: Customer/User base
    • Following: Financial
    • Following: Lives
  6. Asking the question: What can you do to control (reduce) the risk? is an example of:

    • Risk mitigation
  7. When risk avoidance fails, the best thing to do is to test features with the highest impact and the features that are most likely to fail.

    • True

Software Defect Reports

  1. Only about half of testing efforts are spent on actual testing.

    • True

Software Defect Reports: Analysis

  1. Part of analysis is figuring out where the fault of the defect lies. The fault could lie with the:

    • Test
    • Tester
    • Product
  2. Reproducibility and repeatability are the same thing when it comes to defects.

    • False
  3. Not all defects are created equal.

    • True

Software Defect Reports: Reporting

  1. The report phase consists of four main steps.

    • Ensure defect is not a duplicate
    • Make sure defect gets fixed
    • Enter defect into the system
    • Talk with developers
  2. What are the characteristics of an effective defect report?

    • Numbered or ID'd
    • Simple
    • Written
    • Complete
    • Understandable
  3. You should always include the minimum number of steps to reproduce the defect in a defect report.

    • True

Software Defect Reports: Report Content

  1. The software defect report content consists of six main components.

    • Identification Information
    • Description of the problem
    • Status Indicator
    • Comments
    • Misc Information
    • Supporting Information
  2. Which of the following components would contain a defect identification number?

    • Identification Information
  3. Which of the following components would contain an overview of the problem along with what you did and the results of that action?

    • Description of the problem
  4. Assume that you are writing a defect report and this particular defect is known to have an impact of medium severity. Which component would contain this information?

    • Status Indicator
  5. Severity and priority are essentially the same in terms of status indication.

    • False
  6. The best defect reports have new and ingenious introductions of terminology and abbreviations.

    • False
  7. Assume that there is a defect that is found to be a problem, but you can essentially ignore it. Which severity level should it have?

    • Low
  8. Lets say you are working on an unmanned aerial vehicle and a defect is found. This defect happens only occasionally, but if it does the vehicle would come crashing out of the sky onto an unsuspecting population killing many. What severity level should this defect be given?

    • High
  9. Assume that a particular low-severity defect is such that by fixing it, it will cause many more problems to come up. What final state should this defect be given?

    • Do not fix
  10. If there is a relatively easy workaround to a problem, STATE IT in the defect report.

    • True

Software Defect Reports: Track, Retest, and Close

  1. When it comes to tracking defects, the most important aspect is to have a process and follow it.

    • True
  2. Which of the following is not a conclusion reached by the retesting phase?

    • Problem is insurmountable
  3. Testing and verification notes belong to which of the following categories?

    • Close

Test Doubles: Introduction

  1. If a system under test needs to interact with other systems in order to complete a unit test, just skip the testing.

    • False
  2. What do you call lightweight versions of components that a system under test interacts with that are necessary to do unit testing?

    • Test Doubles
  3. What do you call the dummy values that are filled into objects that are required as parameters by the system under test, but are otherwise irrelevant?

    • Dummy Objects
  4. What are the dummy input data sources used by a system under test?

    • Test Stubs
  5. What would you use in order to check the indirect results produced by a system under test?

    • Mock Objects
  6. There is essentially no difference between spy objects and mock objects.

    • False
  7. The goal of Mockito is to:

    • Create test doubles and inspect interactions

Test Doubles: Input

  1. When providing test inputs for test doubles, we want to use ___ and ___.

    • Dummy objects, Test stubs
  2. During constructing test doubles, you wish to provide outputs for just a handful of values. What do you use?

    • Test Stubs
  3. During testing, you find that the unit tests require the use of a computationally expensive database. What could you use as a test double?

    • Fake Objects
  4. In Mockito, there is a distiction between the roles that a class plays and how you construct it. The roles of a test double are stub, mock, and dummy (or all three). How you construct them in Mockito is the same.

    • True

Test Doubles: Output

  1. ___ provide the ecosystem.

    • Test doubles
  2. Mocks and spies will allow fine grain monitoring of the system under test.

    • True
  3. Which of the following are not a part of testing interactions using mock objects and spy objects?

    • Required fill-in values are being created for the system under test
  4. ___ objects allow us to observe interactions of fake objects. ___ objects allow us to observe interactions of real objects.

    • Mock, Spy
  5. In Mockito, there is no capability to override the behavior of methods with a spy object.

    • False
  6. In Mockito, it is possible to create an object that is both a stub and a mock.

    • True

Introduction to User Stories and Behavior-Driven Development

  1. Why are User Stories important in software testing?

    • They provide a way of developing software requirements by viewing the system from a user's perspective.
  2. User Stories are mainly expressed using the rule

    • As a < role >, I want < feature > so that < reason >
  3. Why are roles used in User Stories?

    • To identify all the different kinds of users in the end product.
  4. Why are reasons useful in User Stories? (Check all that apply)

    • To prioritize features.
    • To improve testing by providing context.
    • To detect overlapping functionality between features.
    • Not: To justify the importance of testing a specific feature.
    • Not: To convince the leading engineer regarding the implementation of a feature.
  5. Epics are different from detailed User Stories because...

    • they involve a story that applies to a broad range of users.
  6. The Gherkin language is an effective way to...

    • express a User Story in such a way that it can be used to generate tests.
  7. Behavior-driven development puts the user at the center of the testing cycle.

    • True
⚠️ **GitHub.com Fallback** ⚠️