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
Reading...
Front

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

image

Play button

image

Play button

image

Progress

1/67

Click to flip

67 Cards in this Set

  • Front
  • Back

Test Control

Corrective procedures to get a test project back on track when we deviate from the test plan

Test Analysis

Identify what to test, what test conditions needed. Each condition should be verified using 1 or more test cases

Test Design

Determine how we will test what we decided during test analysis. Transforming test objectives and conditions from the plan into tangible test cases.

Test case

Set of inputs , execution, and preconditions with an expected result in order to test against to verify specific requirements.

Test implementation

Carrying out activities to prepare for execution such as developing procedures, test data, and test environments.

Test execution

Run the test against the test object (also referred to as system under test)

Checking Results

-Part of execution


See the actual results of the test case, consequences and outcomes.

Evaluating Exit Criteria

A set of conditions that would allow some part of a process to complete. Usually defined during test planning. Help us report our results.

Test Results Reporting

To report our progress


Includes details related to the process, status of the test, and the quality of the system under test.

Test Closure

Collecting test process data related to the various completed test activities in order to consolidate our experience, re use able test ware, important facts, and relevant metrics.

Test Objective

Reason or purpose for designing and executing a test

Confirmation Testing (re test)

Testing that runs test cases that failed the last time they were run.

Debugging

Testing != Debugging. Debugging fixes the defects found in testing.

Test Strategy

A High Level description of the test levels to be performed and the testing within those levels.

Fundamental Test Process (5 parts)

-Planning and Control


-Analysis and Design


-Implementation and Execution


-Evaluating exit criteria and reporting


-Test Closure Activities

Test Approach

The implementation of the test strategy for the specific project. I.G choosing the way you will approach the test by following the test process.

Test Plan

A document that describes the scope, approach, resources and schedule of intended test activities.

It will identify features to be tested, testing tasks, who will be testing what, degree of tester independence, test environment, design techniques, and entry and exit criteria used.

TLDR: Everything about the test to be executed.


"A road map"

Test Monitoring

Test management task that checks the status of each test project.

Test Condition

Item or event of a component or system that can be verified by 1 or more test cases.




Ex. Test Case = Shadow Bolt should hit the boss normaly

Conditions:
1) Range from player to boss = 30 yards
2)Projectile leaves player and travels boss
3) Shadow damage is dealt in the correct parameters

Test Basis

All documents from which the requirements can be inferred. The documentation on which the test cases are based.




Includes documentation, interface requirements, risk analysis reports

Test Data

Data that exists before the test is executed and that affects or is affected by the component or system under test.



Test Procedure Specification

Document specifying a sequence of actions for the execution of a test.

Test Suite

Set of several test cases for system test or component. where the post condition of one test is often used a the precondition for the next one.

if then;

Testware

Artifacts produced during the test process required to carry out the test.

Regression Test

Testing for defects that were not previously present in (usually) already tested components or systems.

Exit Criteria

The set of generic and specific conditions for permitting a process to be officially completed.

Test Log

Chronological record of relevant details about the execution of tests

Test Summary report

Document summarizing testing activities and results.
Should also contain an eval of the corresponding test items against exit criteria.

Dynamic vs Static Testing

Dynamic: actually executing the software and checking for responses ect.

Static: automated analysis of code or review of code.

Error guessing

Designing tests based on previous experience with similar situations and expectations

Indepence

the level (low to high, low being not so good) of the efficacy and willingness to spot flaws

Test Policy

a high level document describing the principles, approach and major objectives of the organization regarding testing.




Verification Testing

Confirmation by examining through provision of objective evidence that specified requirements have been fulfilled.

Validation Testing

Confirmation by examining and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled.

Waterfall Model

NEVER USE. Test at the end, can lead to huge problems and very inefficient.

V-Model

Framework to describe the software development life cycle actives from reqs spec to maintenance. Illustrates how testing can be integrated into each phase of development.

Test Levels (V-Model)

A group of test activities that are organized and managed together. It is linked to the responsibilities in a project.




1 Component Testing


2 Integration testing


3 System Testing


4 Acceptance Testing

V-Model: Component Testing

Search for defects in and verifies the functioning of software components that separately testable.

V-Model: Integration Testing

Tests interfaces between components, interactions to different parts of a system like the OS or file system

V-Model: System Testing

Concerned with the behavior of the whole system/product. Verifies against specific requirements.

V-Model: Acceptance Testing

Validation testing with respect to user needs, requirements and business process conducted to determine whether or not accept the system (final?).

Incremental development models

A development life cycle where a projects in broken into a series of increments, each of which delivers a portion of the functionality in the over all projectile reqs. Each sub projects follows a mini-v-model.




Examples: Prototyping, RAD, RUP, and Agile.

Iterative development models

Development life cycle where a project is broken into a large number of iterations. An iteration is a complete development loop resulting in a executable project, a subset of the final project that grows with each iteration.

Rapid Application Development
(RAD)

A model where components / functions are dev in parallel as if there were mini projects, that are time boxed, delivered, and then assembled into a working prototype.




Pros: Rapid change and development is possible

Agile

A group of software development methodologies based on iterative incremental development.

Component Testing: Stub

A skeletal or special-purpose implementation of a software component, used to develop or test a component that calls or is otherwise dependent on it. It replaced a called component.




Called from the software component

Component Testing: Driver (test driver)

A software component or test tool that replaces a component that takes care of the control and or the calling of a component or system.




Calls the software component

System Testing: Functional Requirement

Req that specifies a function that a component or system must perform.

System Testing: Non-Functional Requirment

Req that does not relate to functionality, but to attributes such as reliability, efficiency etc.

System Testing: Test Environment (Test Bed)

Required. An environment containing hardware, instrumentation, sims, software tools, and other support elements needed to conduct a test.

Acceptance Testing: Alpha Testing

Simulated or actual; operational testing by potential users or an independent test team, but outside the development org. A form of internal acceptance testing.




The first stage

Acceptance Testing: Beta Testing (Field Test)

Operational testing by potential and or existing users at an external site not otherwise involved with the developers, to determine whether or not a component or system satisfies user needs.

External acceptance testing.

2nd stage(final).

Test Type

Group of test activities aimed at a testing component or system focused on a specific testing objective. A means of clearly defining the objective of the test level.

Functional Testing

Considers the specified behavior and is based on the analysis of the functionality of a component.

Black Box Testing

Testing, both functional and non functional, without reference ti the internal structure of the component.

Structural Testing

"White Box" , wanting to see what happens inside.

Static testing defects find able:

deviation from standards, missing requirements, design defects, bad code etc.




Static testing finds defects not failures - dynamic does that

Entry criteria

Set of generic and specific conditions for permitting a process to go forward with a task/ test phase.

Traceabilitiy

The ability to identify related items in documentation and software, such as requirements with associated tests.

HorizontalTractability

The tracing of requirements for a given test level through it's test documentation, specification etc.

Vertical Tractability

Tracing of requirements through several layers of development.

Test Script

Procedure specification

Experience based test design technique

Procedure to derive and/or select test cases based on testers experience.

Equivalence Partitioning

Black Box testing where you partition a set of test conditions into groups or sets that can be considered the same.




Example if(num < 13 || num > 30)


11 12
31 32

Boundary Value Analysis

Black Box testing based on boundaries between partitions.




always use the boundary values and then 1 below and above etc. I.E 1 and 99 being those values.


ex.


input 1-99


invalid 0


valid 1, 99


invalid 100

Decision Table Testing

Black Box testy where test cases are designed to execute the combinations of inputs shown in a decision table.

State Transition Testing

Black Box test where test cases are designed to execute valid and invalid state transitions.