The document discusses test case generation for verifying and testing database functionalities. It describes test case generation as the process of writing SQL test cases and designing them based on the functionalities of an application. The purpose is to check the output against expected results. Multiple techniques for generating test cases are discussed, including goal-oriented, random, specification-based, and source-code-based approaches. Best practices for writing quality test cases are also provided.

1. Generating Test Cases
Abhinav Kumar Singh
MCA/25018/21

2. What is Test Case Generation
Test case generation is the process of writing SQL test cases for verifying and testing database
functionalities. Relational databases are queried by SQL statements, so the test cases are also
generated in SQL. Test cases are designed based of the functionalities of an application. So it
varies from one application to another. The purpose of test case generation is to check the
output against expected results. Based on the results, either the test case is modified or kept as
it is.

3. Explanation
The aim of testing is to find bugs in a system or application. Test case generation is the process
of building test suites for detecting system errors. A test suite is a group of relevant test cases
bundled together. Test case generation is the most important and fundamental process of
software testing.

4. Multiple techniques available for
generating test cases
• Goal-oriented approach – The purpose of the goal-oriented test case generation approach is to
cover a particular section, statement or function. Here the execution path is not important, but
testing the goal is the primary objective.
• Random approach – The random approach generates test cases based on assumptions of errors
and system faults.
• Specification-based technique – This model generates test cases based on the formal
requirement specifications.
• Source-code-based technique – The source-code-based case generation approach follows a
control flow path to be tested, and the test cases are generated accordingly. It tests the
execution paths.
• Sketch-diagram-based approach – This type of case generation approach follows the Unified
Modeling Language (UML) diagram to formulate the test cases.

5. Different Types of Test Cases
Test cases can measure many different aspects of code. The steps involved may also be intended
to induce a Fail result as opposed to a positive expected result such as when a user inputs the
wrong password on a login screen.

6. How to Write Software Test Cases
Writing test cases varies depending on what the test case is measuring or testing. This is also a situation where sharing test assets across
dev and test teams can accelerate software testing. But it all starts with knowing how to write a test case effectively and efficiently.
Test cases have a few integral parts that should always be present in fields. However, every test case can be broken down into 8 basic
steps.
Step 1: Test Case ID
Test cases should all bear unique IDs to represent them. In most cases, following a convention for this naming ID helps with organization,
clarity, and understanding.
Step 2: Test Description
This description should detail what unit, feature, or function is being tested or what is being verified.
Step 3: Assumptions and Pre-Conditions
This entails any conditions to be met before test case execution. One example would be requiring a valid Outlook account for a login.
Step 4: Test Data
This relates to the variables and their values in the test case. In the example of an email login, it would be the username and password for
the account.

7. Continue…
Step 5: Steps to be Executed
These should be easily repeatable steps as executed from the end user’s perspective. For instance, a test case for logging into an email server might include these steps:
Open email server web page.
Enter username.
Enter password.
Click “Enter” or “Login” button.
Step 6: Expected Result
This indicates the result expected after the test case step execution. Upon entering the right login information, the expected result would be a successful login.
Step 7: Actual Result and Post-Conditions
As compared to the expected result, we can determine the status of the test case. In the case of the email login, the user would either be successfully logged in or not. The
post-condition is what happens as a result of the step execution such as being redirected to the email inbox.
Step 8: Pass/Fail
Determining the pass/fail status depends on how the expected result and the actual result compare to each other.
Same result = Pass
Different results = Fail

8. What Are the Best Practices for Writing
Quality Test Cases
How to write effective tests and test cases can be streamlined over time. Some best
practices include using strong titles, strong descriptions, and keeping the language concise and clear.
But you’ll also want to include preconditions, assumptions, and the expected results, too. All of this
information is relevant for the software tester — especially when determining whether the test case
should be a “pass” or a “fail” instead.
A cheat sheet for creating test cases that work well is as follows:
Keep things simple and transparent.
Make test cases reusable.
Keep test case IDs unique.
Peer review is important.
Test cases should have the end user or defined requirements in mind.
Specify expected results and assumptions.

10. What Is a Test Suite
A test suite comes into play for test cases as it relates to source code, the collection of
dependencies, or the suite of tests to be performed on code. Test suites allow you to categorize
test cases in ways that align with any analysis or planning needs.
This means that core software features might have their own test suite while another test suite
is for a specific testing type such as smoke or security.

11. What Is a Test Plan
In contrast, a test plan is more like the umbrella that stands over all of the test suites. If test
cases are books and test suites are bookshelves, then test plans are the room that contains the
bookshelf.
Generally, test plans are set up in terms of manual tests, automated tests, and a general format
of how to go about testing.

12. Example of Test Case

13. Thank You