IN4MATX 43 Chapter Notes - Chapter Reading 14: Equivalence Class, Boundary-Value Analysis, Equivalence Partitioning
2 Jun 2018
School
Department
Course
Professor
IN4MATX – 36900 – Intro to Software Engineering
Week 7 – Reading 14 – Testing and Quality Assurance
10.3 – Intro to Testing and Quality Assurance
• Quality usually defined as meeting specs and fit to use
• Therefore is a need for testing; to detect and correct errors in software product
• Quality really depends on process
o But sometimes processes aren’t as they should be; which is why we have
testing
• Quality assurance – all activities designed to measure and improve quality in a
product
o Includes education, training, preparation and process of teams
• Quality control – activities designed to verify quality of product, detect faults or
defects, and ensure that they are fixed before launch
• Every software program has static structure and a dynamic behavior
o Static structure – structure of the source code
o Intermediate software products
▪ Requirements, analysis, and design documents
▪ Only have a static structure
• Detecting errors in programs and intermediate documentation
o Testing
▪ Designing test cases to use on the program in a controlled
environment
▪ Verifying output of tests are correct
▪ Testing one of the most important in quality control
o Inspections and reviews
▪ Applied to both program or intermediate software documents
▪ Requires more than one person alongside original creator
▪ Labor intensive by very effective
▪ Most cost effective
o Formal methods
▪ Mathematical techniques to prove program is correct
▪ Rarely applied in business and commercial
o Static analysis
▪ Analyzing static structure of either program or intermediate
software product
▪ Automated and detects errors or error-prone conditions
• Quality of a product
o Conforms to specifications
o Serves its purpose
o These two above are NOT equivalent
▪ A product may conform but serve no useful purpose
• Definitions of quality
find more resources at oneclass.com
find more resources at oneclass.com
o Juran and De Feo – fitness to use
o Crosby – conformance to requirements with emphasis no prevention of
error and zero defects
• Two activities relating to quality
o Verification
▪ Checking that a software product conforms to reqs. And specs.
▪ Reqs are traced through dev phases
▪ Transformation of software between phases is verified
o Validation
▪ Checking that a finished software pdocut meets users’ reqs and
specifications
▪ Usually done in beginning of project with prototypes
• Fault, Failure and Error
o Usually identify fault as a cause of failure but faults can exist without
causing failures
o During testing, failures may reveal faults
o Failure/Problem – inability of system to perform function according to its
specs
o Fault/Defect – condition that may cause failure in system; caused by error
made by software engineer (also called a bug)
o Error – mistake made by software engineer or programmer
o Examples
▪ Fault – a req that is hard to understand
▪ Failure – the above becomes a failure if it leads to
misunderstanding of req
▪ Error – the above then turns into an error in design and code that
all manifests as software failure
o Summary
▪ Human error creates a fault
▪ Fault may cause a failure
▪ Not all defects turn into failures; esp those that are dormant/hidden
unless specified testing is done
• Explicit and Implicit requirements
o Explicit
▪ Needs to be mentioned in reqs documents
▪ Recognized as authoritative by software team
o Implicit
▪ Not authoritative, but are good references and should be followed
▪ Implicit needs to be made explicit for inspection or review or testing
10.2 – Testing
find more resources at oneclass.com
find more resources at oneclass.com
• Definition
o Testing is an activity performed for evaluating product quality, and for
improving it, by identifying defects and problems
• Software testing
o Dynamic verification of program behavior based on test cases
• Definition of test criteria
o Used to determine which of the infinite possible tests to run
• Testing
o Complex activity involving many other activities and therefore has to be
planned accordingly
10.2.1 – The Purpose of Testing
• Two main purposes of testing
o Find defects in software in order to correct or control
o Provide general assessment of quality, including estimate of possible
remaining faults
• View of the first
o Main purpose of testing to find faults; the more the better
o A bit negative view and often makes testers uncomfortable
• View of the second
o More positive
o Proving that the software product works
• Testing CANNOT prove that a product works
o Only finds defects and shows that product works for the tested cases
o No guarantee for anything other than the test cases
• Testing Techniques
o Who does the testing?
▪ Programmers
• Create test cases and run as they write the program
• Usually considered to be unit testing
▪ Testers
• Role is specifically to test items by writing test cases and
ensuring execution
• Programming knowledge is extremely useful, but testing
requires different intellectual requirements
▪ Users
• Good idea to involve users in testing to detect usability
problems
• Good for subjecting program to real-world scenarios
• Also known as Alpha testing if users are from organization;
Beta testing if not
find more resources at oneclass.com
find more resources at oneclass.com
Document Summary
In4matx 36900 intro to software engineering. Week 7 reading 14 testing and quality assurance. Implicit: not authoritative, but are good references and should be followed. Implicit needs to be made explicit for inspection or review or testing. Beta testing if not: what is test, unit testing testing individual units functionality; procedures, methods, or classes, functional testing determining of individual units work when put together. 10. 3. 1 equivalence-class partitioning: equivalence-class partitioning, spec-based, black-box technique. If program fails for one member of class, expect it to fail for all, same for correctness: equivalence classes, determined using req specs and by tester"s intuition; without looking at implementation. It"s not always clear what to choose as equivalence class: most useful when reqs are expressed as a series of conditions, but not for when the reqs seem to call for loops. 10. 3. 3 path analysis: test design technique that is reproducible traceable, and countable, often used as white-box testing technique.
