Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Certified Associate in Software Testing (CAST) > skill category 7 > Flashcards

skill category 7 Flashcards

1
Q

Test conditions

A
  • describe the specific functional capability, structural design, consideration, features, and validation checks which needs to be validated
  • System specs is the primary source for test conditions
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Where can test conditions be derived from?

A
  • specifications decomposition
  • population analysis
  • test transactions
  • Business process Analysis
  • Structural analysis
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Test transaction types

A 
-field
record
-file
-relationship 
-error 
-use (outputs) 
-search
-match/merge
-stress
-control -procedures
-attributes -states
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

what does a test condition indicate?

A

What to test

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

Text conditions can only be to ride from requirements?

A

false

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

Population analysis

A
  • analyze prod data to identify, independent from the specs, the types in frequency of data that the system will have to process/produce
  • this verifies that the specs can handle types and frequency of actual data and can be used to create validation test
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Types of population analysis

A
  • files/database/table population
  • screen population
  • Field/data element population
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Structural analysis

A
  • technique used by developers to define unit test cases
  • involves path and condition coverage
  • benefit – find effects not obvious from blackbox or external perspectives
  • con: can’t find defects in software’s fitness for use in a user environment
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Use case

A
  • A technique for capturing a functional requirements of systems through the interaction between an actor and they system
  • create it as part of requirements definition are via JAD
  • A description of how a user uses the system being designed to perform a given task
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

System boundary diagram

A
  • depicts the interfaces between the software under test and the individuals, systems, and other interfaces
  • purpose is to establish the scope of the system and to identify the actors that need to be developed
  • each boundary, an actor must be identified
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Actors

A

an individual group or entity outside the system

-May include other software systems, hardware components, or other entities

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

Primary actor

A

Wanna have a girl which requires the assistance of the system

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

Secondary actor

A

One from which the system requires assistance

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

use case fields (format)

A 
-unique identifier and name 
summary description
-frequency/iteration number
-status, actors, trigger 
-Basic and alternate course of events
-pre-and post conditions
-Business rules and assumptions
-Notes in author, action and date
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Happy path

A

follows a single flow uninterrupted by errors or exceptions from beginning to end

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

Sad part

A

Hey path through the app which does not arrive at the desired result

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

Alternate path

A

additional testable conditions are derived from the exceptions in alternative course of the use case

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

Why should we use “use cases”?

A

to address the effects of incomplete, incorrect, and missing test cases
-helps with communication between customer, developers, testers, and other project people

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

Preconditions

A

A list of conditions which must be met before the use case can be properly executed

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

Post conditions

A

A list of conditions which will be true after the use case finished successfully

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

User story

A

short description of some thing that a customer will do when they use an app

  • Focus on the value of result a customer would receive during whatever it is the App does
  • POV of a user
22
Q

user story notes

A
  • simple
  • written by customer or product owner
  • incomplete
  • placeholder for a Convo
  • written quickly
  • Easy to understand
23
Q

Use case notes

A
  • complex
  • written by a business analyst or developer
  • attempts to be complete
  • intend to answer any questions
  • May take some time
  • May take some training to understand
24
Q

INVEST

A

invest in your user stories
-Independent: user stories do not overlap each other
-Negotiable: can change until it enters iteration
-valuable: A user story must deliver value to the end-user
Estimable: user stories must be created such that their size can be estimated
Small: should require no more than four days to implement
Testable: provide the necessary info to make test development possible

25
Q

user stories include the following:

A
  • functional acceptance criteria
  • nonfunctional acceptance criteria
  • performance criteria
  • Boundaries
26
Q

Acceptance criteria

A
  • things a user will be able to do with the product after a story is implemented
  • Conditions of satisfaction
27
Q

Statement testing

A

requirements that every statement in the program must be executed

28
Q

brand/decision testing

branch

A

-test method that requires that each possible branch and each decision point be executed at least once

29
Q

Condition testing

A
  • each clause in every condition is forced to take on each of its possible values in combination with those of other clauses
  • Breaking compound condition statements into simple conditions and testing the resulting “if” statement
  • make sure that every decision is evaluated to be truth and false
30
Q

Branch condition combination coverage

A
  • A very thorough structural testing technique requiring to 2(^n) test cases to achieve 100% coverage of a condition containing n Boolean operands
  • all combinations of true/false are covered
  • creates 2(^xx)n combos
31
Q

Modified condition decision coverage

A
  • requires test cases to show that each Boolean operand can independently affect the outcome of the decision
  • collapse the branch condition combination where possible
32
Q

Data flow analysis

A

-trace the behavior of program variable for reference, and unreference and defined

33
Q

Path testing

A

-systematic method of white box testing, where the aim is to identify the execution paths through each module of program code and then create test cases to cover those paths

34
Q

Equivalence partitioning

A
  • The input domain of a system is partitioned into classes of representation value so that the number of test cases can be limited to one per class, which represents the minimum number of test cases that must be executed
  • benefit: don’t need to generate redundant test cases by testing each possible value with identical outcomes
35
Q

Boundary value analysis

A
  • used for testing decisions made based on input values

- test cases explore the inside and outside edge of the range

36
Q

Decision tables

A
  • method of representing equivalence partitioning

- describes and analyzes problems that contain procedural decision situations characterized by one or more conditions

37
Q

pair-wise all pairs

A
  • combination of method used to generate the least number of test cases necessary to test each pair of input parameters to a system
  • test all possible discrete combinations of those parameters
38
Q

cause-effect graphing

A

focuses on modeling the dependency relationships are tween a programs input conditions and output conditions

  • requirements based test technique
  • dependency modeling
39
Q

State transition testing

A
  • System must remember what happened before or when valid and invalid orders of operations exists
  • Becomes large and cumbersome with the number of states and events increase
40
Q

State transition

A
  • understand the various states
  • identify transitions
  • model the system
  • confirm the state changes
  • Create test cases to visit all states, trigger all events and execute all paths
41
Q

Scenario testing

A
  • testing based on real world scenario of how the system is supposed to act
  • Use case testing in agile story testing are considered scenario testing types
42
Q

scenario testing Characteristics

A
  • test based on a story
  • story is motivating and credible
  • story has some complexity
  • Test results are easy to evaluate
43
Q

Experience based techniques

A

uses the experience of the tester to determine what to test

ex: error guessing

44
Q

Error guessing

A
  • test data selection technique for picking values that seem likely to cause defects
  • Based on the theory that test cases in test data can be developed based on the intuition and experience of the tester
45
Q

Non-functional test

A 
testing non-functional requirements for an app
ex: documentation testing
endurance testing
maintainability
performance
portability
compatibility
compliance
security
stress
usability
Volume
46
Q

Non-functional test types

A
  • compatibility
  • efficiency
  • localization
  • Scalability
47
Q

test cases can be built without any prior knowledge of the system.

(true or false?)

A

false

48
Q

test case building techniques include:

A
  • equivalence partitioning
  • boundary value analysis
  • Pairwise techniques
49
Q

Building test cases include the following steps

A
  • use what needs to be tested
  • utilize test techniques
  • define what needs to be executed
  • determine what is being covered
  • determine what is expected
50
Q

Measuring test coverage

A
  • Measure the coverage of a set of test cases
  • analyze test cases coverage against system requirements
  • develop new test cases for test previously uncovered parts of a system
51
Q

A system boundary diagram only depicts the human users in the application under test.

(true or false?)

A

false

Certified Associate in Software Testing (CAST) (6 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions