Test Case Vs Test Script

A test case is a detailed document that outlines specific steps, prerequisites, input values, and expected outcomes to validate a particular functionality or feature of an application. Test cases are written in plain language to check if a system meets standards, guidelines, and customer requirements.

In contrast, a test script is a set of automated instructions or code written in a specific programming language or tool (for example, Selenium, Appium) to execute a series of actions on the application.

Test cases provide a high-level guide for testing, while test scripts focus on automating and executing the defined test steps for efficiency and consistency.

What is a Test Case

A Test Case is a document that contains the sequence of actions that validate if the application is working as per the business requirements. Test cases cover all software product features, from clicking a button and accepting input in a text box to checking for storage and a seamless user interface. A complete test case document has to include every possible combination of data and functionalities to be tested on an application before the final product is ready for roll-out.

Test cases give a clear picture of the business requirements of the application. Test case documenting is essential so the testers can recall the feature tested after a long gap. It helps in achieving uninterrupted software testing.

Test Case Prioritization is a vital step in writing test cases. Running all the test cases in a test suite requires a lot of time and effort. As the number of features increases, testing the entire suite for every build is practically impossible. Test case prioritization helps overcome these challenges.

Key Components of a Test Case

Here are the key components of a Test Case:

• Test Case ID: A unique identifier for the test case (for example, TC001, Login_01).
• Test Case Title: A brief and descriptive name summarizing the test case purpose (for example, “Verify Successful Login with Valid Credentials”).
• Objective: A concise statement describing what the test case aims to validate.
• Prerequisites/Preconditions: Conditions that must be met before the test case can be executed.
• Test Data: Input data or parameters required for the test.
• Test Steps: Step-by-step instructions for executing the test case.
• Expected Result: The anticipated outcome for each step or the final state.
• Actual Result: The observed outcome during test execution.
• Test Environment: Details of the hardware, software, network, and configurations used during the test.
• Severity/Priority: Indicates the criticality or urgency of the test case.
• Test Status: The result of the test case after execution.
• Attachments: Screenshots, logs, or any additional resources supporting the test case.
• Author: Name of the person who created the test case.
• Comments/Notes: Additional remarks or observations during execution.
• Related Requirements (Optional): Links to specific requirements the test case validates.
• Automation Status (Optional): Whether the test case is automated or manual.
• Test Type (Optional): Functional, Performance, Regression, etc.

Example of a Test Case

Let us understand how to write test cases with an example.

Let’s look at how to write a test case for an e-commerce website. Here the user is logged in and has checked out the items in the shopping cart. The test case is to check the four text boxes where the user inputs the Debit/Credit card number. The payment screen is where the user has to enter the Debit/Credit card details.

The above example is a Formal Test Case. Here, the document clearly instructs the tester to test specific functionalities with a set of prerequisites and test data. However, there are certain cases where a well-experienced tester tries out different test cases absent in the test case document. Through the tester’s experience, they might test a few random cases and try out various possible inputs to find bugs in the application. These types of cases are called Informal Test Cases. Informal test cases are written when the exact input and output are not known. In such times, the actions are performed, and the outcomes are recorded.

Best Practices to Follow While Writing Test Cases

1. Keep things simple and clear.
2. Define the preconditions clearly to avoid confusion.
3. The test cases are considered effective if they can be reused.
4. Test case IDs should be unique.
5. Always think from the end user’s perspective when you begin to write the test case.
6. Specify the expected results and post conditions.
7. Make sure you are not repeating test cases. It can easily happen in the urge to cover all the bases.
8. Refrain from cramming too much information in one test case. Split the test cases to avoid confusion.

Test Script

Test Scripts are step-by-step instructions on how to test a test case. They are detailed and contain individual steps that test for each and every functionality. Test scripts are programs that execute tests on the software product/application. The tester has to write and run the test scripts to validate if the application’s outcome meets the business requirements.

Test cases serve as a backbone for writing test scripts. A single test case can have multiple test scripts for different testing environments. While most test scripts identify with Automation testing, they can also be a part of manual testing. The testers write automated scripts that can generate data to test every functionality. Usually, the test scripts run automatically and check every test case with various possible input data. Python, Ruby, Perl, Java, VB Script etc are a few of the scripting languages used to write test scripts.

Once written, a test script can execute many test instances that test a single application function. Since the test scripts are more detailed and extensive than test cases, writing test scripts in a reusable format is an excellent practice to make the tester’s life easier.

Key Components of a Test Script

Here are some of the key components of a Test Script:

• Script ID: A unique identifier for the test script (e.g., TS001, Login_Script_01).
• Script Name: A descriptive title that summarizes the purpose of the script.
• Objective: A clear statement defining the goal of the test script.
• Prerequisites/Preconditions: Conditions or setup required before executing the script.
• Test Environment: Details of the system, platform, and configurations where the script will run.
• Test Data: Input values or parameters required for script execution.
• Test Steps: Detailed instructions or code that defines the sequence of actions to be executed.

• Expected Outcome: The anticipated result for each step or the overall execution.
• Actual Outcome: The observed result during execution (filled after running the script).
• Error Handling: Steps or mechanisms included to manage exceptions or failures.
• Log and Reporting: Details on how execution logs are captured and results reported.
• Version Control: Information about the script version and any updates or revisions.
• Author/Creator: Name of the person or team responsible for writing the script.
• Dependencies: Any external files, libraries, or systems required for the script to function.
• Execution Time: Estimated time required to execute the script.
• Reusability: Notes on whether the script can be reused across multiple test scenarios.
• Comments/Notes: Additional remarks or documentation about the script.
• Automation Tool: The specific tool or framework (e.g., Selenium, Appium) used to execute the script.

Example of a Test Script

Let us take the same example as above.

We have an e-commerce application where the user is logged in and has checked out the items in the shopping cart. He is now on the payment screen, where he has to enter his debit/credit card details. The script can be in any language of the tester’s choice by following the below steps.

Identify the text boxes or buttons or any element on the screen by its ID (For example, CSS element ID).

Continuing with the TC001 example use above.

1. Place the cursor on the first text box.
2. Type the first four digits.
3. Type the next four digits. The digits should automatically appear in the following text box. If this happens, the test status is ‘Pass’; if not, the test status is ‘Fail’.
4. The text boxes should accept all 16 digits split into four text boxes.
5. Check if there are four digits in the four text boxes. If yes, the test status is ‘Pass’; if not, the test status is ‘Fail’.
6. Check if the 16-digit input is of number data type. If yes, the test status is ‘Pass’; if not, the test status is ‘Fail’.

For the above script, the test data can be numbers, alphabets, special characters and a combination of all three. It ensures that the text box accepts only numbers and not any other data type.

This script can be coded in any scripting language with test data and executed to test the application for these functionalities.

Best Practices to Follow while Writing Test scripts:

Here are the best practices to follow while writing test scripts:

1. Test scripts cover a wide range of data. So, make sure that the scripts are reusable.
2. Test scripts should be updated with each change in requirements.
3. Follow proper naming conventions to ensure proper code maintenance. Make sure the names align with the application and the tested functionality.
4. The input of one test script should not depend on the output of another script so that multiple tests can run simultaneously.

Test Cases vs Test Script

Understanding the distinction between test cases and test scripts is essential for effective software testing, as they serve different purposes. Here is a comparison table for test case vs test script:

Talk to an Expert

Conclusion

Though the primary differences between test cases and test scripts have been established, in some instances, these terms are used in tandem or interchangeably. It is unique to the application being tested, and the practices followed within the project team.

However, the idea behind writing test cases and test scripts remains the same for any type of testing like Functional Testing, Unit testing, Regression testing, and Visual testing, to name a few. With the advent of developing applications to suit a variety of devices, there is immense pressure to test as many test cases as possible without missing out on any functionality or input.

BrowserStack Automate simplifies the execution of test scripts by enabling seamless automation across real devices and browsers, enhancing efficiency and scalability in testing. You can run Selenium, Cypress, Playwright,  Puppeteer, Appium, Espresso, and XCUITest tests on a combination of 3500+ browsers, devices, and operating systems.

Additionally, BrowserStack Test Management helps teams create, organize, and manage test cases effectively, ensuring streamlined workflows and comprehensive test coverage. Together, these tools empower teams to deliver high-quality applications faster.

Try BrowserStack now