1
Q
Software Project Management
A
Discipline of managing projects to completion (all features/scope) while achieving quality within time constraints & budget.
2
Q
Software Quality
A
Discipline of specifying, assuring, monitoring & controlling quality of software products. In SE, measures how well software designed & how well it conforms to that design.
3
Q
Software Verification
A
Have we built software right? Have we made right decision each step of the way?
4
Q
Software Validation
A
Have we built right software? How well does product address business needs?
5
Q
Software Testing
A
Techniques to execute programs with intent of finding as many defects as possible/gaining sufficient confidence in Software Under Test (SUT).
6
Q
Software Inspections
A
Techniques aimed at systematically verifying software artifacts (design docs, code, tests etc) without executing them, with intent of finding as many defects as possible, as early as possible.
7
Q
What are the factors of software quality?
A
Functional stability, reliability, performance efficiency, operability, security, compatibility, maintainability and portability
8
Q
Functional Stability
A
Functional appropriateness, accuracy and compliance
9
Q
Reliability
A
Maturity, availability, fault tolerance, recoverability and compliance
10
Q
Performance Efficiency
A
Time-behaviour, resource utilisation and compliance
11
Q
Operability
A
Appropriateness, recognisability, learnability, ease of use, attractiveness, technical accessibility and compliance
12
Q
Security
A
Confidentiality, integrity, non-repudiation, accountability, authenticity and compliance
13
Q
Compatibility
A
Co-existence, interoperability and compliance
14
Q
Maintainability
A
Modularity, reusability, analysability, changeability, modification stability, testability and compliance
15
Q
Portability
A
Adaptability, installability, replaceability and compliance
16
Q
Correctness
A
Does software perform as expected?
17
Q
Understandability
A
- Are var names descriptive of physical/functional property represented?
- Do uniquely recognisable functions contain adequate comments so their purpose is clear?
- Are deviations from forward logical flow adequately commented?
- Are all elements of array functionally related?
18
Q
Completeness
A
- Are all necessary components available?
- Does any process fail for lack of resources/programming?
- Are all potential pathways through code accounted for, including proper error handling?
19
Q
Conciseness
A
- Is all code reachable?
- Is any code redundant?
- How many statements within loops could be placed outside loop, reducing computation time?
- Are branch decisions too complex?
20
Q
Portability
A
- Does program depend upon system/library routines unique to certain installation?
- Have machine-dependent statements been flagged & commented?
- Has dependency on internal bit rep of alphanumeric/special chars been avoided?
- How much effort required to transfer program from 1 hardware/software system/environment to another?
21
Q
Consistency
A
- Is 1 var name used to rep diff logical/physical entities in program?
- Does program contain only 1 rep for any given physical/mathematical constant?
- Are functionally similar arithmetic expressions similarly constructed?
- Is consistent scheme used for indentation, nomenclature, colour palette, fonts & other visual elements?
22
Q
Maintainability
A
- Has some memory capacity been reserved for future expansion?
- Is design cohesive (does each module have distinct, recognisable functionality)?
- Does software allow for change in data structures (object-oriented designs more likely to allow for this)?
- If code is procedure-based (not object-oriented), is change likely to require restructuring main program or just module?
23
Q
Testability
A
- Are complex structures employed in code?
- Does detailed design contain clear pseudocode?
- Is pseudocode at higher level of abstraction than code?
- If tasking used in concurrent designs, are schemes available for providing adequate test cases?
24
Q
Usability
A
- Is GUI used?
- Is there adequate online help?
- Is user manual provided?
- Are meaningful error messages provided?
25
Reliability
- Are loop indexes range-tested?
- Is input data checked for range errors?
- Is divide-by-zero avoided?
- Is exception handling provided?
- It is probability that software performs its intended functions correctly in specified time period under stated op conditions, but could be issue with req doc.
26
Efficiency
- Have functions been optimised for speed?
- Have repeatedly used code blocks been formed into subroutines?
- Has program been checked for memory leaks or overflow errors?
27
Security
- Does software protect itself & its data against unauthorised access & use?
- Does it allow its operator to enforce security policies?
- Are security mechanisms appropriate, adequate & correctly implemented?
- Can software withstand attacks that can be anticipated in its intended environment?
28
Error
Root cause, committed by people
29
Fault
Result of human error in software doc/code
30
Failure
Occurs when fault executes
31
Incident
Consequences of failures, failure occurrence may/may not be apparent to user
32
Defects
Error/fault/failure/incident, usually a fault (bug)
33
Error-propogation
Fault -> causation -> failure -> results in -> incident
34
Test case
Set of inputs & expected outputs for unit/module/system under test. Without expected outputs, test case not complete
35
What should a good test case do?
- Be effective at uncovering faults
- Help locate faults for debugging
- Be repeatable so precise understanding of fault gained
- Can be automated to lower cost & timescale
- Be systematic so it’s predictable
36
What should a good bug report include?
- Function being tested
- Initial state of system
- Steps to reproduce defect/bug
- Expected Outcome
- Actual Outcome
37
Test suite/set
Set of test cases (minimum of 1)
38
Test-case design
Art & science of deriving efficient but effective num of test cases. Less is more - less cases, max chance of covering faults
39
Pair testing
Software dev technique where 2 people work at 1 keyboard to test software app. 1 tests & other analyses/reviews testing
40
Waterfall Method
Testing at end (Test-Last Development, TLD). Bad - too late, too costly & not enough time. Analysis → Design → Implementation → Testing
41
TDD
Test-driven development, used in Agile & DevOps, testing throughout
42
Test Coverage
Percentage of obligations met
43
Test coverage in black-box testing (functional)
- All use cases
- All menu items
- All states
- All boundary values
- Derive test cases from specifications/reqs
- No access to source code
- Can show missing functionality
44
Test coverage in white-box testing (structural)
- All methods
- All statements
- All code branches (if/else)
- Deriving test cases from implementation (source code)
- Expected outputs derived from specs/reqs
- Can show unexpected functionality
45
Exhaustive/complete testing
- Testing software system using all possible inputs
- Usually impossible
- Technique used to reduce num inputs
- Testing criteria group input elements into equivalence classes
- 1 input selected in each class (notion of test data coverage)
46
Types of non-functional testing
- Testing non-functional reqs
- Performance testing
- Load testing
- Endurance testing
- Localisation/internationalisation testing
- Recovery testing
- Security testing
- Stress testing
- Installation testing
- Compatibility testing
- Usability testing
- Scalability testing
- Reliability testing
47
Types of testing based on test levels
- Unit/Module/Component Testing (Individual Component)
- Integration Testing (Integrated Component)
- System Testing (Entire System)
- User Acceptance Testing (Final System)
48
Regression testing
Any type of software testing to uncover new defects (regressions) in existing (old) functionality after new changes made during maintenance (e.g. functional enhancements, patches & config changes)
Intent is to ensure change didn’t introduce new faults.
1 of main reasons for it is that it’s often difficult for software eng to figure out how change in 1 part of software will echo in other parts of software. Can be manual or automated.
49
Functional testing
Testing functional requirements and checking correct functionality of system
50
Automated testing
- Specs, models & code used to derive test cases
- Automated oracle needed
- Test execution easily repeatable
- Massive input data possible
51
Manual testing
- Clever test-case design
- Interaction with system
- Inspiration for new tests
- Human oracle
- Single test case execution
- Limited data
52
Manual scripted testing
- Oldest, rigorous.
- Test cases designed & reviewed by team before execution.
- Can be created at basic functionality level or scenario level.
- Heavy on doc & requires considerable resources to create test scripts, which often become outdated as SUT changes.
- Makes test cases repeatable & easy enough for new person to start testing with min supervision.
- Also used when written software spec must be met for successful implementation of project.
- Scripted test cases useful when tests for benchmarking & must be same each time.
53
Test evaluation
Determine outcome of each test case (pass/fail), report to devs (enter in bug database)
54
Test execution
Run tests on software (manual/auto) and record results
55
Test automation
- Using any software tool in any other test activities
- Auto execute tests on SUT
- Derive test cases
- Write code to test code, use “test tools”
56
Test-Case Design (Criteria-Based)
Design test values to satisfy coverage criteria, covering all lines of code
57
Test-Case Design (Exploratory - Human Based)
- Design test values based on domain knowledge of program & human knowledge of testing, exploratory testing
- Commonly used term for testing with little/no planning & doc.
- Manual, no test script. Tests run once unless defect discovered.
- Major issues can be found quickly, performed with improvisation - tester seeks to find bugs however they choose.
- Contrasts to regression testing that looks for specific issue with detailed repro steps & clear expected result.
- Exploratory testing is generally complementary.
Software Testing
flashcards
Decks in class (3)
# Cards
