General Test Overview Flashcards

1
Q

Why do we engineer software?

A

To solve customer’s problem.
To produce quality product within budget and scheudle.
To show the product (software) is indeed high quality.

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

What is a problem?

A

A difference between things as desired and things as perceived.

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

Stakeholders

A

Those who have a stake in the change being considered and who stand to gain or lose from the change.

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

Testing Original Purpose:

A

Demonstration of proper behavior or quality demonstration.

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

Testing New Purpose:

A

Defect Detection and Reduction.
Archieve defect-free software.

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

Oracle

A

The expected behavior of an operation.

The actual output should be compared with the “Oracle”

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

Ad-Hoc Testing

A

“Run and Observe”
One way to structure is to build a checklist

A type of informal testing that is performed without any formal test plan or test cause creation.

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

Ad-Hoc Drawbacks

A

Lack of structure
Likely to miss and repeat oneself.
Whole Process is hard to repeat.

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

Systematic Testing

A

Process is explicitly defined.
Testing with checklists.

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

Reliability

A

Probablity of failure-free operation for a specific period or a given set of input under a specific environment.

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

Creativity

A

Ability to produce work that is both Novel and Appropriate.

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

How to measure creativity in RE?

A

Rate the requirements at a 5 point Likert Scale.
Kappa Statistic : Show the level of agreement among participants.

In recent Years, we rate Clarity, Novelty and Usefulness.

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

Requirement Based Testing

A

Address 2 Major Issues:
1. Check/Validate the requirements for Correctness, Completeness, Ambiguity, and Logical Consistency.

  1. Designing a set of test cases for requirements from a black box perspective.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Quality Assurance:

A

To ensure that few , if any, defects remain in the software when it is delivered to its customers or released to the market.

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

Error

A

A mistake made by a programmer or software engineer which caused the fault, which in turn may cause a failure.

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

Fault

A

Condition/ Internal characteristic that may cause a failure in the system.

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

Failure

A

Inability of the system to perform a function according to its specification due to some fault.

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

Defect Relationship

A

Errors causes Faults.
Faults causes Failures.

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

TDD

A

A software development process where a unit’s test are written before the unit’s implemention and guide the unit’s development as the tests are executed repeatedly until they all succeed, signaling complete functionality.

20
Q

TDD Process Steps

A

Red:
Write a new test for a section.
Verify failure of the new test and the success of existing tests.

Green:
Write code to implement, modify or develop the unit.
Repeat until the tests pass.

Refactor:
Refactor the code to improve non-functional code structure, style, and quality.
Confirm tests pass.

Repeat.

21
Q

Unit

A

The smallest executable or testable component of a system.

22
Q

Unit Testing vs TDD

A
23
Q

Input Domain

A

Space of all allowable test points

24
Q

Input SubDomain

A

Subset of input domain defined with a concrete relationship

25
Q

Domain Partition

A

Partition the input domain into a series of subdomains.

26
Q

Specification

A

Defines each dimension separately

27
Q

Boundary

A

Where 2 subdomains meet.

28
Q

Different Types of Points

A

Boundary Point: Point on Boundary
Interior Point: Point on subdomain but not on boundary
Exterior Point: Point not in the subdomain nor boundary.
Vertex Point: Point where 2 or more boundaries meet.

29
Q

Boundary Types

A

Closed - All boundary points belong to the subdomain.
Open - None of the boundary points belong to the subdomain

30
Q

Problems in Partitioning

A

Ambiguity: Under-defined/incomplete
Contradictions: Over-defined/Overlap
Key: Sub-Domians form a partition.

31
Q

Types of boundary Problems

A

Closure Problem
Boundary Shift
Missing Boundary
Extra Boundary

32
Q

EPC

A

Extreme points test the limits of the system.
# Test Case = 4^n + 1

Good for Closure and Missing Boundary Problems.

33
Q

Weak Nx1

A

Pick the OFF point so close to the boundary that any small amount of boundary change would change the processing mode of the test points/cases defined.

34
Q

ON Point

A

ON the boundary

35
Q

OFF Point

A

OFF the boundary

Should be on the side of the boundary that will receive different processing than the boundary points.

Should be x away from boundary

36
Q

Weak Nx1 Test Cases Function

A

Total Points = (n + 1) x b + 1

n = boundary points
b = boundaries

37
Q

Strong Nx1

A

1 set of tests for each segment

38
Q

Test management Function

A

T = H / (t + f * r)

T = # of tests
H = Total Hours for testing
t = Time each test takes
f = % of faulty tests
r = Time to remove a fault

39
Q

Black Box Testing

A

Functional Testing
Tests external functions

40
Q

White box Testing

A

Structural Testing
Tests interanl implementation.

41
Q

Function (in Math)

A

A relationship from a domain X to a codomain Y such that for every element x in X.

Every input has only one output.

42
Q

Checklist

A

A list of item that need to be covered in a test.
Ensure that all the important areas of the applications are covered.
Could include structural or functional aspects.

43
Q

A partition is a “mutally exclusive and exhaustive” set of inputs? What does this mean?

A

Mutally exclusive: No two partition have any elements in common.
Exhaustive: The union of all partitions is the entire input space.

44
Q

Why is creativity important in SE?

A

Its more critical in modern software industry.
- Competition in the industry.
- Multiple system in the same application domain.

45
Q

Requirements Engineering

A

Discovering stakeholder’s needs and desires.
Communicating these to system implementers.

46
Q

RBT Approach Steps

A
  1. Validate requirement
  2. Define test completion criteria
  3. Design test cases (define logical test cases)
  4. Execute Tests
  5. Verify test results.
  6. Verify test coverage.
  7. Manage and track defects/improvements.
  8. Manage the test library.