In this short series, I outline the notes that I took while preparing for this foundation exam.
While the content may not have changed drastically in the time that I took the exam, there may have been small changes or additions that my notes don’t cover. So I would advise you that if you do use my notes to help you revise for the Foundation exam, that you use them as a supplement to the most recent edition of the book (this is an affiliate link) and go over your knowledge with practice exam papers.
Previous notes within this blog series:
Software Development Models
Development cycles that facilitate the work-product early to evaluate: V-model and Cyclical (iterative) models
Requirement specification – capturing of user needs.
Functional specification – definition of functions required to meet user needs.
Technical specification – technical design of functions identified in the functional specification.
Program specification – detailed design of each module or unit to be built to meet required functionality.
Program specification reviewed to check the following:
- Conformance to the previous work-product
- That there is sufficient detail for the subsequent work-product to be built correctly
- That it is testable
Iterative-incremental development models
A working version of the product is built in a series of iterations. Also, referred to as cyclical.
Cycles referred to as time-boxes. After the time-box a decision is made on what extra functionality needs to be created for the next iteration.
- Involvement of user representatives in the testing
- Lack of formal documentation. Test-driven development is used to counter this.
- Developers make any changes required without formally recording them.Changes may not be traced back. Traceability is reduced.
- Another issue associated is the amount of regression testing required.
- Prototyping, RAD, Agile software development
- A proprietary methodology is the Rational Unified Process (RUP)
Verification ensuring the work-products are being developed in the right way.
Validation ensures the product meets the users needs
Characteristics of good testing across the development life cycle:
- Early test design
- Each work product is tested
- Testers are involved in reviewing requirements before they are released
Unit (component) testing
Code is written before testing can start. It is written in units (also called programs, modules or components). Unit testing is intended to ensure that that code written for the unit meets its specification prior to integration with other units.
Unit testing would verify that all of the code that has been written for the unit can be executed.
Test bases for unit testing:
- Component requirements
- The detailed design
- The code
- Data conversion/migration programs
- Database modules
Unit testing approach example: Test Driven Development
Test Driven Development is an iterative approach. Tested by the developer. Defects found and fixed during unit testing are often not recorded.
To expose defects in the interfaces and in the interactions between integrated components or systems.
Common integration strategies:
Big-bang integration – when all units are linked at once
Top-down integration – when systems is built in stages starting with components that call other components.
Components that call others are usually placed above those that are called.
Bottom-up integration – opposite of top-down integration and the components are integrated in a bottom-up order.
Checking functionality from end-to-end perspective. Non-functional testing occurs have:
- Load handling
- Stress handling
All of these can be carried out by an independent team
To provide end users with confidence that the system will function according to their expectations.
Carried out by customers or users of a system.
Typical forms of acceptance testing:
- User acceptance testing
- Operational acceptance testing
- Contract and regulation acceptance testing
- Alpha + beta testing
Functional testing also called specification-based testing: testing against a specification.
Non-functional testing Is testing the behavioural aspects of the system. Black box techniques usually used.
Structural testing is used to measure how much testing has been carried out.
Retesting (Confirmation testing) Testing a fix from a defect after the system has changed.
Regression testing may also be involved to ensure the fix has not impacted on other aspects of the system.
Testing which takes place on a system which is in operation in the live environment.
Type of testing that can be involved: