II - Testing Throughout the Software Development Lifecycle

Question 1

Functional Testing

Answer 1

Evaluates “what“ the system should do. Work products would include: business requirements, functional specs, epics and user stories, and use cases.

Question 2

Non-Functional Testing

Answer 2

Evaluates “how well“ the system behaves.

Question 3

Change Related Testing

Answer 3

Required when functions have been changed or added, to confirm the fix. Ex. Confirmation Testing and Regression Testing

Question 4

Confirmation Testing

Answer 4

A type of Change Related Testing.

Confirms whether the original defect has been successfully fixed.

Question 5

Regression Testing

Answer 5

A type of Change Related Testing.

Re-testing an already tested program after its modification (or a modification in the environment) to make sure that:
- the behavior of other code parts is not influenced unintentionally.
- no new defects are built in.
- no existing defects have been exposed.

Question 6

Characteristics of Good Testing

Answer 6

• For every development activity, there is a corresponding test activity.
• Each test level has test objectives specific to that level.
• Test activities (starting with test analysis and design) for a given test level begin during the corresponding development.
• Testers participate in discussions to define and refine requirements and design.
• Testers are involved in reviewing work products (e.g.,requirements, design, user stories, etc.)

Question 7

Sequential Development Models

Answer 7

A type of Software Development Lifecycle Model. Linear, sequential process (step by step).

Typically done for long-term projects.

Ex. Waterfall or V model.

(terms like validation/verification, usually referring to V model).

Question 8

Waterfall Model

Answer 8

An example of a Sequential Development Model.

• Testing is a “one time only” activity.
• “Final testing” at test closure of a software project.
• The model does not include error correction or a continuation of the project.

Question 9

V Model

Answer 9

An example of a Sequential Development Model.

One side is developer activities, the other side is tester activities.

The V-model integrates the test process throughout the development process, implementing the principle of early testing: Development step, then a Verification + Validation step.

Question 10

Iterative and Incremental Models

Answer 10

A type of Software Development Lifecycle Model. When groups of features are specified, designed, built, and tested together in a series of cycles.

The software’s features grow incrementally.

Typically for shorter-term projects, as it works in weekly increments

Ex. Rational Unified Process (RUP), Scrum/Agile, Kanban, and Spiral (Prototyping).

Question 11

Rational Unified Process (RUP)

Answer 11

An example of an Iterative and Incremental Model.

An outdated model, not used much anymore.

Business value is delivered incrementally in time-boxed cross-disciplined iterations.

Question 12

Scrum/Agile

Answer 12

An example of an Iterative and Incremental Model.

Pull user stories from the Backlog. Items are developed + tested over a short period of time (ex. days or weeks), to produce a potentially shippable product.

Question 13

Kanban

Answer 13

An example of an Iterative and Incremental Model.

Work to do is categorized under 3 categories: To Do, Doing, Done.

Implemented with or without fixed-length iterations,
which can deliver either a single enhancement or feature upon completion, or can group features together to release at once.

Question 14

Spiral (Prototyping)

Answer 14

An example of an Iterative and Incremental Model.

Involves creating experimental increments,
some of which may be heavily re-worked or even abandoned in subsequent development work.

Work with client to prototype the product. Testing begins once client signs off on the “final” prototype.

Question 15

Software Development Lifecycle Model Selection

Answer 15

Software development lifecycle models must be selected and adapted to the context of project and product characteristics.

High-risk / long-term projects should use Sequential models.

Low-risk / shorter-term projects should use Iterative models.

Can also combine models together, depending on the project.

Question 16

Test Levels

Answer 16

Test levels are groups of test activities that are organized and managed together.

Each test level uses at least one instance of the test process.

Includes Component Testing, Integration Testing, System Testing, and Acceptance Testing.

Question 17

Component Testing

Answer 17

Focuses on a single component, like a button, or a field.

Component testing is often done in isolation from the rest of the system and is usually performed by the developer who wrote the code.

Defects are typically fixed as soon as they are found, often with no formal defect management.

Test Basis:
- Detailed Design
- Code
- Data Model
- Component Specifications

Test Objects:
- Components, units, or modules
- Code and data structures
- Classes
- Database models

Question 18

Integration Testing

Answer 18

Includes multiple components. Focuses on interactions between components or systems.

Includes:
- Component Integration Testing, which is usually done by the developer.
- System Integration Testing, which is usually done by the tester. Typically involves testing multiple softwares (ex. Amazon site + payment system).

Test Basis:
- Software and system design
- Sequence diagrams
- Interface and communication protocol specifications
- Use cases
- Architecture
- Workflows
- External interface definitions

Test Objects:
- Subsystems
- Databases
- Infrastructure
- Interfaces
- APIs
- Microservices

Question 19

System Testing

Answer 19

Testing everything together (end to end testing). Focuses on the behavior and capabilities of a whole system or product.
Ex. from logging in to logging out

Typically performed by independent testers.

Test Basis:
- System and software requirement specifications
- Risk analysis reports
- Use cases
- Epics and user stories
- Models of system behavior
- State diagrams
- System and user manuals

Test Objects:
- Applications
- Hardware/software systems
- Operating systems
- System under test (SUT)
- System configuration and configuration data

Question 20

Acceptance Testing

Answer 20

Also known as User Acceptance Testing (UAT).
Making sure it’s easy to use, from a user’s perspective.

Is often the responsibility of the customers, business users, product owners, or operators of a system.

Test Basis:
- Business processes
- User or business requirements
- Regulations, legal contracts and standards
- Use cases and/or user stories
- System requirements
- System or user documentation
- Installation procedures
- Risk analysis reports

Test Objects:
- System under test
- System configuration and
configuration data
- Business processes for a fully integrated system
- Recovery systems and hot sites (for business continuity and disaster recovery testing)
- Operational and maintenance processes
data
- Forms and Reports
- Existing and converted production

Question 21

Component Integration Testing

Answer 21

Focuses on the interactions and interfaces between integrated components. This is generally automated.

Examples of Defects:
- Incorrect data, missing data, or incorrect data encoding
- Incorrect sequencing or timing of interface calls
- Interface mismatch
- Failures in communication between components

Question 22

System Integration Testing

Answer 22

Is performed after the system test or in parallel with ongoing system test activities.
Focuses on the interactions and interfaces between systems, packages, and microservices.

Examples of Defects:
- Inconsistent message structures between systems
- Incorrect data, missing data, or incorrect data encoding
- Interface mismatch
- Failures in communication between systems
- Failure to comply with mandatory security regulations

Question 23

Common Forms of Acceptance Testing

Answer 23

• User acceptance testing
• Operational acceptance testing
• Contractual acceptance testing
• Regulatory acceptance testing
• Alpha and beta testing

Question 24

User Acceptance Testing (UAT)

Answer 24

• Building confidence that the users can use the system to meet their needs, fulfill requirements.
• Perform business processes with minimum difficulty, cost, and risk.

Question 25

Operational Acceptance Testing (OAT)

Answer 25

Build confidence that the operators or system
administrators can keep the system working properly for the users in the
operational environment.

Ex. When the administrative/IT team completes a system update, database upgrade, etc. Usually happens behind the scenes.

• testing of backup and restore
• installing, uninstalling and upgrading
• disaster recovery
• data load and migration tasks
• checks for security vulnerabilities

Question 26

Regulatory Acceptance Testing

Answer 26

Testing is performed against any regulations that must be adhered to, such as government, legal, or safety regulations.

Ex. If you’re a bank or health authority, there would be legal regulations to comply to.

Question 27

Alpha Testing

Answer 27

Potential or existing customers/ user/operator or independent tester perform tests at the developing organization’s site.

Separate team completes the testing, within the company.

Question 28

Beta Testing

Answer 28

Potential or existing customers/user/ operator perform the tests of a SW- System in its intended operational environment at the customer site

Ex. Individual testing a game at their own house.

OR Google initial releases

Question 29

Maintenance Testing

Answer 29

Once deployed to production environments, software and systems need to be maintained.

Completed anytime changes are done on production.

Maintenance is also needed to preserve or improve non-functional quality characteristics over its lifetime, especially
- performanceefficiency
- compatibility
- reliability
- security

Question 30

Triggers for Maintenance Testing

Answer 30

1. Modification, such as:
   - planned enhancements (e.g.,release-based)
   - corrective and emergency changes
   - changes of the operational environment
   (such as planned operating system or database upgrades)
   - upgrades of COTS software
   - patches for defects and vulnerabilities
2. Migration (from one platform to another)
   → operational testing of the new environment
   → testing the changed software
3. Retirement (application reaches the end of its life)
   → testing of data migration
   → testing restore/retrieve procedures
   (after archiving for long retention periods may also be needed)

Regression testing may be needed
→ to ensure that any functionality that remains in service still works.

Question 31

Impact Analysis

Answer 31

When a dev comes to you saying that a major change has been made and maintenance testing is needed, an impact analysis is needed to determine how much maintenance testing will be needed.

Evaluates the changes to:
- identify the intended consequences
- identify possible side effects of a change
- identify the areas in the system that will be affected by the change
- determines the extent to which regression testing is to be carried out
- help to decide if the change should be made

Question 32

What can make Impact Analysis Difficult?

Answer 32

• specifications are out of date or missing
• test cases are not documented or are out of date
• bi-directional traceability between tests and the test basis has not been maintained
• tool support is weak or non-existent
• the people involved do not have domain and/or system knowledge
• insufficient attention has been paid to the software’s maintainability during development

Question 33

Test Object

Answer 33

The component or system to be tested.

Question 34

Test Basis

Answer 34

The body of knowledge used as the basis for test analysis and design.

Question 35

White-box testing

Answer 35

Testing based on an analysis of the internal structure of the component or system.