What Is The Test Case?

Many teams have problems with their testing processes. The general error here is; It is a misunderstanding of the concepts found in the testing processes. I believe that there is no one right way in this process. But understanding the concepts will provide us with a more understandable process. In this article, I will try to explain these concepts to you. I will give some examples in life about this process.

Test cases describe how to test a system, software, or application. A test case is a singular set of actions or instructions that a tester must perform that validates a particular aspect of a product or app functionality. If the test fails, the result may be a software bug that the organization can prioritize.

A tester or QA professional typically writes test cases that run after the completion of a feature or set of features that make up the release. Test cases also verify whether the product meets the software requirements.
A group of test cases is organized in a test suite that tests a logical part of the application, such as a particular feature.

Types of Test Cases

To validate and validate system functionality, the organization must take a multifaceted approach that evaluates the front-ends and back-ends of the product. There are different ways to categorize various test cases.

Formal Test Cases

In such test scenarios, the tester writes a test where the inputs such as prerequisites and test data are all known and detailed. Formal tests have predefined inputs, which means they provide an expected output that the test is trying to validate.

For example in life, we want to test an elevator. Let’s assume that we are given information about what action will be taken on which key is pressed. And let’s test based on this information. The elevator will go to the first floor when the button that says “1” is pressed. In our formal test case, the inputs for this process and the result are clear and we check whether we go to the first floor.

Informal Test Cases

Conversely, informal test cases have no known inputs or outputs. Testers run such test scenarios to discover and record results that could reveal interesting findings about digital quality.

For example in life, Let’s test an elevator again. Let’s examine if the elevator moves up and down. You thought that input is required in this. But we will not check that it goes up when a key is pressed, but only if it moves up. So press the key you want. If you see it go up, the test is successful. As you can see, we didn’t need input to test this situation.

Most test case types are formal — preplanned based on software requirements.

Test case types :

• Functionality
• User Interface
• Integration
• Performance
• Usability
• Database
• User Acceptance
• Exploratory

I will explain these types in detail in another article.

Test Case Results

While the purposes of test cases differ, most formal ones have predictable results. The typical test case format should detail the expected and actual results, which the test itself validates.

Most test case results :

• Pass
• Fail
• n/a
• Blocked

Successful and unsuccessful tests indicate that the system has succeeded or failed in this attempt. These results should not be confused with tests designed to be positive or negative, which may pass or fail. Positive tests allow users to go through all the steps and pass the expected result when the input is correct. Negative tests ensure that the system correctly handles invalid input, such as disallowing a login if a password is incorrect. Both types of tests either pass or fail depending on the expected result.

Test results marked as not executed, as the name suggests, are tests that have not yet run or will not run as part of this round of testing. Blocked tests are caused by an external condition or precondition that prevents the test from running. For example, a system failure that prevents functionality from being available will result in a blocked test, such as a misconfigured test environment.

For example in life, Above, we tested the elevator in certain conditions. Now let’s examine these test results.

In the example I gave for the Formal Test Case, we pressed the number 1 button and went up to the first floor. Let’s consider two cases for this scenario.
Case 1(Positive Test):
“We have to go to the first floor when button 1 is pressed”
Test Result:
Pass: if the elevator went up to the first floor and stopped
Perpetrator: elevator failed to reach the first floor or went to another floor
n/a: The test could not be performed because there is no elevator in the building.
Blocked: the elevator will be repaired. and waiting for the repair to be finished to test it.

Case 2(Negative Test):
“When the door open button is pressed while the elevator is in motion, the door should not be opened.”
Note: Since this case is negative, the test is valid in negative cases. In other words, even if the door does not open seems like a negative situation, the test is successful when the door is not opened, since this is the desired situation.
Test Result:
Pass: If the door is not opened while moving
Perpetrator: If the door is opened
n/a: The test could not be performed because there is no elevator in the building.
Blocked: the elevator will be repaired. and waiting for the repair to be finished to test it.

Test Case Format

Test case documents typically contain all relevant information for running the test and collecting data from the test. While the specific test case format differs between organizations, most include the following details:

• Module Name: This is the module or feature being tested.
• Test ID or Name: This is a unique identifier that must follow a standard naming convention.
• Test User Name: The person doing the test.
• Test Data: This describes the datasets to be used for testing.
• Assumptions or Preconditions: Explain the various steps that must be performed before the test, or what we can state situationally assume about the test, such as “after a successful login”.
• Test Priority: Identify whether the test is low, medium, or high priority.
• Test Scenarios: As explained above, this is the high-level action from which the test case derives.
• Test Environment: Define the name and/or properties of the environment to be tested.
• Test Steps: Detail the steps that the tester must follow in the desired order.
• Expected Results: This is the output you expect to get from the system.
• Actual result: This is the output you get from the system.
• Pass/fail determination: If the actual results match the expected results, the test is successful. If not, the test will fail.

By following the test case format above, the organization can adhere to a standard method of writing tests, which is useful during maintenance. The organization should regularly review, maintain and approve test cases to ensure they adequately cover new and legacy functionality. Fully detailed test cases reduce the need for time-consuming exploratory testing to fill coverage gaps.

For example in life; We’ve been testing an elevator for some time now. However, we were not given any information about this elevator. First, we need to know what kind of elevator we are testing (with automatic door, sliding door, touch screen, etc.)
After this information, another important piece of information is the details of our cases. I have explained the necessary details above. Let’s think of a few questions for our elevator frames and try to answer these questions according to the information above.
- Who tested the elevator?
- What information is required before starting the test?
- Is preparation necessary? If necessary, what are they?
- Test priority?
- How should the test steps be?
When we look at these questions, we see how many parts remain unanswered. If we fill in the above fields, these questions will not return to us as time costs.

Writing Test Cases Efficiently

Well-written test cases have benefits; good quality products, higher profits(time and money), and easier test maintenance.
However, it takes some effort and organization to write test cases that help achieve these goals.

Generally, the tester should write test cases early in the SDLC (System Development Life Cycle) and during the requirements-gathering phase. Testers should refer to the requirements and use case documentation as well as the overall test plan when writing test cases. A prototype can also tell the tester what the feature or functionality will look like when complete.

Once the tester has all this information, they can start writing the various test cases mentioned above. When writing test cases, the tester must consider application flows — how the user arrives at application functionality is an important element of their journey and should be properly validated.

Write test cases clearly and concisely to ensure accuracy no matter who reads and performs the test. While some details are important, aim to keep test cases economical and highly easy to execute to reduce maintenance when the application changes. Well-written test cases should also be repeatable and reusable; several tests are run only once, and reusable tests can save time when developing additional functionality. Make each traceable so documents and results can easily inform the team.

Test Case Management

One way to make sure test cases are easy to find and understand is to give them a thorough review. The naming conventions and descriptions of test cases should be consistent. The sanity check can also reveal whether the author’s “simple” explanation of the testing steps makes sense to another reader and reflects real-world conditions.

The larger the scope of a product, the larger the footprint of test cases. Simply put, the more you develop, the more you have to test, which can cause difficulties in scaling test suites. Test cases need to keep up with new functionality, and the need for regression testing means legacy test cases also need updates.

Test management tools or products can help organizations monitor and update tests as needed. There are so many options for test management tools. Ultimately, the best option is the one that fits as seamlessly into your workflows as possible, allowing the team to view, interpret, and access audit trails.

Reporting is an important element of test case management. Test case reports should give the team actionable information on how testing is progressing, what scope you have, and where the team can improve in the future.

While managing test suites can be daunting, maintaining digital quality for your products is ultimately a necessary task. If the task is difficult to maintain internally, look for tools or services to help you get on with it.

For example in life, In some of our cases, we could not test it because the elevator was repaired. This is actually a matter of planning and management. The processes from the moment we start creating cases to the moment we test them should be planned. Of course, there can be setbacks. We may encounter unexpected situations. However, in order to minimize these situations, we should use the time when the repair is finished, not the time the elevator is repaired, to test it. Maybe the elevator was not repaired correctly and this will give us the wrong result!

I am trying to explain the Test Case in this article. We will keep together about QA. I hope, this article can help you.
See you next time!