Please enable JavaScript.
Coggle requires JavaScript to display documents.
Testing (Requirements Driven Testing (The UML expresses functional…
Testing
Requirements Driven Testing
The UML expresses functional requirements as use cases
Non-functionals also require testing
Each use case becomes a set of test cases
Normal and alternative path
testing a group of test conditoins
Know as black box testing,
External view of the sytem
Exit Criteria - based on error free delivery of a solution that meets the use case specificaitons
Or maybe only the 'Must haves'
Test Condition
A test condition is defined as “... an item or event of a component or system that could be verified by one or more test cases, e.g. a function, transaction, feature, quality attribute, or structural element” (ISTQB Glossary)
Test Case
... a set of input values, execution pre-conditions, expected results and execution post-conditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement.” (ISTQB Glossary)
TC1, TC2 etc
Alternative path includes, i.e. valid user, then invalid user
Test Data
Input data
Input required the test the condition - i.e. username/password
base data
Stored data i.e. customer/product data/EVCs
UC (Use Case)Step - Test Condition - input data - base data - Expected Result
1 - Selection of the ‘Register New User’ option - Option selection - none - 'Register User' screen appears
2 - input of a (new) valid User ID - UserID = bob - user bob is not there - input accepted by system
Testing non functionals
May not be testable
Cover with an SLA if they can't be tested.
Professional testers at better at it than developers
Different mentality,
Trained in techniques
Independent
testing show the presence of defects
Exhaustive testing is impossible
testing should start as early as possible in the SDLC
Systems vary in criticality
target testing based on risk
It may find defects, but no guaratnees
Requires planning and support