CSIT 314 - Topic 5 - Verification & Validation and Test-driven development
CSIT 314 - Topic 5 - Verification & Validation and Test-driven development
Software Development
Methodologies
Verification & Validation and Test-driven development
Software Development Activities
• Verification:
– "Are we building the product right?“
• The software should conform to its specification (such as
non-functional requirement).
• Validation:
– "Are we building the right product?“
• The software should do what the user really requires.
Verification & Validation
• Software inspections
– analysis of the static system representation to discover
problems (static verification)
• Software testing
– executing and observing product behaviour (dynamic
verification)
• The system is executed with test data and its operational
behaviour is observed
Static and Dynamic Verification
http://csis.pace.edu/~marchese/SE616_New/L8/L8.htm
Software inspections
• Statement coverage
– each statement is executed at least once
• Decision (branch) coverage
– each statement …; each decision takes on all possible outcome
at least once
• Condition coverage
– each statement…; each decision …; each condition in a
decision takes on all possible outputs at least once
• Path coverage
– each statement …; all possible combinations of condition
outcomes in each decision occur at least once
Black Box Testing
• Without knowing the internal works
• Systematic (non-uniform):
– Try to select important inputs (with specially valuable)
• Usually by choosing representatives of classes that are apt
to fail often or not at all
Example:
• Pizza values 1 to 10 is
considered valid. A success
message is shown.
• While value 11 to 99 are
considered invalid for order and
an error message will appear,
"Only 10 Pizza can be ordered“.
Source: https://www.guru99.com/equivalence-partitioning-boundary-value-analysis.html
Boundary Value Analysis
• Code coverage
– Every code segment that you write has at least one
associated test so all code written has at least one test.
• Regression testing
– developed incrementally to make sure changes have not
‘broken’ previously working code.
• Simplified debugging
– When a test fails, it should be obvious where the problem
lies. The newly written code needs to be checked and
modified.
Tools
• cpputest
• csUnit (.Net)
• Cunit
• HTMLUnit
• HTTPUnit
• JUnit
• PHPUnit
• PyUnit (Python)
• DocTest (Python)
• TestOoB (Python)
• Test::Unit (Ruby)
• VBUnit