Study your flashcards anywhere!

Download the official Cram app for free >

  • Shuffle
    Toggle On
    Toggle Off
  • Alphabetize
    Toggle On
    Toggle Off
  • Front First
    Toggle On
    Toggle Off
  • Both Sides
    Toggle On
    Toggle Off
  • Read
    Toggle On
    Toggle Off

How to study your flashcards.

Right/Left arrow keys: Navigate between flashcards.right arrow keyleft arrow key

Up/Down arrow keys: Flip the card between the front and back.down keyup key

H key: Show hint (3rd side).h key

A key: Read text to speech.a key


Play button


Play button




Click to flip

69 Cards in this Set

  • Front
  • Back

A human action that produces an incorrect result.


Flaw in a component or system that can cause it to fail to perform it's required function.


Deviation of the component or system from it's expected delivery or result.


Cause as many failures as possible in order to allow them to be fixed.

Development testing

Confirm the system works as expected and to gain confidence that it has met requirements.

Acceptance testing

Ensure no new defects are introduced after a change.

Maintenance testing

What is the correct order for the testing process?

i. Designing Tests

ii. Test Control

iii. Reviewing Documents

iv. Planning

iv. Planning

ii. Test Control

i. Designing Tests

iii. Reviewing Documents

Development activity that finds, analyzes, and removes the cause of a failure.


An ongoing process to ensure test plans are being executed.

Test control

The process of outlining the objective and goals of testing, and determining the proper test and resources.

Test planning

- Objectives are translated into test cases & conditions

- Review test basis, evaluate testability

- Identify and prioritize high level test cases

- Identify test environment

- Identify test tools

- Create bi-directional traceability

Test analysis and design

- Finalize and prioritize test cases

- Develop and prioritize test procedures

- Verify test environment and traceability

- Execute test procedures

- Log outcomes

- Document and report discrepancies

- Repeat test cases

Test implementation and execution

- Evaluate test logs vs given exit criteria

- Assess if more testing is necessary

- Write a summary report for stakeholders

Evaluating exit criteria and test reporting

- Check deliverables

- Close bug reports

- Document acceptance of system

- Finalize + archive testware

- Post mortems

Test closure

What does the client want/need?

User requirement identification

What are the system requirements to run the software?

System requirement identification

Overall design decisions, little detail

High level design

Elaboration on the base design

Detailed design

Project begins to take shape, content is implemented

Coding and implementation

Follows a process of establishing requirements, designing, building, and testing a system in a series of short development cycles.

Iterative-incremental development model

"Are we building the product right?"

Checking the application after each phase of development to be sure it meets the requirements for that phase.


"Are we building the right product?"

Checking the application at the end of the development process to verify it satisfies specified requirements.


Ensure each piece works on it's own.

Requires access to code.

Component testing

Tests the interaction between different systems or parts of the system.

Integration testing

Concerned with the behavior of the entire system or product.

System testing

Establishes confidence in the system.

Ideally done by users.

Acceptance testing

The piece of code that activates the section you are testing.


The piece that accepts the information from the driver.


Testing interactions between different software components.

Done after component testing.

Component integration testing

Tests interaction between different systems of software and hardware.

May be done after system testing.

System integration testing

All, or most, developed modules are put together to form a complete system and then are used for testing how well everything integrates.

Big bang integration testing

Performed systematically starting from top level modules and working down, testing modules one at a time.

Top-down integration testing

Performed systematically starting from bottom level modules and working up, testing modules one at a time.

Bottom-up integration testing

Testing that revolves around what a system does and what it should do.

Ex: Black box, security, interoperability

Functional testing

Testing that revolves around how a program performs.

Ex: Performance, load, stress, efficiency, usability, maintainability, portability.

Non-functional testing

Testing the internal structure of a system (done through inspecting code).

Ex: Coverage, white box.

Structure based testing

Testing revolving around changes made to a system to verify that they still work.

Ex: Regression, confirmation

Change testing

The process of testing previously released software that has undergone some changes.

Maintenance testing

Testing to see the ease of upkeep on software.

Maintainability testing

Determining how existing systems are affected by changes, used to plan regression.

Impact analysis

Testing the internal structure of a program before it is executed.

The focus of this is to identify issues in the code.

Static testing

Testing which involves the execution of the software of a component or system.

Dynamic testing

- No formal process

- Results may be documented

- Inexpensive way to benefit from gathered info

Informal review

A walkthrough, technical review, or inspection.

Formal review

A step-by-step presentation by the author.


Discussing, making decisions, evaluating alternatives, finding defects, solving technical problems, and checking conformance to specifications, plans, regulations, and standards.

During this: Defects are documented, management participation is not required, and is generally led by a moderator.

Technical review

- Led by a moderator

- Roles are defined for participants

- Metrics are gathered

- Uses entry and exit criteria for acceptance of software work product

- Formal follow up


- Plans review

- Mediates discussion

- Runs meeting

- Provides follow up


- Individual whose code or documentation is being reviewed

- Responsible for learning during review

- Clarifies and answers questions


- Records data

- Generally should be a non-participant


- Decides when a review is necessary

- Responsible for scheduling

- Determines if the objectives of a review were met


- Reviews code or material

- Gives feedback

- Aids improvement on reviewed subject


? -> Kick off -> Preparation -> Review meeting -> Rework -> Follow up


Plan -> ? -> Preparation -> Review meeting -> Rework -> Follow up

Kick off

Plan -> Kick off -> ? -> Review meeting -> Rework -> Follow up


Plan -> Kick off -> Preparation -> ? -> Rework -> Follow up

Review meeting

Plan -> Kick off -> Preparation -> Review meeting -> ? -> Follow up


Plan -> Kick off -> Preparation -> Review meeting -> Rework -> ?

Follow up

- Define review criteria

- Select personnel

- Allocate roles

- Define entry/exit criteria (if applicable)

- Select what aspects are being reviewed


- Distribute documentation to participants

- Explain objectives

- Answer initial questions

Kick off

- Review documents/code

- Record defects, questions, feedback

- Author waits


- Discuss results

- Reommendations and defects are noted

- Scribe takes notes

- Author listens and learns

Review meeting

- Author works on issues brought up


- Check that defects were addressed

- Gather metrics

- Check exit criteria

Follow up

Analysis of software artifacts (code/requirements) carried out without execution of the software.

Static analysis

Compilers, link checkers, HTML syntax checkers, conformance checkers, security auditors, complexity analyzers.

Static analysis tools

Order which statements, instructors, or function calls are executed.

Control flow

Path in which data travels in a program.

Data flow

Level of difficulty in understanding or maintaining the internal structure or component of a program.