Web testing practices
My notes: best practices from experience
Unit and integration testing best practices
How to test API?
Principles
Validations
Inputs examples
Create: POST
Read: GET, GET LIST
Update: PUT, PATCH
Delete: DELETE
Others (edge cases for edge cases)
Comprehensive testing checklist
General Test Scenarios
UI and Usability Test Scenarios
Performance Testing Test Scenarios
Security Testing Test Scenarios
Database Testing Test Scenarios
Test Scenarios for filters
Test Scenarios for results grid
Test Scenarios for forms and pop-ups
Test Scenarios for uploaded documents
Test Scenarios for export functionality
Test Scenarios for sending emails
UI testing checklist
Extra resources

Web testing practices

Functionality Testing (business logic for API and UI)
Usability and UI testing (manual testing)
Compatibility testing (browser, OS, device)
Performance testing (load, stress)
Security testing (input validations, auth)

My notes: best practices from experience

Tests should be independent from setup and teardown parts. You can use different implementations for these stages. Use try/except in teardown.
Tests themselves should be independents.
Sometimes you want your test to pass to behavior of backend, but sometimes you can make mistakes.
Naming conventions need to be discussed. Classes, test methods.
Config: API hosts, DB, users.
Automation engineers sometimes need to duplicate the work of developers.
Discuss in the beginning what to test, and how to test, what needs to be tested.
Users → Authentication and authorization. Do you have roles?
First test happy paths, then move to negative testing.
It is okay to have duplicate code in test scripts. Don't overuse clean coding, keep WET not too much DRY. In the end, we should have maintainable, extensible and readable code.
Validate RESPONSE body schema. Success responses and error responses. Validate status code.
Create a document: how to write test methods, how to design test cases, how to name, how to run, what kind of branching use, where store and how to write manual test cases, how to review test cases, how to report bugs.
What kind of metrics needed to track the effectiveness and efficiency of testing.
Setup CI/CD to run tests on a daily basis.

Unit and integration testing best practices

How to test API?

Principles

Test all HTTP methods: As CRUD operations are based on HTTP methods, it's essential to test all four HTTP methods for CRUD - POST, GET, PUT/PATCH, and DELETE.
Test with invalid inputs: Testing with invalid inputs is crucial for CRUD testing. For example, if a user tries to create or update a record with invalid data, the system should respond appropriately.
Test with boundary values: It's important to test CRUD operations with boundary values. For example, if there is a limit on the number of characters that can be used for a field, it's essential to test with inputs that are at the limit or exceed it.
Test with data integrity in mind: Data integrity is critical for CRUD operations, and testing should be designed to ensure that the system maintains data consistency during CRUD operations.
Test with authorization in mind: Authorization is essential for CRUD operations, and testing should be designed to ensure that only authorized users can perform CRUD operations.
Test with different user roles: CRUD operations should be tested with different user roles. For example, a user with administrative privileges should have access to all CRUD operations, while a regular user should have limited access.
Test with error handling in mind: Testing should be designed to ensure that the system handles errors correctly during CRUD operations. For example, if a record cannot be created due to an error, the system should provide an appropriate error message.

Validations

Happy Path Scenarios: Test the Create, Read, Update, and Delete functionalities with valid and complete data.
Negative Test Cases: Verify the Create, Read, Update, and Delete functionalities with invalid or incomplete data, such as null or missing fields, wrong data types, and values that violate business rules.
Data Consistency: Test the consistency of data after performing Create, Update, and Delete operations by retrieving the same data using GET or GET ALL.
Authentication and Authorization: Test the functionalities with different authentication and authorization scenarios, such as valid and invalid user credentials, and user roles.
Duplicate Check: Check for duplicate resources by attempting to create resources with identical data.
Parameter Validation: Test the functionalities with different parameter scenarios, such as missing, empty, or null values, long strings, special symbols, and non-existing or non-required fields.
Response Validation: Validate the response status code, message, and data schema of the API responses.
Method Validation: Test the API functionalities with different HTTP methods, such as GET, POST, PUT, PATCH, and DELETE.
Business Logic: Test the functionalities with different business logic scenarios, such as unique email or phone numbers, and change in the order of parameters.
Data Integrity: Test the API functionalities with different data integrity scenarios, such as sending empty data, empty body, and redundant fields.

Inputs examples

String

empty string: " " and ""
NULL
string with length 1 and string with length 255+
lowercase and upper case letters
!@#$%^&*()_+():;',.
characters in the Unicode: ProTip™, 👻, 60%, https://google.com
spaces before and after the name
Latin and Cyrillic, logograms
<body>
different data type instead of string, use integer/float instead of string
SQL/NoSQL syntax in strings: Instead of just "injections," try strings like ' OR 1=1 -- or {"$gt": ""}.
Path traversal: Strings like ../../etc/passwd or C:\Windows\System32.
Zero-width characters: These are invisible characters (like \u200B) that can cause "duplicate" records that look identical to a human but different to a computer.
Long strings (Overflow): Go beyond 255. Try 32,767 (max for some small text types) or 65,535 characters.
Boundary testing: * Exactly 255, 256, 65535, and 65536 characters (common database column limits).
System commands: * ' ; ls -la ; (Command injection attempt). {{7*7}} (Template injection—if the response returns 49, the API is vulnerable).
The "Invisible" killers:

\n, \r, \t (New line, carriage return, and tabs inside a string).
\0 (The Null Byte—in some older languages, this tells the system the string has "ended" prematurely).

The "Script" test: <img src=x onerror=alert(1)> (Testing if the API sanitizes HTML before storing it).

Numbers

empty input
NULL
Integers: -1, 0, 1, 2, middle, max, max+1
leading 0s in integers
floats: with comma or point
different data type instead of int/float
Precision: For floats, send a number with 20 decimal places (e.g., 0.00000000000000000001). Does the API round it, truncate it, or crash?
Scientific notation: Try 1e3 or 1.5E-10
Divisor zero: If this number is used in a calculation, what happens if you send 0?
Currency/Decimals: If it’s a price, try a negative price 99.99
Currency specifics: 0.001 (If the system only allows two decimals, does this round up to 0.01 or down to 0.00?).
The "Great Beyond" (Overflow):

2147483647 (Max 32-bit Integer).
2147483648 (Max + 1—often causes a crash or flips to a negative number).
9007199254740991 (Number.MAX_SAFE_INTEGER in JavaScript).

Array

empty array
NULL
array with different data types
array with 10,000 identical items
super large array
Empty nest: [null], [{}], [[]] (Arrays containing empty items)
Deep nesting: What if you send an object inside an object inside an object... 100 times? (This is a "Billion Laughs" style attack).
If the API expects {"name": "John"}, send {"name": {"first": "John", "last": "Doe"}}. (Sending an object where a string is expected).
Duplicate keys: In JSON, what happens if you send {"id": 1, "id": 2}? Which one does the API keep?

Dates and time

ISO 8601 Compliance: Send 2024-05-20T12:00:00Z vs. 20/05/2024.
Leap year: Try February 29th on a non-leap year vs. a leap year.
Timezones: Send a date with a massive offset (e.g., +14:00 or 12:00).
The "Unix Epoch": send 0 or 1970-01-01.
The "Future-Past" paradox:

1900-01-01 (Very old).
9999-12-31 (The far future).

The "Invalid" day:

2023-02-30 (February 30th doesn't exist).
2023-04-31 (April only has 30 days).

The "Format" flip:

12-10-2024 (Is this December 10th or October 12th?).

Booleans

Non-standard truths: Instead of true/false, try "true", 1, 0, "yes", "no", or null.
Case censitivity: Does the API accept TRUE, True, true, "Y", "N", "T", "F"?
"" (An empty string often evaluates to false in some languages—is that allowed?).

Security testing: injections

Create: POST

Positive test cases:

Create an object with only mandatory fields (leave out all optional ones). Create the object with valid data and in valid condition. Expect response status code to be 201 (Created). Validate response payload.
Create an object with all optional fields filled with maximum allowed lengths/values.
After POST, check if the object was added using GET or GET LIST request. Verify that the response payload exactly matches the input data (no data loss or unexpected transformations, like "John" becoming "john")
If request payload is JSON, change order of the parameters.
Try all valid inputs values in JSON request payload.
Idempotency (The "Double Tap"): If your API supports X-Idempotency-Key, send the same request twice. The second response should be a success (200 or 201) but not create a duplicate in the database.
Default values: Create an object without fields that have "defaults" on the backend. Check if the backend correctly assigned the default values (e.g., status: "active").
Character preservation: Create an object with complex strings (Emojis, Non-Latin, HTML tags) and use a GET request to ensure the data wasn't corrupted or "cleaned" incorrectly in the database.

Negative test cases:

Validate the business logic. Even if you provide valid data, there could be cases when the action should not be performed. For example, what if object can't be created in particular statuses.
Parameters:

Check if parameter is mandatory/not mandatory missed or null.
Add extra parameter in JSON, use not existing JSON parameters.
Send redundant fields. What will happen if we will have two similar keys?
Check if parameter strings are CAPITALIZED.

Values (Please use the checklist above to validate strings and numbers).
Test with empty body.
What if URL PATH parameter doesn’t exist or invalid? Ex: what if tenant doesn't exist, schema type/version? In URL, use null, “”, “ “, not allowed template.
Duplicate check: based on business logic, emails, phone numbers might be unique. Try to create duplicate resources.
Send unauthenticated request. Send the request with no Authorization header (401 Unauthorized)
Try to access different tenant.
Use different HTTP method instead of POST.
Try to send fields that the user shouldn't be able to set, like is_admin: true, role: "superuser", or balance: 999999
If a field expects an Array, send an Object.
If it expects a Boolean, send the string "true"
Try to create an object linked to a non-existent parent ID (e.g., create a "Comment" for a "PostID" that doesn't exist)
Try to create an object with logically impossible dates (e.g., end_date occurs before start_date)
Send a valid JSON body but set Content-Type: text/plain
Send an empty Content-Length header.
Send a JSON payload where an object refers to itself in a way that might cause a recursive loop on the server.
Keep POSTing until you hit the limit. Does the API return 429 Too Many Requests
Send a POST request with a 10MB JSON body. Does the server return 413 Payload Too Large or does it crash
If a field is "Unique" in the database (like a username), try creating it, then deleting it, then creating it again. Some systems fail to "clear" the unique constraint on deleted items
Use a valid token that has "Read" permissions but try to "POST" (Create). You should get a 403 Forbidden
Try to create a resource but set the tenant_id or organization_id to one that belongs to a different user
Injection: send {"username": {"$gt": ""}} or {"username": "' OR 1=1--"}.

Status Code	Scenario
201 Created	Successful creation.
400 Bad Request	Missing mandatory fields, syntax errors, or type mismatches.
401 Unauthorized	Missing or invalid authentication token.
403 Forbidden	Authenticated, but no permission to create this resource.
409 Conflict	Trying to create a duplicate (e.g., same email/username).
413 Payload Too Large	The JSON body is too big for the server to process.
415 Unsupported Media Type	Wrong `Content-Type` header (e.g., sending XML instead of JSON).
422 Unprocessable Entity	The JSON is valid, but the business logic fails (e.g., `age: -5`).

Read: GET, GET LIST

Positive test cases:

If no data, then GET LIST should return empty list.
Populate with data before fetching and validate if data is there.
Request may work differently if search or/and filters is used for GET LIST.
Check that "numbers" are numbers, not strings (e.g., price: 10.99 vs "price": "10.99").
The "Single Object" (GET /id)

Data Integrity: Verify all fields returned in the response match the database exactly.
Format Check: Verify the date formats (ISO 8601), currency symbols, and nested objects are correct.
Header Verification: Ensure headers like Content-Type: application/json are present.

The "List & Collection" (GET /)

Empty State: Verify that if no records exist, the API returns a 200 OK with an empty array [], not a 404.
Pagination (The Essentials): * Test page=1&size=10.

Verify that the response includes metadata (e.g., total_records, total_pages, next_page_url).

Sorting: Test sort=desc and sort=asc. Verify the first and last items in the list to ensure the order is mathematically correct.
Filtering: Test filtering by every available parameter (e.g., status=active, category=electronics).
Try combining filters. Multi-filter: ?status=active&type=admin
Range filter: ?created_after=2024-01-01&created_before=2024-12-31
Search: Test partial matches (e.g., searching "Gemi" to find "Gemini").

Response time: Verify the list returns within an acceptable threshold (e.g., <200ms) even with 100 items.
Cache headers: Check for ETag or Cache-Control headers. If you request the same data twice, does it load faster?

Negative test cases:

What if URL PATH parameter doesn’t exist? Ex: what if tenant doesn't exist, schema type/version? In URL, use null, “”, “ “, not allowed template.

Use not existing ID for GET request.

Send unauthorized request: Try to GET without a token. Expect 401 Unauthorized.
Try to access different tenant. A junior tester checks if the data is there. An elite tester checks if the data is only there for the person who is allowed to see it.
IDOR (Horizontal Privilege Escalation): Try to GET a resource ID that belongs to another user or tenant. You should get a 403 Forbidden or 404 Not Found.
Expired Token: Try to GET with a token that has expired.
Pagination Overload: * Try size=99999999. Does the API cap the results at a maximum (e.g., 100), or does it try to load everything and crash the database? Try page=-1 or page=abc.
Filter Injection: Try putting SQL-like syntax in the filter: /users?name=' OR 1=1.
Invalid ID Formats: * /users/0, /users/-5, /users/null, /users/undefined
Resource Non-Existent: GET an ID that has never been created. Expect 404 Not Found.
Wrong Endpoint: /user (singular) instead of /users (plural).
Unacceptable Format: Set the header Accept: application/xml if the API only supports JSON. Expect 406 Not Acceptable.
GET a list, DELETE one item, GET list again. The deleted item must disappear immediately (Cache check).
Searching for 👻 or &. Does the search break or return a 500 Error?
A list with 500+ large objects. Does the API use "Gzip" to compress the data so the download is fast?
Requesting page 1,000,000. The API should handle this without timing out.

Update: PUT, PATCH

Positive test cases:

Create the object with valid data and in valid condition. Expect response status code to be 200 (OK).
In PUT, PATCH check that data was modified using GET. Send every single field. Verify with a GET that every field updated and no data was lost. If update is unsuccessful check that the data was not modified.
If you update an object, ensure fields that weren't in the request (but are system-generated like created_at) remain unchanged.
If request payload is JSON, change order of the parameters.
Try not filling optional arguments.
Try all valid inputs values in JSON request payload.
Send only one field (e.g., {"status": "active"}). Verify that only that field changed and all other data stayed exactly the same.
Update a single field inside a nested object (e.g., just the zip_code inside an address object) without wiping out the city or street.
Send the exact same PUT request twice. The second time should still result in a 200 OK and the data should remain identical.

Negative test cases:

Validate the business logic. Even if you provide valid data, there could be cases when the action should not be performed. For example, what if object can't be updated in particular statuses.
Parameters:

Check if parameter is mandatory/not mandatory missed or null.
Add extra parameter in JSON, use not existing JSON parameters.
Send redundant fields. What will happen if we will have two similar keys?
Check if parameter strings are CAPITALIZED.

Values (Please use the checklist above to validate strings and numbers).
Test with empty body.
What if URL PATH parameter doesn’t exist or invalid? Ex: what if tenant doesn't exist, schema type/version? In URL, use null, “”, “ “, not allowed template.
Duplicate check: based on business logic, emails, phone numbers might be unique. Try to create duplicate resources.
Send unthenticated request. Try to update a resource ID that belongs to another user/tenant. You should get a 403 Forbidden or 404 Not Found.
Try to access different tenant.
Send {"name": null} in a PATCH. Does the API clear the name or ignore the field? (Check business requirements).
PATCH an ID that was just DELETEd. Verifies the system doesn't allow "zombie" updates.
Send {"age": "25"} (string) instead of 25 (int). Does the API auto-convert or strictly validate?
Send a 1MB string into a "description" field. Tests database truncation or 413 Payload Too Large.
Use different HTTP method instead of PUT/PATCH.
Try to update fields that should never change, such as id, uuid, created_at, or owner_id. The API should either ignore these or return a 400 Bad Request.
Try to "elevate" yourself by sending {"role": "admin"} or {"balance": 99999}.
If an order status is "Cancelled," try to PATCH it to "Shipped." This should fail based on business logic.
Send a PUT request with a missing mandatory field. It should fail with 400 Bad Request rather than deleting that field's value in the database.
Send a PATCH with an empty body {}. It should ideally return 200 (no change) or 400 (nothing to update), but never crash.
Two users PATCH the same resource at the same time. With different payloads, and same.
If the API uses If-Match headers (ETags), try to update a resource with an outdated ETag. It should return 412 Precondition Failed.

Delete: DELETE

Positive test cases:

Delete the existing object. Expect 204 (No content). Use GET or GET ALL to check if the deleted object doesn't exist.

Standard Cleanup: Delete an existing object. Expect 204 No Content or 200 OK.
The "Double Check": Immediately follow a DELETE with a GET. Expect 404 Not Found.

Soft Delete Verification: Verify the record still exists in the DB with a deleted_at timestamp, but is filtered out of all public API GET calls.
Cascading Cleanup: If a Parent is deleted, verify all linked "Children" (e.g., a user's profile settings) are also removed or nullified.
Storage Purge: Verify that associated files (images, PDFs) are deleted from S3 or cloud storage buckets.
Cache Invalidation: Verify the item is removed from Redis or CDN caches and no longer appears in search results (Elasticsearch).
Audit Logging: Verify the system logs the "Delete" event with the Correct User ID and Timestamp.
The "Undo" Policy: If the business logic allows a 30-day "Trash" period, verify the item is moved to a deleted state but not permanently purged.

Negative test cases:

DELETE already deleted entity. Attempt to delete an ID that has already been deleted. Expect 404 Not Found or 410 Gone.
When DELETE with not existing ID. Attempt to delete a random/fake ID. Expect 404 Not Found.
When DELETE with wrong ID, check that no data was deleted in GET ALL.
What if URL PATH parameter doesn’t exist? Ex: what if tenant doesn't exist, schema type/version? In URL, use null, “”, “ “, not allowed template.
Attempt to delete a resource that is currently "Locked" or "In Progress" (e.g., deleting an order that is already out for delivery). Expect 400 Bad Request or 422 Unprocessable Entity.
Send unauthenticated request. Attempt to delete without a token. Expect 401 Unauthorized.
Try to access different tenant.
Unauthorized Deletion: Attempt to delete a resource using a valid token that belongs to a different user/tenant. Expect 403 Forbidden.
Scope Violation: Use a token with read-only scopes to attempt a DELETE. Expect 403 Forbidden.
Attempt to delete a parent that has required children (if the system prevents cascading). Expect 409 Conflict.
Send two DELETE requests for the same ID at the exact same millisecond. Ensure the system doesn't crash or return two 204 responses.
Send a string where an Integer ID is expected (e.g., DELETE /user/abc). Expect 400 Bad Request.
Attempt to DELETE the base endpoint (e.g., DELETE /users/). Expect 405 Method Not Allowed or 400 Bad Request

Status Code	Why it happened
204 No Content	Perfect. It's gone, and there's nothing left to say.
403 Forbidden	You found it, but you aren't allowed to kill it.
404 Not Found	You're trying to kill a ghost (it doesn't exist).
409 Conflict	It has "Children" that need to be deleted first.
410 Gone	(Elite!) The system remembers it was there, but it's gone now.

Others (edge cases for edge cases)

Try to access the not existing endpoints.
Sending two Authorization headers with different tokens. Which one does it trust?
Sending a JSON file that is just one massive string of "A"s until the server runs out of memory.
Using /../ in the URL path to see if you can access internal server files.
Header & Metadata Testing

The body isn't the only thing that matters. Headers often control the logic of the API.

Content-Type Mismatch: Send a JSON body but set Content-Type: application/xml. (Does it crash or return a 415 Unsupported Media Type?)
Accept Header: Ask for Accept: application/pdf on a JSON endpoint.
Custom Headers: If your API uses custom headers (e.g., X-Request-ID or X-Tenant-ID), test what happens when they are missing, malformed, or suspiciously long.
User-Agent: Does the API behave differently if the User-Agent is a mobile browser vs. a script (curl)?

Rate Limiting & Throttling (The "Spam" Test)

Professional APIs should protect themselves from being overwhelmed.

Rate Limit: Send 100 requests in 1 second. Do you get a 429 Too Many Requests?
Retry-After: Does the 429 response include a Retry-After header telling you when to come back?

Payload Size & Compression

Large Payloads: What if the JSON body is 5MB? 50MB? (Test the 413 Payload Too Large limit).
Gzip/Deflate: Send a compressed request body to see if the server handles decompression correctly.

Response Time & Timeouts

Latency: Use a tool to simulate a slow network. Does the API connection time out gracefully, or does it hang forever?
Consistency: Send the same request 10 times. Is the response time relatively stable, or are there massive spikes?

Data Consistency (The "Double-Edge" Case)

Race Conditions: If you send two PATCH requests to the same resource at the exact same millisecond with different data, which one wins? Does the server handle the "collision"?
Pagination Deep-Diving: On GET LIST, test the page_size=0 and page_size=999999. Also, test what happens if you ask for page=2 when there is only 1 page of data.

Security (Beyond Injections)

CORS (Cross-Origin Resource Sharing): Try calling the API from a different domain. Is it properly restricted?
Token Expiry: Use a valid but expired JWT/Auth token.
Token Scopes: Use a token that is valid for "Read" but try to "Delete."

Comprehensive testing checklist

Few notes to remember:

Execute these scenarios with different user roles e.g. admin user, guest user etc.
These scenarios should be tested on multiple browsers like IE, FF, Chrome, Safari etc. installed on different OSs (depends on requirements)
Test with different screen resolutions like 1024 x 768, 1280 x 1024, etc.
Application should be tested on variety of displays like tablets or mobile phones (depends on customer's requirements: mobile version, tablet version or version for special customer's devices).

General Test Scenarios

All mandatory fields should be validated and indicated by asterisk * symbol
Validation error messages should be displayed properly at correct position
All error messages should be displayed in same CSS style
General confirmation messages should be displayed using CSS style other than error messages style (e.g. using green color)
Tool tips text should be meaningful
Dropdown fields should have first entry as blank or text like ‘Select’
Delete functionality for any record on page should ask for confirmation
Select/deselect all records options should be provided if page supports record add/delete/update functionality
Amount values should be displayed with correct currency symbols
Default page sorting should be provided
Reset button functionality should set default values for all fields
All numeric values should be formatted properly
Input fields should be checked for max field value. Input values greater than specified max limit should not be accepted or stored in database
Check all input fields for special characters
Field labels should be standard e.g. field accepting user’s first name should be labeled properly as ‘First Name’
Check page sorting functionality after add/edit/delete operations on any record
Check for timeout functionality. Timeout values should be configurable. Check application behavior after operation timeout
Check cookies used in an application
Check if downloadable files are pointing to correct file paths
All resource keys should be configurable in config files or database instead of hard coding
Standard conventions should be followed throughout for naming resource keys
Validate markup for all web pages (validate HTML and CSS for syntax errors) to make sure it is compliant with the standards
Application crash or unavailable pages should be redirected to error page
Check text on all pages for spelling and grammatical errors
Check numeric input fields with character input values. Proper validation message should appear
Check for negative numbers if allowed for numeric fields
Check amount fields with decimal number values
Check functionality of buttons available on all pages
User should not be able to submit page twice by pressing submit button in quick succession.
Divide by zero errors should be handled for any calculations
Input data with first and last position blank should be handled correctly

UI and Usability Test Scenarios

All fields on page (e.g. text box, radio options, dropdown lists) should be aligned properly
Numeric values should be right justified unless specified otherwise
Enough space should be provided between field labels, columns, rows, error messages etc.
Scroll bar should be enabled only when necessary
Font size, style and color for headline, description text, labels, infield data, and grid info should be standard as specified in Software Requirements Specification
Description text box should be multi-line
Disabled fields should be grayed out and user should not be able to set focus on these fields
Upon click of any input text field, mouse arrow pointer should get changed to cursor
User should not be able to type in drop down select lists
Information filled by users should remain intact when there is error message on page submit. User should be able to submit the form again by correcting the errors
Check if proper field labels are used in error messages
Dropdown field values should be displayed in defined sort order
Tab and Shift+Tab order should work properly
Default radio options should be pre-selected on page load
Field specific and page level help messages should be available
Check if correct fields are highlighted in case of errors
Check if dropdown list options are readable and not truncated due to field size limit
All buttons on page should be accessible by keyboard shortcuts and user should be able to perform all operations using keyboard
Check all pages for broken images
Check all pages for broken links
All pages should have title
Confirmation messages should be displayed before performing any update or delete operation
Hour glass should be displayed when application is busy
Page text should be left justified
User should be able to select only one radio option and any combination for check boxes.

Performance Testing Test Scenarios

Check if page load time is within acceptable range
Check page load on slow connections
Check response time for any action under light, normal, moderate and heavy load conditions
Check performance of database stored procedures and triggers
Check database query execution time
Check for load testing of application
Check for stress testing of application
Check CPU and memory usage under peak load condition

Security Testing Test Scenarios

(Visit OWASP website for details)

Check for SQL injection attacks
Secure pages should use HTTPS protocol
Page crash should not reveal application or server info. Error page should be displayed for this
Escape special characters in input
Error messages should not reveal any sensitive information
All credentials should be transferred over an encrypted channel
Test password security and password policy enforcement
Check application logout functionality
Check for Brute Force Attacks
Cookie information should be stored in encrypted format only
Check session cookie duration and session termination after timeout or logout
Session tokens should be transmitted over secured channel
Password should not be stored in cookies
Test for Denial of Service attacks
Test for memory leakage
Test unauthorized application access by manipulating variable values in browser address bar
Test file extension handing so that exe files are not uploaded and executed on server
Sensitive fields like passwords and credit card information should not have auto complete enabled
File upload functionality should use file type restrictions and also anti-virus for scanning uploaded files
Check if directory listing is prohibited
Password and other sensitive fields should be masked while typing
Check if forgot password functionality is secured with features like temporary password expiry after specified hours and security question is asked before changing or requesting new password
Verify CAPTCHA functionality
Check if important events are logged in log files
Check if access privileges are implemented correctly

Database Testing Test Scenarios

Check if correct data is getting saved in database upon successful page submit
Check values for columns which are not accepting null values
Check for data integrity. Data should be stored in single or multiple tables based on design
Index names should be given as per the standards e.g. IND_<Tablename>_<ColumnName>
Tables should have primary key column
Table columns should have description information available (except for audit columns like created date, created by etc.)
For every database add/update operation log should be added
Required table indexes should be created
Check if data is committed to database only when the operation is successfully completed
Data should be rolled back in case of failed transactions
Database name should be given as per the application type i.e. test, UAT, sandbox, live (though this is not a standard it is helpful for database maintenance)
Database logical names should be given according to database name (again this is not standard but helpful for DB maintenance)
Stored procedures should not be named with prefix “sp_”
Check is values for table audit columns (like createddate, createdby, updatedate, updatedby, isdeleted, deleteddate, deletedby etc.) are populated properly
Check if input data is not truncated while saving. Field length shown to user on page and in database schema should be same
Check numeric fields with minimum, maximum, and float values
Check numeric fields with negative values (for both acceptance and non-acceptance)
Check if radio button and dropdown list options are saved correctly in database
Check if database fields are designed with correct data type and data length
Check if all table constraints like Primary key, Foreign key etc. are implemented correctly
Test stored procedures and triggers with sample input data
Input field leading and trailing spaces should be truncated before committing data to database
Null values should not be allowed for Primary key column

Test Scenarios for filters

User should be able to filter results using all parameters on the page
Refine search functionality should load search page with all user selected search parameters
When there is at least one filter criteria is required to perform search operation, make sure proper error message is displayed when user submits the page without selecting any filter criteria.
When at least one filter criteria selection is not compulsory user should be able to submit page and default search criteria should get used to query results
Proper validation messages should be displayed for invalid values for filter criteria

Test Scenarios for results grid

Page loading symbol should be displayed when it’s taking more than default time to load the result page
Check if all search parameters are used to fetch data shown on result grid
Total number of results should be displayed on result grid
Search criteria used for searching should be displayed on result grid
Result grid values should be sorted by default column.
Sorted columns should be displayed with sorting icon
Result grids should include all specified columns with correct values
Ascending and descending sorting functionality should work for columns supported with data sorting
Result grids should be displayed with proper column and row spacing
Pagination should be enabled when there are more results than the default result count per page
Check for Next, Previous, First and Last page pagination functionality
Duplicate records should not be displayed in result grid
Check if all columns are visible and horizontal scroll bar is enabled if necessary
Check data for dynamic columns (columns whose values are calculated dynamically based on the other column values)
For result grids showing reports check ‘Totals’ row and verify total for every column
For result grids showing reports check ‘Totals’ row data when pagination is enabled and user navigates to next page
Check if proper symbols are used for displaying column values e.g. % symbol should be displayed for percentage calculation
Check result grid data if date range is enabled

Test Scenarios for forms and pop-ups

Check if default form\pop-up size is correct
Check if pop-up size is correct
Check if there is any field on page with default focus (in general, the focus should be set on first input field of the screen)
Check if child windows are getting closed on closing parent/opener window
If child window is opened, user should not be able to use or update any field on background or parent window
Check window minimize, maximize and close functionality
Check if window is re-sizable
Check scroll bar functionality for parent and child windows
Check cancel button functionality for child window

Test Scenarios for uploaded documents

(Also applicable for other file upload functionality)

Check for uploaded doc path
Check doc upload and change functionality
Check doc upload functionality with doc files of different extensions (e.g. JPEG, PNG, BMP etc.)
Check doc upload functionality with docs having space or any other allowed special character in file name
Check duplicate name doc upload
Check doc upload with doc size greater than the max allowed size. Proper error message should be displayed.
Check doc upload functionality with file types other than docs (e.g. txt, doc, pdf, exe etc.). Proper error message should be displayed
Check if docs of specified height and width (if defined) are accepted otherwise rejected
doc upload progress bar should appear for large size docs
Check if cancel button functionality is working in between upload process
Check if file selection dialog shows only supported files listed
Check multiple docs upload functionality
Check doc quality after upload. doc quality should not be changed after upload
Check if user is able to use/view the uploaded docs

Test Scenarios for export functionality

File should get exported in proper file extension
File name for the exported doc file should be as per the standards e.g. if file name is using timestamp, it should get replaced properly with actual timestamp at the time of exporting the file
Check for date format if exported doc file contains date columns
Check number formatting for numeric or currency values. Formatting should be same as shown on page
Exported file should have columns with proper column names
Default page sorting should be carried in exported file as well
Doc file data should be formatted properly with header and footer text, date, page numbers etc. values for all pages
Check if data displayed on page and exported doc file is same
Check export functionality when pagination is enabled
Check if export button is showing proper icon according to exported file type e.g. doc file icon for xls files
Check export functionality for files with very large size
Check export functionality for pages containing special characters. Check if these special characters are exported properly in doc file

Test Scenarios for sending emails

(Test cases for composing or validating emails are not included)

(Make sure to use dummy email addresses before executing email related tests)

Email template should use standard CSS for all emails
Email addresses should be validated before sending emails
Special characters in email body template should be handled properly
Language specific characters (e.g. Russian, Chinese or German language characters) should be handled properly in email body template
Email subject should not be blank
Placeholder fields used in email template should be replaced with actual values e.g. Firstname and Lastname should be replaced with individuals first and last name properly for all recipients
If reports with dynamic values are included in email body, report data should be calculated correctly
Email sender name should not be blank
Emails should be checked in different email clients like Outlook, Gmail, Hotmail, Yahoo! mail etc.
Check send email functionality using TO, CC and BCC fields
Check plain text emails
Check HTML format emails
Check email header and footer for company logo, privacy policy and other links
Check emails with attachments
Check send email functionality to single, multiple or distribution list recipients
Check if reply to email address is correct
Check sending high volume of emails

UI testing checklist

Testing user interface for web application is slightly different from testing user interface of traditional applications. Irrespective of the web application there are certain things which should be tested for every web application. Following checklist will give some information on items that should be tested to ensure quality of the user interface of your web application.

Colors

Are hyperlink colors standard?
Are the field backgrounds the correct color?
Are the field prompts the correct color?
Are the screen and field colors adjusted correctly for non-editable mode?
Does the site use (approximately) standard link colors?
Are all the buttons are in standard format and size?
Is the general screen background the correct color?
Is the page background (color) distraction free?

Content

All fonts to be the same
Are all the screen prompts specified in the correct screen font?
Does content remain if you need to go back to a previous page, or if you move forward to another new page?
Is all text properly aligned?
Is the text in all fields specified in the correct screen font?
Is all the heading are left aligned
Does the first letter of the second word appears in lowercase?

Images

Are all graphics properly aligned?
Are graphics being used the most efficient use of file size?
Are graphics optimized for quick downloads?
Assure that command buttons are all of similar size and shape, and same font & font size.
Banner style & size & display exact same as existing windows
Does text wrap properly around pictures/graphics?
Is it visually consistent even without graphics?

Instructions

Is all the error message text spelt correctly on this screen?
Is all the micro-help text(i.e tool tip) spelt correctly on this screen?
Microhelp text(i.e tool tip) for every enabled field & button
Progress messages on load of tabbed(active screens) screens

Navigation

Are all disabled fields avoided in the TAB sequence?
Are all read-only fields avoided in the TAB sequence?
Can all screens accessible via buttons on this screen be accessed correctly?
Does a scrollbar appear if required?
Does the Tab Order specified on the screen go in sequence from Top Left to bottom right? This is the default unless otherwise specified.
Is there a link to home on every single page?
On open of tab focus will be on first editable field
When an error message occurs does the focus return to the field in error when the user cancels it?

Usability

Are all the field prompts spelt correctly?
Are fonts too large or too small to read?
Are names in command button & option box names are not abbreviations.
Assure that option boxes, option buttons, and command buttons are logically grouped together in clearly demarcated areas "Group Box"
Can the typical user run the system without frustration?
Do pages print legibly without cutting off text?
Does the site convey a clear sense of its intended audience?
Does the site have a consistent, clearly recognizable "look-&-feel"?
Does User cab Login Member Area with both UserName/Email ID ?
Does the site look good on 640 x 480, 600x800 etc.?
Does the system provide or facilitate customer service? i.e. responsive, helpful, accurate?
Is all terminology understandable for all of the site’s intended users?

Extra resources

https://www.clouddefense.ai/blog/10-best-practices-for-software-testing-projects best practices
Validating input: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html

The MOST comprehensive testing checklist and practices