Testing Flashcards

1
Q

What is the famous saying regarding testing for errors

A

Testing can only show the presence of errors, not their absence

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
1
Q

What are the 2 things you are trying to do when testing software

A
  1. Making sure all requirements are met
  2. Squash bugs
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What is the famous wording for the difference between validation and verification

A

Validation: Are we building the right product?
Verification: Are we building the product right?

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

What is V&V concerned with

A

Checking that the software is meeting specs/reqs and that the functionality works as expected

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

What is verification (as opposed to validation)

A

Checking that the software meets functional and non-functional requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

What is validation (as opposed to verification)

A

Checking that the software meets the user’s and stakeholder’s expectations, which are not necessarily part of any requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

What is the goal of V&V

A

Establish confidence that the software system is “fit for purpose”

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

What does it mean when a system is “fit for purpose”

A

The system must be good enough for its intended use

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

What are the 3 things that determine how much confidence a system needs to have (when is it “good enough”)

A
  1. Software Purpose (Criticalness)
  2. User Expectations (Previous Experience + Company Maturity)
  3. Marketing Environment (Other Competition)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

What should also be done for V&V besides testing, and what are the 3 advantages of doing it

A

Inspections/Reviews:
1. Errors are discovered that testing would have otherwise been hiding due to the lack of knowing if it came from a known error or a new one
2. You can discover errors before the system can even be ready to test, reducing development costs
3. You can discover a lack of quality in the code that testing cannot identify, such as compliance, portability, and maintainability

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

What are the 3 things inspections NOT good for that testing could detect

A
  1. Unexpected interactions between different parts of the system
  2. Timing problems (race conditions)
  3. System performance
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

What is important to understand when it comes to making test cases

A

Test cases are impossible to automatically generate. You must be INVOLVED in understanding what the system is supposed to do in order to create test cases and the expected test results.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

What are the 3 major stages of testing for a software’s lifespan

A
  1. Development Testing (during development)
  2. Release Testing (finalizing)
  3. User Testing (post-prod in non-dev environments)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

What is particularly impossible to automatically test

A

GUIs and unanticpated side effects

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

What are the 3 stages of Development Testing

A
  1. Unit Testing (objects/methods)
  2. Component Testing (composite interfaces)
  3. System Testing (whole, component interactions)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

What are the 3 parts of an automated test

A
  1. Setup (initialize, inputs + outputs)
  2. Call (the object)
  3. Assertion (compare result)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

What can be used that would skip bottlenecks in automated tests, such as database requests

A

Mock objects

17
Q

What is unit test case “Effectiveness”

A

Making test cases that either show that the component is doing what it is supposed to do and that defects are revealed

18
Q

What are 2 effective types of strategies for developing test cases

A
  1. Partition Testing
  2. Guideline-based Testing
19
Q

What is Partition Testing

A

Identify and define all possible (separate) sets of inputs for a unit test as classes, and group them from their (supposedly correct) behavior (output) as classes (behavior of separate input classes can interleave), with these classes being called “equivalence partitions/domains”, and for all classes of input and output partitions, if the partitions are ranges, test the boundaries of them (along with the middle), or otherwise test the full sets. Also identify all possible INVALID input and output equivalence partitions and test that the system is correctly handling those errors.

20
Q

What is Guideline-based Testing

A

Use previous knowledge of common developer errors to include in all tests

21
Q

When is it appropriate to start performing Component Testing

A

Once all of the unit testing has been completed

22
Q

What are the 4 types of interfaces between components

A
  1. Parameter Interfaces (direct data flow)
  2. Shared Memory Interfaces (external)
  3. Procedural Interfaces (call the methods from other)
  4. Message-Passing Interfaces (pls)
23
Q

What are the 3 most common forms of interface errors

A
  1. Interface Misuse (type)
  2. Interface Misunderstanding (ordering, etc)
  3. Timing Errors (race cond.)
24
Q

What is sometimes better to do for detecting interface errors

A

Inspections/reviews

25
Q

What are the 2 important differences of System Testing that separates it from Component Testing

A
  1. You can be testing old components (or purchased off-the-shelf components) that have been previously developed and is now being integrated to the whole system
  2. The teams that developed components separately join together to test the integration, or a new team (not involved in the development of all the components at all) is used
26
Q

What must be done to achieve Exhaustive Testing

A

It is impossible

27
Q

What are the 5 steps of TDD

A
  1. Identify the next increment
  2. Write an automated test
  3. Run the test(s) to make sure the test is working
  4. Implement the increment and re-run the test. Repeat this until the test passes.
  5. Go back to step 1
28
Q

What are the 4 benefits of TDD

A
  1. Code Coverage
  2. Regression Testing
  3. Simplified Debugging
  4. System Documentation
29
Q

What type of system makes TDD ineffective

A

Multi-threaded systems

30
Q

What are the 2 things that make Release Testing different than System Testing

A
  1. It should not be done by the developers
  2. It focuses on meeting requirements, not squashing bugs
31
Q

What is Release Testing also known as

A

Functional Testing (concerned with functionality, NOT implementation)

32
Q

Regarding this topic, what should be considered when performing Requirements Engineering

A

Making sure each requirement is testable

33
Q

What are you NOT doing for Requirements-Based Testing

A

Defect Testing (you are instead validating that requirements are implemented)

34
Q

What is Scenario Testing

A

You write tests based on narratives and scenarios, in which each covers multiple requirements

35
Q

What are the 2 goals of Stress Testing

A
  1. Checking that system failure due to overload causes it to “fail-soft” (not resulting in data corruption or unexpected loss of services)
  2. Reveal the defects that only appear under overload
36
Q

What type of systems are important to Stress Test and why

A

Distributed systems that are based on a network of processors. This is because there is a point in which degredation occurs where processors wait on other processors, and this Stress Testing can identify when that happens to implement when transactions should be rejected to end this spiral before it begins.

37
Q

Why is User Testing essential

A

Because the developer’s environment is artificial and will never replicate the actual working environment

38
Q

What are the 3 types of User Testing

A
  1. Alpha Testing (internal users)
  2. Beta Testing (closed and/or experimental release)
  3. Acceptance Testing (custom systems)
39
Q

What are the 6 stages of Acceptance Testing

A
  1. Define Acceptance Criteria (before contract signed)
  2. Plan (budget and schedule)
  3. Derive/Build Tests
  4. Run/Execute (ideally in environment, with user training)
  5. Negotiate (good enough?)
  6. Reject/Accept (repeat if rejected)
40
Q

What typically happens even if Acceptance Testing fails

A

The system is used anyways because the customer already set up the environment to use it and would cost more to wait and pay for more development than to just work around the issues. In Agile development, usually this is the end of Acceptance Testing (move to alpha user stories).