How to Write Test Cases?

What is a Test Case?

A test case is a set of criteria that a tester uses to verify whether or not a software application is meeting the customer's requirements. Preconditions, case name, input conditions, and intended result are all included in the test case design. A test case is a basic activity that is derived from test scenarios.

It is a comprehensive document that comprises all possible inputs (both positive and negative) as well as navigation instructions for the test execution process. Writing test cases is a one-time effort that can be reused for regression testing in the future.

The test case contains thorough information about the testing strategy, process, preconditions, and expected results. These are used during the testing process to see if the software application is capable of executing the purpose for which it was created.

By associating a defect with a test case ID, test cases assist testers in defect reporting. The testing team benefits from detailed test case documentation because if the developer misses something, it can be caught during the execution of these full-proof test cases. To construct the test case, we need the requirements to extract the inputs, as well as the test scenarios to ensure that we don't overlook any testing features. Then, to maintain uniformity, we should have a test case template, or every test engineer should prepare the test document in the same way.

Whenever the developer is busy writing code, we will usually write the test case.

Test Case vs. Test Scenario

The test situations are a little hazy and cover a lot of ground. It's all about being very specific when it comes to testing.

As an example of a test scenario, consider the following − Check Login Functionality There are a variety of test cases to consider −

• Test Case 1 − Check outcome on inserting valid User Id & Password

• Test Case 2 − Check the results of entering an invalid User ID and Password in Test Case 2.

• Test Case 3 − Examine the response when a User ID is blank and the Login Button is pressed, and many others.

These are all Test Cases.

When should a test case be written?

When we have the following information, we will write the test case −

• When the customer provides the business requirements, the developer begins work and estimates that the product will take 3.5 months to complete.

• Meanwhile, the testing group will begin writing the test cases.

• It will send it to the Test Lead for review once it is completed.

• The product is then handed over to the testing team once the developers have finished building it.

• Because testing is constant and does not depend on the mood of the person rather than the quality of the test engineer, test engineers never glance at the requirement while testing the product document.

Important − Because the product is still in development, the actual outcome should never be written when writing the test case. As a result, the actual result should be written only after the test cases have been completed.

Process of writing test cases

The procedure for writing a test case can be broken down into the following steps −

• System Study

• Consider all possible scenario

• Make test cases.

• Examine the test cases.

• Fix the fault found if any

• Approval of the test case

• Keep track of your test cases in the test case repository.

System study

• In this case, we'll look into the requirements or SRS provided by the customer to get a better understanding of the application.

Consider all possible scenario

• When the product is released, what are the various methods in which the end-user can utilize the software to determine all of the possibilities?

• In a document titled test design/high-level design, I have covered all conceivable scenarios.

• The test design is a database that contains all conceivable scenarios.

Make test cases

• Convert all discovered scenarios to test claims, grouping them according to their features, prioritizing the module, and writing test cases using test case design methodologies and the standard test case template, which is the one chosen for the project.

Examine the test cases

• Give the test case to the team leader to review, and then fix the review criticism provided by the reviewer.

Approval of the test case

• Send it back for approval after you've fixed the test case based on the input.

Keep track of your test cases in the test case repository.

• After the test case has been approved, store it in the test case repository, which is a familiar location.

Terms to be consider while writing a test case

When writing a test case, remember to provide the following details.

• What requirement is being tested is described in this section.

• The description of how the system will be put to the test

• The test setup, which includes information such as the hardware, security access, physical or logical date, version of the application under test, software, data files, operating system, time of day, prerequisites such as other tests, and any other setup information relevant to the requirements being tested.

• (Actions and expected outcomes) inputs and outputs

• Any attachments or proofs

• Make use of active case terminology

• There should be no more than 15 steps in the test case.

• Inputs, purpose, and expected results are all noted in an automated test script.

Best ways to write Test Cases

Test cases must be straightforward and simple

Make your test cases as simple as possible. They must be clear and straightforward because the test case author may not be able to perform them.

Use declarative language such as "go to the main page," "input data," "click here," and so on. This makes it easier to understand the test stages and speeds up the testing process.

Create a test case that considers the end user

Any software project's ultimate goal is to produce test cases that fulfil client requirements and are simple to use and run. A tester must write test cases from the standpoint of the end user.

Don't use the same test scenario twice

Test cases should not be repeated. If a test case is required for the execution of another test case, refer to it by its test case id in the pre-condition column

Do not make assumption

When creating a test case, don't make assumptions about the functioning and features of your software application. Follow the specifications in the specification documents.

Make certain you have complete coverage

Make sure you write test cases to ensure you've covered all of the software requirements in the specification document. To verify that no functions or conditions are left untested, use the Traceability Matrix.

Test Cases must be able to be identified

The test case id should be named in such a way that it may be easily identified later on for monitoring faults or identifying a software requirement.

Use Testing Methodologies

In your software application, you won't be able to verify for every possible scenario. Software testing approaches assist you in selecting a small number of test cases that have the best chance of detecting a flaw.

Self-cleaning

The test case you write must restore the Test Environment to its previous condition and should not render it unusable. This is particularly true when it comes to configuration testing.

Reliable and self-contained

Regardless of who evaluates the test case, the results should be consistent.

Peer evaluation

After you've finished writing test cases, have them reviewed by your coworkers. Your peers can spot flaws in your test case design that you might overlook.