Getting Restarted With Software Testing: Part 3

This is Part 3 of our Software Testing series.
If you haven’t read Part 1 yet, you can read it here:
https://dev.to/software_testing_blog/getting-restarted-with-software-testing-part-2-3oc2

"Test Scenarios vs Test Cases: What’s the difference and why does it matter?"

Test scenarios is what to be tested and testcases is how to be tested.

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.
For 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

Writing test scenarios in detail or step by step process to perform and validate the functionality of the software.

Key Components of a Test Case:-

• Test Case ID:
  Unique identifier for the test case.
  Example: TC001

• Test Description / Title:
  Short description of what is being tested.
  Example: “Verify login functionality with valid credentials.”

• Preconditions:
  Conditions that must be met before executing the test case.
  Example: “User must be registered in the system.”

• Test Steps:
  Step-by-step instructions to execute the test.
  Example:
  Open the login page
  Enter valid username and password
  Click on login button

• Test Data:
  Input data required for the test.
  Example: username = user1, password = Pass@123

• Expected Result:
  What the system should do after executing the steps.
  Example: “User should be redirected to the dashboard.”

• Actual Result (filled after execution):
  What actually happened when the test was executed.

• Status: Pass-Fail
  Indicates if the test case passed or failed.

• Remarks: Comments (optional)
  Any additional information, bugs, or observations.

Positive vs Negative Test Cases: What’s the difference and why are both needed?

1. Positive Testcases

A positive test case is a test scenario where the input is valid, and the system is expected to behave as intended. The goal of positive testing is to ensure that the software works correctly when used as expected.

Positive Test Case Example:
Test Case: Verify user login with valid credentials.

• Test Steps:
  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.

2. Negative Testcases

A negative test case is a test scenario where the input is invalid, and the system is expected to handle the error or reject the input gracefully. The goal of negative testing is to verify that the software can handle unexpected or incorrect input without crashing and that it provides appropriate error messages or feedback.

Negative Test Case Example:
Test Case: Verify user login with invalid credentials.

• Test Steps:
  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:
  • The system should display an error message, such as "Invalid username or password."
  • The user is not logged in and remains on the login page.

What is bug in a software testing ?

Bug represent the flaw or deviation in the software application that causes it to produce incorrect or unexpected results or to behave in ways that it was not designed to.

Example 1: UI Bug (User Interface)

Description: The text on a button in an e-commerce website is not aligned properly.

Expected behavior: The text should be centered on the button.
Actual behavior: The text is pushed to the left side of the button.

Example 2: Functional Bug (Login Issue)

Description: Users cannot log in even though they enter the correct credentials.

Expected behavior: After entering correct credentials, users should be able to log in and be redirected to the homepage.
Actual behavior: After submitting valid credentials, the user is shown an error message saying "Invalid username or password."

Example 3: Performance Bug (Slow Loading)

Description: The webpage takes more than 30 seconds to load a list of products.

Expected behavior: The product page should load within 5 seconds.
Actual behavior: The product page takes a lot longer to load (more than 30 seconds).

What is a bug life cycle ?

It involves several stages where the bug is tracked, managed, and resolved, ensuring that it is fixed in the software before release.

Stages of bug life cycle:-

1. New: A bug has been identified but is not yet analyzed.
2. Assigned: A developer or team has been assigned to fix the bug.
3. Open: The bug is being worked on.
4. Fixed: The issue has been fixed by the development team.
5. Retest: The testing team verifies if the fix resolves the issue.
6. Closed: The bug is confirmed fixed, and the issue is resolved.
7. Reopened: If the issue is not fixed after the first attempt, it is reopened for further investigation.

Define bug statuses in a software testing

In software testing, bug (defect) statuses show the current state of a bug in its life cycle—from discovery to closure.

Common Bug Statuses:-

1. New

• Find the defect for the first time.
• Not yet reviewed by the development team.

2. Open

• Bug has been reviewed and accepted.
• Assigned to a developer for fixing.

3. Assigned

• Bug is specifically assigned to a developer.
• Bug is specifically assigned to a developer.

4. In Progress

• Developer is actively working on fixing the bug. 5. Fixed
• Bug has been resolved by the developer.
• Code changes completed and ready for testing.

6. Pending Retest

• Fix is deployed to the test environment.
• Waiting for tester verification.

7. Retest

• Tester is re-executing test cases to verify the fix.

8. Verified
-Tester confirms the bug is fixed successfully.

9. Closed
-Bug is fixed and no further action is required.

Rejection / Alternate Statuses:-

1. Rejected

• Bug is not valid (works as designed or not reproducible).

2. Duplicate

• Bug already exists in the system.

3. Deferred

• Bug fix is postponed to a future release.

4. Not a Bug

• Reported issue is expected system behavior.

5. Cannot Reproduce

• Developer or tester cannot reproduce the issue.

Special / Advanced Statuses:-
1. Reopened

• Bug reappears after being marked fixed or closed.

2. On Hold

• Work paused due to dependency or missing information.

3. Won’t Fix

• Bug acknowledged but will not be fixed due to low impact.

What is bug severity in a software testing ?

Severity indicates the impact of the defects on any software application. It measures how serious the defect is from a technical point of view.

Bug Severity Levels:-
1. Critical / Blocker

• System crashes or becomes unusable
• Testing cannot continue
• Example:
  • Application crashes on launch
  • Server down

2. Major / High

• Major functionality is broken

• No workaround available

• Example:

  • Login not working
  • Payment processing fails

3. Medium / Moderate

• Partial functionality issue
• Workaround exists
• Example:
  • Search works but filters fail

4. Low/Minor

• Minor issue with minimal impact
• Cosmetic or UI issues
• Example:
  • Button misalignment
  • Font inconsistency

What is bug priority in a software testing?

Defect priority indicates how urgently a defect needs to be fixed. It helps the team decide which defects should be addressed first, based on business impact and timelines.

** Bug Priority Levels:-**
1. High Priority

• Must be fixed immediately
• Affects critical business functionality Example:
  • Payment button not working
  • App crashes during checkout

2. Medium Priority

• Should be fixed, but not immediately
• Core functionality works with workarounds
• Example: -Profile update works but shows a warning message

3. Low Priority

• Can be fixed later
• Minor impact on user experience
• Example: -UI alignment issue

Define roles and responsibilities of a software tester

A software tester is responsible for making sure a software product works correctly, meets requirements, and it is free of defects.

Roles of a Software Tester:-

1. Quality Assurance Role
Ensures the software meets quality standards and user expectations.
2. Defect Identifier
Finds bugs, errors, and missing features in the software.
3. Requirement Validator
Checks whether the software matches the given requirements and specifications.
4. User Advocate
Thinks from the end-user’s point of view to ensure good usability and functionality.
5. Team Collaborator
Works closely with developers, designers, and managers to improve the product.

Responsibilities of a Software Tester:-

1. Understanding Requirements
Study software requirements, designs, and use cases carefully.

2. Test Planning
Create test plans and decide what, how, and when to test.

3. Test Case Design
Write test cases and test scenarios based on requirements.

4. Test Execution
Run manual or automated tests to check software behavior.

5. Defect Reporting
Identify, document, and report bugs clearly using defect tracking tools.

6. Regression Testing
Re-test the software after fixes to ensure new changes don’t break existing features.

7. Performance and Security Testing
Check speed, stability, and basic security aspects (when required).

8. Test Documentation
Maintain test cases, test reports, and test results.

9. Automation (if applicable)
Develop and maintain automated test scripts.

10. 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. In the end, effective testing is the key to delivering software that truly works.