Software Development Lifecycle Models
Describes the types of activity performed at each stage in a software development project, and how the activities relate to one another logically and chronologically.
Characteristics of good testing
- For every development activity, there is a corresponding test activity
- Each test level has test objectives specific to that level
- Test analysis and design for a given test level begin during the corresponding development activity
- Tester participates in discussions to define and refine requirements and design, and are involved in reviewing work products
Sequential model
- Sequential flow of activities
- This means that any phase in the begin in the development process should begin when the previous phase is complete
- In theory, there is no overlap of phases, it is beneficial to have early feedback from the following phase
Incremental Development
- Pieces
- Software grows incrementally
- The size of these feature increments vary
- The feature increments can be as small as a single change to a user interface screen
Iterative
- Groups of features
- Fixed duration
- Each iteration delivers working software which is a growing subset of the overall set of features
- Fast feedback from the customer
Waterfall Model
- Activities are completed one after another
- Test activities only occur after all other development activities have been completed
V-model
- Sequential
- Early-testing
- The customer doesn’t see the software until the acceptance testing
- Planning, designing and execution
Rational Unified Process RUP
- Each iteration tends to be relatively long (two or three months)
- Iterative and Incremental model
Scrum
- Agile
- Each iteration tends to be relatively short (days, a few weeks)
- Feature increments are correspondingly small
Kanban
- Implemented with or without fixed-length iterations
- Incremental model
Spiral or prototyping
- Experimental Increments
- Heavily re-worked or even abandoned in subsequent
Test Levels
- Test levels are groups of test activities that are organized and managed together
- Each test level is an instance of the test process
- Test levels are related to other activities within the software development lifecycle
- For every test level, a suitable test environment is required.
Are characterized:
- Specific objectives
- Test basis, referenced to derive test cases
- Test object (what is being tested)
- Typical defects and failures
- Specific approaches and responsibilities
Component Testing or Unit Testing
- Focuses on components that are separately
- Reduce risk-find defects-prevent defects
- Behavior
- TEST BASIS→ Detailed design-code-data model component specification
- TEST OBJECTS→ Components - Units Modules - Code - Data Structures - Classes - database modules
- DEFECTS AND FAILURES→ Incorrect functionality - Data flow problems - Incorrect code and logic
- Done by the developer - TDD
TDD ⇒ Fail → Pass → Refactor
Integration Testing
- Interactions between components or systems
- System Integration Testing is after system testing not after integration testing
- If integrating module A with module B, tests should focus on the communication between the modules, not the functionality of the individual modules
- If integrating system X with system Y, tests should focus on the communication between the systems, not the functionality of the individual systems.
- Responsibility for TESTER, black box testing
- OBJECTIVES → Reduce risk-find defects-prevent defects
- TEST BASIS → Software and system design - Sequence diagrams - use cases - workflows
- TEST OBJECTS → Subsystems - APIs - Microservices - Interfaces - Databases - Infrastructure
- DEFECTS AND FAILURES → Failures in communication - Incorrect data - Interface - Incorrect data
- Top down - bottom up - simulators - stubs - drivers
- Integration should normally be incremental
- This is one reason that we use continuous integration, where software is integrated on a component-by-component basis
Integration Testing
• Component integration testing focuses on the interactions and interfaces between integrated
components. Component integration testing is performed after component testing, and is
generally automated. In iterative and incremental development, component integration tests are
usually part of the continuous integration process.
• System integration testing focuses on the interactions and interfaces between systems,
packages, and microservices. System integration testing can also cover interactions with, and
interfaces provided by, external organizations (e.g., web services). In this case, the developing
organization does not control the external interfaces, which can create various challenges for
testing (e.g., ensuring that test-blocking defects in the external organization’s code are resolved,
arranging for test environments, etc.). System integration testing may be done after system
testing or in parallel with ongoing system test
System Testing
- Focuses on the behavior and capabilities of a whole system
- Often considering the end-to-end tasks the system can perform
- Produces information that is used by stakeholders to make release decisions
- Test environment should ideally correspond to the final target or production
- Focus on the overall
- Independent tester typically carry out system testing
- OBJECTIVES → Reduce risk - find defects - prevent defects
- TEST BASIS → SRS - Risk analysis reports - use cases - epics - user stories
- TEST OBJECTS → Applications - operating systems - system under test - system configuration
- DEFECTS AND FAILURES → System failure - Incorrect data flow - unexpected behavior
Acceptance Testing
- Like system testing
- Focuses on the behavior and capabilities of a whole system or product
- May produce information to assess the system readiness for deployment and use by the customer (end-user)
- Defects may be found during acceptance testing, but finding defects is often not an objective.
- OBJECTIVES → Establish confidence - validate system - verify behavior
- TEST BASIS → Business processes - requirements - use cases - installation procedures - risk analysis reports - regulations contracts
- TEST OBJECTS → System under test - recovery systems - hot sites - forms - reports
- DEFECTS AND FAILURES → System workflow - Business rules - Contract - Non-functional failures
- Operational Acceptance Testing
Which testing level is primarily focused on building confidence rather than finding defects?
Acceptance testing
If you need to add system integration testing as a test level for a particular project, what testing level should it directly follow?
→ System Testing
Functional Testing
- Involves tests that evaluate functions that the system should perform.
- Functional requirements may be described in work products such as
- User stories
- Use cases
- Functional specifications
- They may be undocumented.
- What the system should do
- Should be performed at all test levels, though the focus is on difference at each level
- BLACK BOX → may be used to derive test conditions and test cases for the functionality of the component or system in different
- Functional coverage is the extent to which some type of functional element has been exercised by tests.
Non-Functional Testing
- How well the system behaves
- Usability, performance, efficiency or security
- Can be done at all test levels
White-box Testing
- Derives tests based on the system internal structure or implementation
- Internal structure may include code, architecture, workflows, and/or data flows within the system
- We look at the internal structure systems
- Structural Coverage Percentage of the type of element being covered
- Code coverage is based on the percentage of component code that has been tested
Which of the following is mostly true regarding structural testing?
→ Deriving tests based on the system internal structure
Which of the following is a correct definition of structural coverage?
→ The extent to which some type of structural element has been exercised by tests
