Database test checklist for Web-Applications | David Tzemach

Overview

When a user performs operations on the browser (Client Side) the requests are sent to the back-end server that stores the application records in a dedicated database (SQL, Oracle etc.).

When testing a Web-Application, we will need to validate the synchronization between the two access points (Client (Browser) <-> Server Side (Database).

Checklist

• Validate that the data, which is displayed in the site is the one that stored in the back-end server.
• Validate that each column has a MAX input limit (Any value that exceeds this length will be rejected).
• Validate that the DB tables can handle the boundary values that are retrieved from the client.
• Verify the functionality of the DB stored procedures (Name, Parameters, output, syntax, etc.).
• Validate that every user operation will update the database values (Add, Delete, and Edit).
• Validate that the user will not be affected when there is a DB error (Back-end side).
• Validate that the user cannot access the DB without a proper authentication.
• Validate that the DB queries are executed without any failures.
• Validate that each table has the correct foreign/Primary keys.
• Validate that the DB server can handle negative numbers.
• Validate that the response time of the DB server.
• All DB tables should include a short description.
• Validate that the database structure contains the preliminary specifications (Tables, Columns, Stored-Procedures, Indexes, data types, flags etc.).
• Validate that the user data is committed only when the process is done (in any failure along the way this data should be ignored).
• Validate that the client interacts with the relevant database (in most cases the back-end site will host multiple databases).
• Validate that the client cannot update the DB with ‘Null’ value (in any tables that has a column that prohibits this value).
• Validate that there are no synchronization issues when the client/servers are located in a different Time zone.

System Test Review Checklist | David Tzemach

System Test Review Checklist

1.     Validate that every test objective is reviewed and approved by the team.

2.       Validate that every test is connected to a requirement (Each test should be linked to a specific requirement that will increase the traceability factor).

3.       Validate that your system tests will cover every requirement.

4.       Validate that you have a sufficient time to allow bug fixes.

5.       In any case that you need to test the system
with existing systems, validate the following:

a.       What are the requirements and specifications of the other system?

b.      What are the interfaces that are used to allow the integration process?

c.       What is the data flow between the two systems?

d.      Are there any hardware/application bottlenecks?

6.       Validate that you have a criterion for test coverage.

7.       Validate that your testing data is reviewed and approved.

8.       Validate that your team as the relevant knowledge to execute the tests.

9.       Validate that your team will know the business case behind the system

10.   Validate that each test is independent.

11.   Validate that you have a test preparation prior to the start of the testing cycles (Test Data, Test Environment etc.).

What is a “Use case” in software testing?

A “use case” in software testing, can be described as a detailed description of a user requirement that will help the test team to become familiar about the way that the user expects the application to operate.

A good and effective Use case, will describe the user operations (Step-By-Step) and the exact way that he wants to use the software functionalities

Things to remember:

• A Use case should be written as a requirement in the SRS/Spec documents.
• A Use case can be described in many ways, such as Flows, Diagrams Etc.
• A Use case should be detailed enough so the testers can understand it.
• A Use case should contain a user operation and the expected result.
• A Use case is NOT a "Test case" (Test case is designed based on it).
• A good use case will be valuable to the user.
• Single Use case per requirement.