Getting Restarted With Software Testing: Part 3
Source: Dev.to
If you haven’t read Part 1 yet, you can read it here:
Getting Restarted with Software Testing – Part 2
“Test Scenarios vs Test Cases: What’s the difference and why does it matter?”
1. Test Scenarios
A test scenario is a high‑level description of what needs to be tested.
It represents a real‑world use case or business flow of the application.
Example – We have a web application.
Test Scenario
- Verify user login functionality
From this single scenario, multiple test cases can be derived:
- Login with valid credentials
- Login with invalid password
- Login with invalid username
- Login with empty fields
- Login with locked account
2. Test Cases
A test case details the step‑by‑step process to perform and validate a specific piece of functionality.
Key Components of a Test Case
| Component | Description |
|---|---|
| Test Case ID | Unique identifier (e.g., TC001) |
| Test Description / Title | Short description of what is being tested (e.g., “Verify login functionality with valid credentials.”) |
| Preconditions | Conditions that must be met before execution (e.g., “User must be registered in the system.”) |
| Test Steps | Step‑by‑step instructions (see example below) |
| Test Data | Input data required for the test (e.g., username = user1, password = Pass@123) |
| Expected Result | What the system should do after executing the steps (e.g., “User should be redirected to the dashboard.”) |
| Actual Result | What actually happened (filled after execution) |
| Status | Pass / Fail |
| Remarks | Optional comments, bugs, or observations |
Example Test Case
Test Case ID: TC001
Title: Verify login functionality with valid credentials
Preconditions: User must be registered in the system
Test Steps:
1. Open the login page
2. Enter valid username (e.g., validuser)
3. Enter valid password (e.g., validpassword123)
4. Click the login button
Test Data:
username = validuser
password = validpassword123
Expected Result: User is redirected to the dashboard
Actual Result: (filled after execution)
Status: Pass / Fail
Remarks: (optional)3. Positive vs. Negative Test Cases
3.1 Positive Test Cases
A positive test case uses valid input and verifies that the system behaves as intended.
Example – Verify user login with valid credentials
| Step | Action |
|---|---|
| 1 | Open the login page |
| 2 | Enter a valid username (e.g., validuser) |
| 3 | Enter the correct password (e.g., validpassword123) |
| 4 | Click the login button |
Expected Outcome: The user is successfully logged in and redirected to the homepage/dashboard.
3.2 Negative Test Cases
A negative test case uses invalid input to ensure the system handles errors gracefully.
Example – Verify user login with invalid credentials
| Step | Action |
|---|---|
| 1 | Open the login page |
| 2 | Enter an invalid username (e.g., invaliduser) |
| 3 | Enter an incorrect password (e.g., wrongpassword) |
| 4 | Click the login button |
Expected Outcome:
- An error message such as “Invalid username or password.” is displayed.
- The user remains on the login page and is not logged in.
4. What Is a Bug in Software Testing?
A bug (or defect) is a flaw or deviation in a software application that causes it to produce incorrect or unexpected results, or to behave in ways it was not designed to.
Example Bugs
| Type | Description | Expected Behavior | Actual Behavior |
|---|---|---|---|
| UI Bug | Text on a button in an e‑commerce site is not aligned properly. | Text should be centered on the button. | Text is pushed to the left side of the button. |
| Functional Bug | Users cannot log in even with correct credentials. | After entering correct credentials, users should be logged in and redirected to the homepage. | After submitting valid credentials, an error “Invalid username or password.” is shown. |
| Performance Bug | Webpage takes > 30 seconds to load a product list. | The product page should load within 5 seconds. | The page loads in more than 30 seconds. |
5. Bug Life Cycle
The bug life cycle describes the stages a defect goes through from discovery to closure.
Stages
- New – Bug identified but not yet analyzed.
- Assigned – A developer or team is assigned to fix the bug.
- Open – The bug is being worked on.
- Fixed – Development team has fixed the issue.
- Retest – Testing team verifies that the fix resolves the problem.
- Closed – Bug is confirmed fixed and closed.
- Reopened – If the issue persists after the first fix, it is reopened for further investigation.
6. Common Bug Statuses
Bug statuses indicate the current state of a defect within its life cycle.
| Status | Meaning |
|---|---|
| New | Defect discovered for the first time; not yet reviewed. |
| Open | Defect reviewed and accepted; assigned to a developer. |
| Assigned | Specifically assigned to a developer (duplicate of “Open” in some tools). |
| In Progress | Developer is actively working on the fix. |
| Fixed | Development has implemented a fix. |
| Retest | QA is testing the fix. |
| Closed | Defect verified as fixed and closed. |
| Reopened | Fix was insufficient; defect reopened for further work. |
Additional Lifecycle Statuses
| Status | Description |
|---|---|
| Pending Retest | Fix is deployed to the test environment; waiting for tester verification. |
| Verified | Tester confirms the bug is fixed successfully. |
| Rejected | Bug is not valid (works as designed or not reproducible). |
| Duplicate | Bug already exists in the system. |
| Deferred | Bug fix is postponed to a future release. |
| Not a Bug | Reported issue is expected system behavior. |
| Cannot Reproduce | Developer or tester cannot reproduce the issue. |
| On Hold | Work paused due to dependency or missing information. |
| Won’t Fix | Bug acknowledged but will not be fixed due to low impact. |
7. Bug Severity in Software Testing
Severity indicates the impact of a defect on the software from a technical standpoint. It measures how serious the defect is.
Bug Severity Levels
| Severity | Description | Example |
|---|---|---|
| Critical / Blocker | System crashes or becomes unusable; testing cannot continue. | Application crashes on launch; server down. |
| Major / High | Major functionality is broken; no workaround available. | Login not working; payment processing fails. |
| Medium / Moderate | Partial functionality issue; a workaround exists. | Search works but filters fail. |
| Low / Minor | Minor issue with minimal impact; cosmetic or UI problems. | Button misalignment; font inconsistency. |
8. Bug Priority in Software Testing
Priority indicates how urgently a defect needs to be fixed. It helps the team decide which defects to address first, based on business impact and timelines.
Bug Priority Levels
| Priority | Description | Example |
|---|---|---|
| High Priority | Must be fixed immediately; affects critical business functionality. | Payment button not working; app crashes during checkout. |
| Medium Priority | Should be fixed, but not immediately; core functionality works with workarounds. | Profile update works but shows a warning message. |
| Low Priority | Can be fixed later; minor impact on user experience. | UI alignment issue. |
9. Roles and Responsibilities of a Software Tester
A software tester ensures that a product works correctly, meets requirements, and is free of defects.
Roles of a Software Tester
- Quality Assurance Role – Ensures the software meets quality standards and user expectations.
- Defect Identifier – Finds bugs, errors, and missing features.
- Requirement Validator – Checks whether the software matches the given requirements and specifications.
- User Advocate – Considers the end‑user’s perspective to ensure good usability and functionality.
- Team Collaborator – Works closely with developers, designers, and managers to improve the product.
Responsibilities of a Software Tester
- Understanding Requirements – Study software requirements, designs, and use cases carefully.
- Test Planning – Create test plans and decide what, how, and when to test.
- Test Case Design – Write test cases and test scenarios based on requirements.
- Test Execution – Run manual or automated tests to check software behavior.
- Defect Reporting – Identify, document, and report bugs clearly using defect‑tracking tools.
- Regression Testing – Re‑test after fixes to ensure new changes don’t break existing features.
- Performance & Security Testing – Check speed, stability, and basic security aspects (when required).
- Test Documentation – Maintain test cases, test reports, and test results.
- Automation (if applicable) – Develop and maintain automated test scripts.
- Continuous Improvement – Suggest improvements in testing processes and product quality.
Conclusion
From understanding SDLC/STLC and testing types to identifying defects, software testing ensures every product is reliable and user‑friendly. Testers play a crucial role in maintaining quality and bridging the gap between development and users. Effective testing is the key to delivering software that truly works.