Please enable JavaScript.
Coggle requires JavaScript to display documents.
Module 5: Software Testing - Coggle Diagram
Module 5: Software Testing
Defination
compare actiual vs expected results
Method: Manual and automation
Functional Testing (Black-Box)
Boundary Value Analysis
Boundary Value Analysis: test values at the edges (boundaries) of input ranges.
Example: Age must be 18–60
Test: 17, 18, 19 and 59, 60, 61
Decision Table Technique
Decision Table Technique: test different combinations of conditions and their outcomes.
Equivalence partitionating
Equivalence Partitioning: divide inputs into groups that behave the same, and test one value from each group.
Example: Age must be 18–60
<18 → test 15 (invalid)
18–60 → test 30 (valid)
60 → test 70 (invalid)
Cause and effect graph
Cause and Effect Graph: shows how input conditions (causes) lead to outputs (effects), then helps design test cases.
Characteristics
High probability of detecting errors
To detect maximum errors, the tester should understand the software thoroughly and try to find the possible ways in which the software can fail
No redundancy
Resources and testing time are limited in software development process. Thus, it is not beneficial to develop several tests, which have the same intended purpose. Every test should have a distinct purpose.
Moderate complexity
A test is considered good if it is neither too simple, nor too complex. Many tests can be combined to form one test case. However, this can increase the complexity and leave many errors undetected. Hence, all tests should be performed separately.
Choose the most appropriate test
There can be different tests that have the same intent but due to certain limitations such as time and resource constraint, only few of them are used. In such a case, the tests, which are likely to find more number of errors, should be considered.
Non- Functional Testing (White Box)
Path testing
Data flow testing
Mutation Testing
Decision Mutation
Statement Testing
Value Mutation
Loop and condition Testing
Example
Levels of testing
A) Unit testing
Individual components
Individual Components (Component Testing): testing each part of a system separately to ensure it works correctly.
Test a login module alone (username/password check) before integrating it with the full app.
White box technique
White Box Technique: testing based on the internal code and logic of the program.
B) Integration testing
Combined modules group
Combined Modules Group (Integration Testing): testing multiple components together to ensure they work correctly as a group.
Example:
Test login + database together to check if user data is correctly retrieved and validated.
Black box or White box
Black Box Testing: test functionality without knowing the internal code
Example: check if login works with valid/invalid inputs
White Box Testing: test internal logic and code structure
Example: test all branches in login code (if/else paths)
C) System testing
Complete integrates system
Complete Integrated System (System Testing): testing the whole system together to check if all parts work as one complete application.
Example:
Test an entire banking app—login, transfer money, check balance, and logout—all working together correctly.
Black box technique
Black Box Technique: testing the system based on inputs and outputs, without knowing the internal code.
Example:
Enter valid and invalid login details to check if the system responds correctly (success or error).
D) Acceptance testing
User requirements verification
User Requirements Verification (Acceptance Testing): checking if the system meets the user’s needs and requirements.
Example:
Users test an app to confirm it can transfer money, show balance, and perform all needed features correctly.
Aplha, beta, Gamma
Alpha Testing: done inside the company by developers/testers before release.Example: testing a new app version in-house.
Beta Testing: done by real users before final release.Example: users try the app and report bugs.
Gamma Testing: final testing after beta, just before full release (less common term).Example: final check to ensure no major issues remain.
Release testing stage
A)Alpha testing
Internal Testing
Internal Testing: testing done by the development team inside the company before releasing the product.
Example:
Developers test a new app feature to find bugs before giving it to users.
Development/QATeam
Development / QA Team Testing: testing done by developers and QA (Quality Assurance) team during development to find and fix bugs early.
Example:
Developers and QA testers check a new login feature to ensure it works correctly before release.
B)Beta Testing
External User
External User Testing: testing done by real users outside the development team to check how the system works in real use.
Example:
Customers use a new app and report bugs or issues during beta testing.
Pre release Testing
Pre-release Testing: final testing done just before releasing the product to ensure everything works correctly.
Example:
Check a mobile app for last bugs, performance, and features before launching it to users.
C)Gamma Testing
Final stage before testing
Final Stage Before Testing (Test Planning / Test Preparation): preparing everything needed for testing before it actually starts.
Example:
Writing test cases, setting up test data, and preparing the testing environment before testing an app.
Market readiness check
Market Readiness Check: final check to see if a product is ready to be released to the market.
It confirms things like quality, performance, and user needs are met.
Example:Before launching an app, the team checks if it is stable, bug-free, and ready for users to download.
