Why do we engineer software?
To solve customer’s problem.
To produce quality product within budget and scheudle.
To show the product (software) is indeed high quality.
What is a problem?
A difference between things as desired and things as perceived.
Stakeholders
Those who have a stake in the change being considered and who stand to gain or lose from the change.
Testing Original Purpose:
Demonstration of proper behavior or quality demonstration.
Testing New Purpose:
Defect Detection and Reduction.
Archieve defect-free software.
Oracle
The expected behavior of an operation.
The actual output should be compared with the “Oracle”
Ad-Hoc Testing
“Run and Observe”
One way to structure is to build a checklist
A type of informal testing that is performed without any formal test plan or test cause creation.
Ad-Hoc Drawbacks
Lack of structure
Likely to miss and repeat oneself.
Whole Process is hard to repeat.
Systematic Testing
Process is explicitly defined.
Testing with checklists.
Reliability
Probablity of failure-free operation for a specific period or a given set of input under a specific environment.
Creativity
Ability to produce work that is both Novel and Appropriate.
How to measure creativity in RE?
Rate the requirements at a 5 point Likert Scale.
Kappa Statistic : Show the level of agreement among participants.
In recent Years, we rate Clarity, Novelty and Usefulness.
Requirement Based Testing
Address 2 Major Issues:
1. Check/Validate the requirements for Correctness, Completeness, Ambiguity, and Logical Consistency.
- Designing a set of test cases for requirements from a black box perspective.
Quality Assurance:
To ensure that few , if any, defects remain in the software when it is delivered to its customers or released to the market.
Error
A mistake made by a programmer or software engineer which caused the fault, which in turn may cause a failure.
Fault
Condition/ Internal characteristic that may cause a failure in the system.
Failure
Inability of the system to perform a function according to its specification due to some fault.
Defect Relationship
Errors causes Faults.
Faults causes Failures.
TDD
A software development process where a unit’s test are written before the unit’s implemention and guide the unit’s development as the tests are executed repeatedly until they all succeed, signaling complete functionality.
TDD Process Steps
Red:
Write a new test for a section.
Verify failure of the new test and the success of existing tests.
Green:
Write code to implement, modify or develop the unit.
Repeat until the tests pass.
Refactor:
Refactor the code to improve non-functional code structure, style, and quality.
Confirm tests pass.
Repeat.
Unit
The smallest executable or testable component of a system.
Unit Testing vs TDD
Input Domain
Space of all allowable test points
Input SubDomain
Subset of input domain defined with a concrete relationship
