Chapter 2: Testing Throughout the Software Development Lifecycle Flashcards
Impact of the Software Development Lifecycle on Testing
The choice of the SDLC impacts on the:
* Scope and timing of test activities (e.g., test levels and test types)
* Level of detail of test documentation
* Choice of test techniques and test approach
* Extent of test automation
* Role and responsibilities of a tester
in the initial phases testers typically participate in requirement
reviews, test analysis, and test design
sequential development models
assumes that change may occur throughout the project
Agile software development
it is assumed that each iteration delivers a
working prototype or product increment.
iterative and incremental development models
Good Testing Practices
- For every software development activity, there is a corresponding test activity
- Different test levels have specific and different test objectives
- Test analysis and design for a given test level begins during the corresponding development phase of the SDLC, so that testing can adhere to the principle of early testing
- Testers are involved in reviewing work products as soon as drafts of this documentation are available
Directs the coding through test cases
Tests are written first, then the code is written to satisfy the tests
Test-Driven Development (TDD):
Derives tests from acceptance criteria as part of the system design process
Tests are written before the part of the application is developed to satisfy the tests
Acceptance Test-Driven Development (ATDD)
Expresses the desired behavior of an application with test cases written in a simple form of natural language, which is easy to understand by stakeholders – usually using the Given/When/Then format.
Behavior-Driven Development (BDD):
The principle of early testing
Shift-Left Approach
Good practices for Shift-Left Approach
- Reviewing the specification from the perspective of testing -ambiguities, incompleteness, and inconsistencies
- Writing test cases before the code is written and have the code run in a test harness during code implementation
- Using CI and even better CD as it comes with fast feedback and automated component tests
- Completing static analysis of source code prior to dynamic testing, or as part of an automated process
- Performing non-functional testing starting at the component test level, where possible.
also known as “post-project meetings” and project retrospectives)
Retrospectives
benefits of Retro for testing
- Increased test effectiveness / efficiency (e.g., by implementing suggestions for process improvement)
- Increased quality of testware (e.g., by jointly reviewing the test processes)
- Team bonding and learning (e.g., as a result of the opportunity to raise issues and propose improvement points)
- Improved quality of the test basis (e.g., as deficiencies in the extent and quality of the requirements could be addressed and solved)
- Better cooperation between development and testing (e.g., as collaboration is reviewed and optimized regularly)
Test Levels
Component testing
Component integration testing
System testing
System integration testing
Acceptance testing
(also known as unit testing) focuses on testing components in isolation. It often requires specific support, such as test harnesses or unit test frameworks.
Component testing is normally performed by developers in their development environments.
(also known as unit integration testing) focuses on testing the
interfaces and interactions between components.
Component integration testing is heavily dependent on the integration strategy approaches like bottom-up, top-down or big-bang.
focuses on the overall behavior and capabilities of an entire system or product
System testing may be performed by an independent test team, and is related to specifications for the system.
focuses on testing the interfaces of the system under test and other
systems and external services .
System integration testing requires suitable test environments
preferably similar to the operational environment.
focuses on validation and on demonstrating readiness for deployment, which means that the system fulfills the user’s business needs
Acceptance testing should be performed by the intended users.
The main forms of acceptance testing are: user acceptance
testing (UAT), operational acceptance testing, contractual and regulatory acceptance testing, alpha testing and beta testing.
Test levels are distinguished by the following non-exhaustive list of attributes
- Test object
- Test objectives
- Test basis
- Defects and failures
- Approach and responsibilities
evaluates the functions that a component or system should perform
Functional testing
The functions are “what” the test object should do.
The main objective of functional testing is checking the functional
completeness, functional correctness and functional appropriateness.
evaluates attributes other than functional characteristics of a component or system.
Non-functional testing is the testing of “how well the system behaves”.
The main objective of nonfunctional testing is checking the non-functional software quality characteristics.
classification of the non-functional software quality characteristics:
- Performance efficiency
- Compatibility
- Usability
- Reliability
- Security
- Maintainability
- Portability
is specification-based and derives tests from documentation external
to the test object.
Black-box testing
The main objective of black-box testing is checking the system’s behavior against its specifications.
is structure-based and derives tests from the system’s
implementation or internal structure (e.g., code, architecture, work flows, and data flows).
White-box testing
The main objective of white-box testing is to cover the underlying structure by the tests to the acceptable level.
confirms that an original defect has been successfully fixed.
Confirmation testing
Depending on the risk, one can test the fixed version of the software in several ways, including
- executing all test cases that previously have failed due to the defect
- adding new tests to cover any changes that were needed to fix the defect
confirms that no adverse consequences have been caused by a change, including a fix that has already been confirmation tested.
Regression testing
can involve planned releases/deployments and unplanned releases/deployments (hot fixes
maintenance
scope of maintenance testing
- The degree of risk of the change
- The size of the existing system
- The size of the change
The triggers for maintenance and maintenance testing can be classified as follows:
- Modifications, such as planned enhancements (i.e., release-based), corrective changes or hot fixes.
- Upgrades or migrations of the operational environment
- Retirement, such as when an application reaches the end of its life.
