General Test Scenarios: A Comprehensive Guide
Key Takeaways
- General test scenarios are essential for ensuring application quality and reliability
- These scenarios cover common functionalities and edge cases that testers should validate
- Proper test scenarios help identify potential issues early in the development cycle
- Following a structured approach to testing improves efficiency and coverage
In software testing, general test scenarios play a critical role in ensuring that an application meets functional, usability, and performance standards. These scenarios cover a wide range of common functionalities and edge cases that testers should validate to ensure the software is robust, user-friendly, and error-free.
In this blog post, we'll explore general test scenarios that every QA engineer should consider when testing web or mobile applications. These scenarios are designed to address common issues, enhance user experience, and prevent potential bugs. We'll also include additional test cases to provide a more comprehensive guide.
Detailed Test Scenarios
Validation Scenarios
Mandatory Field Validation
Description: All mandatory fields should be validated and indicated by an asterisk (*) symbol.
Test Steps:
- Open the form page
- Identify all mandatory fields
- Leave mandatory fields blank
- Submit the form
Expected Result: Error messages are displayed for all mandatory fields, and fields with errors are highlighted.
Error Message Positioning
Description: Validation error messages should be displayed properly at a correct position.
Test Steps:
- Open the form page
- Enter invalid data in a field
- Submit the form
Expected Result: Error message appears next to the invalid field and provides meaningful feedback.
UI Consistency
Error Message Styling
Description: All error messages should be displayed in the same CSS style (e.g., red color).
Test Steps:
- Trigger multiple validation errors on a page
- Observe the styling of error messages
Expected Result: All error messages are styled consistently (e.g., red color, bold font).
Confirmation Message Styling
Description: General confirmation messages should be displayed using CSS style other than error messages style.
Test Steps:
- Perform an action that triggers a confirmation message
- Observe the styling of the confirmation message
Expected Result: Confirmation message is styled differently (e.g., green color) and visually distinct from error messages.
Tooltips
Tooltip Content
Description: Tooltips text should be meaningful.
Test Steps:
- Hover over fields or buttons with tooltips
- Observe the tooltip text
Expected Result: Tooltip displays clear and concise information related to the field or button.
Dropdown Fields
Default Selection
Description: Drop-down fields should have the first entry as blank or text like 'Select'.
Test Steps:
- Open a form with dropdown fields
- Observe the default value of each dropdown
Expected Result: The dropdown's first entry is blank or displays placeholder text like 'Select'.
Delete Functionality
Delete Confirmation
Description: 'Delete functionality' for any record should ask for confirmation.
Test Steps:
- Navigate to a page with records
- Click the delete button for a record
Expected Result: A confirmation dialog appears before deleting the record.
Bulk Operations
Select All Functionality
Description: Select/deselect all records option should be provided for bulk operations.
Test Steps:
- Navigate to a page with records
- Check for 'Select/Deselect All' checkbox
- Test select/deselect functionality
Expected Result: The 'Select/Deselect All' checkbox works correctly and applies actions to all selected records.
Currency Formatting
Currency Display
Description: Amount values should be displayed with correct currency symbols.
Test Steps:
- Navigate to a page displaying amount fields
- Observe the formatting of amount values
Expected Result: Amount is displayed as "$1,000.00" with the correct currency symbol.
Sorting
Default Sorting
Description: Default page sorting should be provided.
Test Steps:
- Open a page with sortable data
- Observe the initial sorting order
Expected Result: The page loads with data sorted by the default column in ascending order.
Numeric Formatting
Number Display
Description: All numeric values should be formatted properly.
Test Steps:
- Navigate to a page displaying numeric values
- Observe the formatting of numbers
Expected Result: Number is displayed as "1,000,000" with proper formatting.
Max Field Value
Field Limit Validation
Description: Input fields should be checked for the max field value.
Test Steps:
- Enter a value exceeding the max limit
- Submit the form
Expected Result: The input is rejected, and an error message is displayed.
Special Characters
Character Validation
Description: Check all input fields for special characters.
Test Steps:
- Enter special characters in various fields
- Submit the form
Expected Result: Special characters are rejected or sanitized, and an appropriate validation message is displayed.
Field Labels
Label Standards
Description: Field labels should be standard and descriptive.
Test Steps:
- Open a form page
- Review field labels
Expected Result: Field labels are descriptive and consistent across the application.
Sorting After CRUD
Sort Persistence
Description: Check page sorting functionality after add/edit/delete operations.
Test Steps:
- Add, edit, or delete a record
- Observe the sorting behavior
Expected Result: Sorting remains consistent after adding, editing, or deleting records.
Timeout
Session Timeout
Description: Check for timeout functionality.
Test Steps:
- Log in to the application
- Wait for the session timeout period
- Attempt to perform an action
Expected Result: Application redirects to the login page or displays a timeout message.
Downloadable Files
File Download
Description: Check if downloadable files are pointing to the correct file paths.
Test Steps:
- Click on a download link
- Verify the file opens/downloads correctly
Expected Result: The file downloads successfully and matches the expected content.
Resource Keys
External Configuration
Description: All resource keys should be configurable in config files or databases.
Test Steps:
- Open the application
- Verify that text strings are stored externally
Expected Result: Text strings are retrieved dynamically from external sources.
Naming Conventions
Key Naming
Description: Standard conventions should be followed for naming resource keys.
Test Steps:
- Review resource keys in config files
- Verify adherence to naming standards
Expected Result: Resource keys follow a consistent naming convention.
HTML/CSS Validation
Markup Validation
Description: Validate markup for all web pages.
Test Steps:
- Use tools like W3C Validator
- Check for syntax errors
Expected Result: No syntax errors are found in HTML and CSS.
Error Redirection
Error Page Handling
Description: Application crash or unavailable pages should be redirected to an error page.
Test Steps:
- Simulate a crash or access an unavailable page
- Observe redirection behavior
Expected Result: The user is redirected to a custom error page with a friendly message.
Spelling/Grammar
Text Accuracy
Description: Check text on all pages for spelling and grammatical errors.
Test Steps:
- Review all visible text on the application pages
- Proofread for accuracy
Expected Result: Text is free of spelling and grammatical errors.
Numeric Input
Character Input Validation
Description: Check numeric input fields with character input values.
Test Steps:
- Enter alphabetic characters in a numeric field
- Submit the form
Expected Result: An error message is displayed for non-numeric input.
Negative Numbers
Negative Value Handling
Description: Check for negative numbers if allowed for numeric fields.
Test Steps:
- Enter a negative number in a numeric field
- Submit the form
Expected Result: If allowed, the value is accepted; otherwise, an error message is displayed.
Decimal Numbers
Decimal Value Handling
Description: Check amount fields with decimal number values.
Test Steps:
- Enter a decimal number in an amount field
- Submit the form
Expected Result: The value is accepted and displayed with proper formatting.
Double Submission
Multiple Submissions
Description: The user should not be able to submit a page twice by pressing the submit button in quick succession.
Test Steps:
- Rapidly click the submit button multiple times
- Observe the result
Expected Result: The form is submitted only once, and subsequent clicks are ignored.
Divide by Zero
Division Error Handling
Description: Divide by zero errors should be handled for any calculations.
Test Steps:
- Perform a calculation involving division by zero
- Observe the application behavior
Expected Result: An appropriate error message is displayed.
Leading/Trailing Blanks
Space Handling
Description: Input data with the first and last position blank should be handled correctly.
Test Steps:
- Enter values with leading/trailing spaces
- Submit the form
Expected Result: Spaces are trimmed, and the value is processed correctly.
| Category | Description | Test Steps | Condition | Test Data | Expected Result |
|---|---|---|---|---|---|
| Validation | All mandatory fields should be validated and indicated by an asterisk (*) symbol. | 1. Open the form page. 2. Identify all mandatory fields. 3. Leave mandatory fields blank. 4. Submit the form. |
Mandatory fields must have an asterisk (*) symbol next to them. | N/A | Error messages are displayed for all mandatory fields, and fields with errors are highlighted. |
| Validation | Validation error messages should be displayed properly at a correct position. | 1. Open the form page. 2. Enter invalid data in a field. 3. Submit the form. |
Error messages should appear near the relevant fields. | Invalid data: "abc" in numeric field | Error message appears next to the invalid field and provides meaningful feedback. |
| UI Consistency | All error messages should be displayed in the same CSS style (e.g., red color). | 1. Trigger multiple
validation errors on a page. 2. Observe the styling of error messages. |
Error messages should follow consistent styling. | N/A | All error messages are styled consistently (e.g., red color, bold font). |
| UI Consistency | General confirmation messages should be displayed using CSS style other than error messages style. | 1. Perform an action that
triggers a confirmation message. 2. Observe the styling of the confirmation message. |
Confirmation messages should differ from error messages. | Success message: "Record saved successfully." | Confirmation message is styled differently (e.g., green color) and visually distinct from error messages. |
| Tooltips | Tooltips text should be meaningful. | 1. Hover over fields or
buttons with tooltips. 2. Observe the tooltip text. |
Tooltip text must provide meaningful information. | Tooltip text: "Enter your first name here." | Tooltip displays clear and concise information related to the field or button. |
| Dropdown Fields | Drop-down fields should have the first entry as blank or text like 'Select'. | 1. Open a form with dropdown
fields. 2. Observe the default value of each dropdown. |
The first entry should be blank or display placeholder text. | Dropdown options: ['Select', 'Option 1', 'Option 2'] | The dropdown's first entry is blank or displays placeholder text like 'Select'. |
| Delete Functionality | 'Delete functionality' for any record should ask for confirmation. | 1. Navigate to a page with
records. 2. Click the delete button for a record. |
Delete operation must trigger a confirmation dialog. | N/A | A confirmation dialog appears before deleting the record. |
| Bulk Operations | Select/deselect all records option should be provided for bulk operations. | 1. Navigate to a page with
records. 2. Check for 'Select/Deselect All' checkbox. 3. Test select/deselect functionality. |
Page supports bulk operations. | Checkbox: Select All | The 'Select/Deselect All' checkbox works correctly and applies actions to all selected records. |
| Currency Formatting | Amount values should be displayed with correct currency symbols. | 1. Navigate to a page
displaying amount fields. 2. Observe the formatting of amount values. |
Amount fields should include appropriate currency symbol. | Amount: 1000, Currency: USD | Amount is displayed as "$1,000.00" with the correct currency symbol. |
| Sorting | Default page sorting should be provided. | 1. Open a page with sortable
data. 2. Observe the initial sorting order. |
Sorting should be applied to a specific column. | Default sort column: Date | The page loads with data sorted by the default column in ascending order. |
| Reset Button | Reset button functionality should set default values for all fields. | 1. Open a form page. 2. Fill in some fields. 3. Click the reset button. |
Reset button should clear all fields. | Default value: First Name = "", Age = 0 | All fields are cleared, and default values are restored. |
| Numeric Formatting | All numeric values should be formatted properly. | 1. Navigate to a page
displaying numeric values. 2. Observe the formatting of numbers. |
Numbers should be formatted with commas for thousands. | Numeric value: 1000000 | Number is displayed as "1,000,000" with proper formatting. |
| Max Field Value | Input fields should be checked for the max field value. | 1. Enter a value exceeding
the max limit. 2. Submit the form. |
Max limit: 100 | Value: 150 | The input is rejected, and an error message is displayed. |
| Special Characters | Check all input fields for special characters. | 1. Enter special characters
in various fields. 2. Submit the form. |
Special characters should be handled appropriately. | Input: "user@name" | Special characters are rejected or sanitized, and an appropriate validation message is displayed. |
| Field Labels | Field labels should be standard and descriptive. | 1. Open a form page. 2. Review field labels. |
Field labels must be descriptive and consistent. | Label: First Name | Field labels are descriptive and consistent across the application. |
| Sorting After CRUD | Check page sorting functionality after add/edit/delete operations. | 1. Add, edit, or delete a
record. 2. Observe the sorting behavior. |
Sorting should remain intact after CRUD operations. | Record added: New User | Sorting remains consistent after adding, editing, or deleting records. |
| Timeout | Check for timeout functionality. | 1. Log in to the
application. 2. Wait for the session timeout period. 3. Attempt to perform an action. |
Timeout value: 30 minutes | N/A | Application redirects to the login page or displays a timeout message. |
| Cookies | Check cookies used in an application. | 1. Open the
application. 2. Verify the presence of cookies. 3. Check cookie expiration. |
Cookies should be secure and encrypted. | Cookie name: SessionID, Expiry: 1 hour | Cookies are secure, encrypted, and expire after the specified duration. |
| Downloadable Files | Check if downloadable files are pointing to the correct file paths. | 1. Click on a download
link. 2. Verify the file opens/downloads correctly. |
File path must be valid. | Download link: https://example.com/files/report.pdf | The file downloads successfully and matches the expected content. |
| Resource Keys | All resource keys should be configurable in config files or databases. | 1. Open the
application. 2. Verify that text strings are stored externally. |
Resource keys must be stored externally. | Key: WelcomeMessage, Value: "Welcome to the application!" | Text strings are retrieved dynamically from external sources. |
| Naming Conventions | Standard conventions should be followed for naming resource keys. | 1. Review resource keys in
config files. 2. Verify adherence to naming standards. |
Naming conventions must be consistent. | Key: welcome_message | Resource keys follow a consistent naming convention. |
| HTML/CSS Validation | Validate markup for all web pages. | 1. Use tools like W3C
Validator. 2. Check for syntax errors. |
Markup must comply with W3C standards. | N/A | No syntax errors are found in HTML and CSS. |
| Error Redirection | Application crash or unavailable pages should be redirected to an error page. | 1. Simulate a crash or
access an unavailable page. 2. Observe redirection behavior. |
Custom error page must exist. | Error page URL: /error | The user is redirected to a custom error page with a friendly message. |
| Spelling/Grammar | Check text on all pages for spelling and grammatical errors. | 1. Review all visible text
on the application pages. 2. Proofread for accuracy. |
Text must be free of errors. | Visible text: "Submit you form here." | Text is corrected to "Submit your form here." |
| Numeric Input | Check numeric input fields with character input values. | 1. Enter alphabetic
characters in a numeric field. 2. Submit the form. |
Numeric fields should reject non-numeric input. | Input: "abc" | An error message is displayed for non-numeric input. |
| Negative Numbers | Check for negative numbers if allowed for numeric fields. | 1. Enter a negative number
in a numeric field. 2. Submit the form. |
Negative numbers may or may not be allowed. | Input: -10 | If allowed, the value is accepted; otherwise, an error message is displayed. |
| Decimal Numbers | Check amount fields with decimal number values. | 1. Enter a decimal number in
an amount field. 2. Submit the form. |
Decimal numbers should be handled correctly. | Input: 10.5 | The value is accepted and displayed with proper formatting. |
| Button Functionality | Check functionality of buttons available on all pages. | 1. Click all buttons on the
page. 2. Observe their actions. |
Buttons should perform their intended actions. | Button: Submit | The button performs its intended action. |
| Double Submission | The user should not be able to submit a page twice by pressing the submit button in quick succession. | 1. Rapidly click the submit
button multiple times. 2. Observe the result. |
Only one action should occur per submission. | N/A | The form is submitted only once, and subsequent clicks are ignored. |
| Divide by Zero | Divide by zero errors should be handled for any calculations. | 1. Perform a calculation
involving division by zero. 2. Observe the application behavior. |
Divide by zero errors should be gracefully handled. | Input: 10 รท 0 | An appropriate error message is displayed. |
| Leading/Trailing Blanks | Input data with the first and last position blank should be handled correctly. | 1. Enter values with
leading/trailing spaces. 2. Submit the form. |
Leading/trailing spaces should be handled appropriately. | Input: " John Doe " | Spaces are trimmed, and the value is processed correctly. |
Conclusion
These general test scenarios form the foundation of effective software testing. By validating these common functionalities, you can identify potential issues early, improve user experience, and deliver high-quality software. While this list is comprehensive, always tailor your test cases to the specific requirements of your application.
Are there any other general test scenarios you'd like us to cover? Share your thoughts in the comments below!
Join Our Community of QA Professionals
Get exclusive access to in-depth articles, testing strategies, and industry insights. Stay ahead of the curve with our expert-curated content delivered straight to your inbox.
Nikunj Mistri
Founder, QA Blogs
About the Author