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
2
Q
Where can test conditions be derived from?
A
- specifications decomposition
- population analysis
- test transactions
- Business process Analysis
- Structural analysis
3
Q
Test transaction types
A
-field record -file -relationship -error -use (outputs) -search -match/merge -stress -control -procedures -attributes -states
4
Q
what does a test condition indicate?
A
What to test
5
Q
Text conditions can only be to ride from requirements?
A
false
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
7
Q
Types of population analysis
A
- files/database/table population
- screen population
- Field/data element population
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
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
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
11
Q
Actors
A
an individual group or entity outside the system
-May include other software systems, hardware components, or other entities
12
Q
Primary actor
A
Wanna have a girl which requires the assistance of the system
13
Q
Secondary actor
A
One from which the system requires assistance
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
15
Q
Happy path
A
follows a single flow uninterrupted by errors or exceptions from beginning to end
16
Q
Sad part
A
Hey path through the app which does not arrive at the desired result
17
Q
Alternate path
A
additional testable conditions are derived from the exceptions in alternative course of the use case
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
19
Q
Preconditions
A
A list of conditions which must be met before the use case can be properly executed
20
Q
Post conditions
A
A list of conditions which will be true after the use case finished successfully
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
user stories include the following:
- functional acceptance criteria
- nonfunctional acceptance criteria
- performance criteria
- Boundaries
26
Acceptance criteria
- things a user will be able to do with the product after a story is implemented
- Conditions of satisfaction
27
Statement testing
requirements that every statement in the program must be executed
28
brand/decision testing
| branch
-test method that requires that each possible branch and each decision point be executed at least once
29
Condition testing
- 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
Branch condition combination coverage
- 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
Modified condition decision coverage
- 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
Data flow analysis
-trace the behavior of program variable for reference, and unreference and defined
33
Path testing
-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
Equivalence partitioning
- 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
Boundary value analysis
- used for testing decisions made based on input values
| - test cases explore the inside and outside edge of the range
36
Decision tables
- method of representing equivalence partitioning
| - describes and analyzes problems that contain procedural decision situations characterized by one or more conditions
37
pair-wise all pairs
- 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
cause-effect graphing
focuses on modeling the dependency relationships are tween a programs input conditions and output conditions
- requirements based test technique
- dependency modeling
39
State transition testing
- 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
State transition
- 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
Scenario testing
- 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
scenario testing Characteristics
- test based on a story
- story is motivating and credible
- story has some complexity
- Test results are easy to evaluate
43
Experience based techniques
uses the experience of the tester to determine what to test
| ex: error guessing
44
Error guessing
- 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
Non-functional test
```
testing non-functional requirements for an app
ex: documentation testing
endurance testing
maintainability
performance
portability
compatibility
compliance
security
stress
usability
Volume
```
46
Non-functional test types
- compatibility
- efficiency
- localization
- Scalability
47
test cases can be built without any prior knowledge of the system.
(true or false?)
false
48
test case building techniques include:
- equivalence partitioning
- boundary value analysis
- Pairwise techniques
49
Building test cases include the following steps
- 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
Measuring test coverage
- 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
A system boundary diagram only depicts the human users in the application under test.
(true or false?)
false
