A test level according to the ISTQB glossary is "a group of testing activities that are organised and managed together. A test level is linked to the responsibilities in a project."
Component testing:
- is the lowest level of testing: it's focused on detailed design and code and is aimed to find defects.
- its test cases are prepared before the code is written.
- it's performed on separated or independent modules, programs, classes that could be tested independently with the use of stubs (replacing a called component) and drivers (calling/launching the component which we want to test) and simulators.
- it can be functional, non functional (robustness, performance) or structural (decision coverage of a flow).
- it's performed usually with the support of development environment and access to the code, so it's used in highly iterative approach. (like in Extreme Programming model). This doesn't necessarily require defects to be formally recorded because they are fixed a soon as they are found by the developer.
- it's well suited for automated testing because test-driven development will use a unit test framework to execute tests prepared before the coding activities.
- it aims to expose defects in the interfaces and interactions between integrated components or systems and is carried out respectively after component testing or system testing. (functional tasks, transactions).
- the test basis used are: workflow, use cases, software/system design, architecture.
- it should be verifying and validating information (functional or not) passing between components (format, data), the order in how component are communicating.
- it can involve systems outside the organisation and need to have a common and global agreement. An incremental approach based on system architecture is advisable to manage a large numbers of components/systems (with different versions)and make easier to isolate defects. A non incremental approach (or big bang) has consequently to be avoided.
- it can follow a top-down approach: testing starts with the top of the component hierarchy, lower level components are simulated by stubs.
- it can follow a bottom-up approach which is the opposite of top-down approach: drivers replace higher level component needed.
- it should be planned earlier as possible as it's tightly related to development order.
- includes functional and non functional testing (performance, reliability..).
- verifies that an integrated system/process meets specified requirements which could be documented or not.
- involves independent test team to use as test basis : use cases, system/software requirement specification, business processes and risk analysis.
- need a like-live environment (hardware, software, tools..) before being carried out.
- black box test technique validates the functionality with regards to its specification without access or refers to the code. White box or structured-based technique takes in account the code coverage.
- it verifies user needs, product/system requirements, and business processes. They have all to satisfy acceptance criteria set with involved customers and/or stakeholders.
- it aims to assess the global system for its deployment and final use, and is often carried out after large-scale system integration or as a single test level for a COTS software product for example.
- it's divided between user acceptance testing (fitness for use by business users) and operational acceptance testing (backup, restore, disaster recovery, user management, maintenance tasks, migration or data loads, security policy).
- it can be performed for contract acceptance: testing is performed against acceptance criteria agreed in a contract or for regulation acceptance: testing is performed against any legal or regulation from Government Authority.
- it can include alpha testing involving potential users outside the organisation within operational environment before be finally deployed and sold.
- it can include beta (or field) testing and in that case, it's carried out by users from the same organisation.
No comments:
Post a Comment