05 Software Testing and Validation Flashcards
What are test cases
description of a set of actions performed on software and expected outcome
what are tests
- execution of test case
- produces outcome
what is Testing
practice of creating, maintaining, executing, evaluating test cases
What is software testing
- process to execute program using data to simulate user input
- process of locating, identifying bugs before delivery to user
- part of general verification and validation
what are program testing goals
- demonstrate to stakeholders that software meets requirements
- discover which behaviour is incorrect, undesirable, does not conform to specifications
What is a “good” test
- high probability of finding error
- neither too simple nor complex
- not redundant
- detect maximum number of errors
How to ensure accuracy of software
- verification
- check consistency of an output of software with its input - validation
- assess how software fulfills its requirement - defect testing
- discover faults in software that does not conform with specification
verification examples
- is the software built right
- does software meets functionality
- takes place first
- goal: application and architecture
- static activities
- use reviews and walkthroughs
validation examples
- are we building the right product
- does functionality meet intended behaviour
- after verification
- goal: actual product
- dynamic activities and execution of code
- use black/white box testing, nonfunctional test
static analysis
inspection:
1. requirement specification
2. architecture
3. UML design
4. database schema
5. program
6. unable to check nonfunctional such as performance and usability
dynamic analysis
testing:
1. exercising
2. observing product behaviour
static/dynamic testing differences
static
1. find bug without code execution
2. verification stage
3. cost effective
4. done with reviews, walkthroughs, inspections
dynamic
1. execute code to find result
2. validation stage
3. expensive
4. done with unit, system, integration tests
software testing process
- design test cases
- prepare test data
- run program with test data
- compare result to test cases
inputs: preconditions
expected: post conditions, actual output
stages of testing
- development testing
- unit test
- integration test
- system test - release testing
- separate testing team test before release to user - user test
- customer test solution on their own environment
debugging process
- identify problems
- identify cause of problems
- fix problems
- evaluate solution
error handling approaches
- ignore
- failfast
- program stops immediately, reports error - failsafe
- program acknowledges error
- continues execution in best way possible
ideal test policies
exhaustive testing
- test all possible scenarios
- impractical but not impossible
- need testing techniques for wide coverage without exhaustive testing
test driven development
- write test cases before writing code
- run code with test
- move to next increment after test case passes
benefits of TDD
- code coverage
- all code pass at least one test - regression testing
- test is developed incrementally with code - simplified debugging
- if code fails, only newly written code needs to be checked - system documentation
- test act as a form of documentation
black box testing
- functionality testing
- based solely on analysis of requirements
- without knowing internal codes
- can be applied to every level of testing
- able to detect
- incorrect functions
- interface error
- usability problem
- concurrency and timing
- data structure/db access
white box testing
- structured test
- based on analysis of internal logic
- compared with expected results
advantages of black box testing
- unbiased as tester is not developer
black box testing disadvantages
- unnecessary testing
- different way to test the same thing - insufficient testing
- miss out corner cases
