Test conditions
- 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
Where can test conditions be derived from?
- specifications decomposition
- population analysis
- test transactions
- Business process Analysis
- Structural analysis
Test transaction types
-field record -file -relationship -error -use (outputs) -search -match/merge -stress -control -procedures -attributes -states
what does a test condition indicate?
What to test
Text conditions can only be to ride from requirements?
false
Population analysis
- 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
Types of population analysis
- files/database/table population
- screen population
- Field/data element population
Structural analysis
- 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
Use case
- 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
System boundary diagram
- 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
Actors
an individual group or entity outside the system
-May include other software systems, hardware components, or other entities
Primary actor
Wanna have a girl which requires the assistance of the system
Secondary actor
One from which the system requires assistance
use case fields (format)
-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
Happy path
follows a single flow uninterrupted by errors or exceptions from beginning to end
Sad part
Hey path through the app which does not arrive at the desired result
Alternate path
additional testable conditions are derived from the exceptions in alternative course of the use case
Why should we use “use cases”?
to address the effects of incomplete, incorrect, and missing test cases
-helps with communication between customer, developers, testers, and other project people
Preconditions
A list of conditions which must be met before the use case can be properly executed
Post conditions
A list of conditions which will be true after the use case finished successfully
User story
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
user story notes
- simple
- written by customer or product owner
- incomplete
- placeholder for a Convo
- written quickly
- Easy to understand
Use case notes
- 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
INVEST
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
user stories include the following:
- functional acceptance criteria
- nonfunctional acceptance criteria
- performance criteria
- Boundaries
Acceptance criteria
- things a user will be able to do with the product after a story is implemented
- Conditions of satisfaction
Statement testing
requirements that every statement in the program must be executed
brand/decision testing
branch
-test method that requires that each possible branch and each decision point be executed at least once
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
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
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
Data flow analysis
-trace the behavior of program variable for reference, and unreference and defined
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
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
Boundary value analysis
- used for testing decisions made based on input values
- test cases explore the inside and outside edge of the range
Decision tables
- method of representing equivalence partitioning
- describes and analyzes problems that contain procedural decision situations characterized by one or more conditions
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
cause-effect graphing
focuses on modeling the dependency relationships are tween a programs input conditions and output conditions
- requirements based test technique
- dependency modeling
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
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
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
scenario testing Characteristics
- test based on a story
- story is motivating and credible
- story has some complexity
- Test results are easy to evaluate
Experience based techniques
uses the experience of the tester to determine what to test
ex: error guessing
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
Non-functional test
testing non-functional requirements for an app ex: documentation testing endurance testing maintainability performance portability compatibility compliance security stress usability Volume
Non-functional test types
- compatibility
- efficiency
- localization
- Scalability
test cases can be built without any prior knowledge of the system.
(true or false?)
false
test case building techniques include:
- equivalence partitioning
- boundary value analysis
- Pairwise techniques
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
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
A system boundary diagram only depicts the human users in the application under test.
(true or false?)
false