Latest Technology Trends in Software Testing

Software testing is an essential part of the software development process, and it has evolved significantly over the years as new technologies and approaches have emerged. Here are some of the latest technology trends in software testing:

1. Artificial intelligence (AI) and machine learning (ML): AI and ML are being increasingly used in software testing to improve the efficiency and effectiveness of the testing process. For example, AI can be used to analyze test results and identify patterns that may indicate defects or other issues. ML can be used to create and execute test cases based on machine learning algorithms, which can help to identify previously unknown defects or test scenarios that may have been overlooked by human testers.
2. Continuous testing: Continuous testing is an approach that involves running automated tests continuously throughout the software development process. This helps to identify and fix defects early in the development process, which can reduce the overall cost of testing and improve the quality of the software. Continuous testing requires the use of automation tools and a culture of collaboration and continuous integration.
3. Test-driven development (TDD): TDD is a software development approach in which tests are written before the code is written. The goal of TDD is to ensure that the code meets the specified requirements and is of high quality. TDD can help to improve the quality of the software and accelerate the development process by identifying and fixing defects early in the development process.
4. Agile and DevOps: Agile and DevOps are software development methodologies that emphasize rapid iteration and continuous delivery of software. They both rely on automation to accelerate the development and testing process. Agile development is based on short development cycles (called "sprints") in which teams work to deliver incremental improvements to the software. DevOps is a culture and set of practices that emphasizes collaboration and communication between software developers and IT operations teams.
5. Cloud-based testing: Cloud-based testing involves using cloud-based platforms and tools to conduct software testing. This can help to reduce the cost and complexity of testing by eliminating the need to maintain on-premises testing infrastructure. Cloud-based testing also enables organizations to scale their testing efforts up or down as needed and to access a wide range of testing environments and configurations.
6. Mobile testing: The increasing use of mobile devices has led to the development of specialized tools and approaches for testing mobile applications. Mobile testing involves verifying that the software functions correctly on different mobile devices and operating systems. It may also involve testing the software's performance and usability on different mobile networks and under different conditions.
7. Internet of Things (IoT) testing: IoT testing involves verifying the functionality and performance of software that runs on IoT devices. This may include testing the software's ability to communicate with other devices and systems, as well as its ability to handle large volumes of data. IoT testing may also involve testing the security and privacy of the software.

Overall, these are just a few examples of the latest technology trends in software testing. It is important for organizations to stay up-to-date on these trends and to evaluate which ones are the best fit for their specific testing needs. By adopting the latest technologies and approaches, organizations can improve the efficiency and effectiveness of their testing efforts and deliver high-quality software to their customers.

Agile and DevOps, test automation, artificial intelligence for testing

Agile and DevOps are software development methodologies that emphasize rapid iteration and continuous delivery of software. They both rely on automation to accelerate the development and testing process.

Agile is a project management approach that emphasizes flexibility and rapid iteration. It is based on the Agile Manifesto, which values "individuals and interactions over processes and tools" and "working software over comprehensive documentation." Agile development is often characterized by short development cycles (called "sprints") in which teams work to deliver incremental improvements to the software.

DevOps is a culture and set of practices that emphasizes collaboration and communication between software developers and IT operations teams. It aims to reduce the time and effort required to deliver software by automating and streamlining the build, test, and deployment process.

Test automation is the use of software to automate the process of testing software. It involves creating and executing automated test cases to validate the functionality and performance of the software. Test automation can help to accelerate the testing process and improve the accuracy and reliability of test results.

There are many benefits to using test automation in the context of Agile and DevOps. For example:

Speed: Automated test cases can be run much faster than manual tests, which can help to accelerate the development and testing process.

Accuracy: Automated test cases are less prone to human error than manual tests, which can help to improve the accuracy and reliability of test results.

Coverage: Automated test cases can be designed to test a wide range of scenarios and edge cases, which can help to improve the coverage of the testing process.

Repeatability: Automated test cases can be run multiple times without the need for human intervention, which can help to ensure that the software is tested consistently and thoroughly.

Artificial intelligence (AI) can be used to enhance the process of testing software in a number of ways. For example, AI can be used to analyze test results and identify patterns that may indicate defects or other issues. This can help to improve the efficiency and effectiveness of the testing process by identifying potential issues more quickly and accurately.

AI can also be used to create and execute test cases based on machine learning algorithms. These algorithms can analyze the software and identify test scenarios that may have been overlooked by human testers. This can help to identify previously unknown defects and improve the coverage of the testing process.

In the context of Agile and DevOps, test automation and AI can be used to support the rapid iteration and continuous delivery of software. By automating the testing process and using AI to analyze and optimize test results, organizations can reduce the time and effort required to test software and accelerate the development and delivery process.

However, it is important to note that test automation and AI are not a substitute for human testing. While they can be very useful tools, they are not able to replicate the creativity and critical thinking skills of human testers. As such, it is important to use a combination of automated and manual testing to ensure that the software is thoroughly tested and of high quality.

Overall, the combination of Agile and DevOps, test automation, and AI can help organizations to develop and deliver high-quality software more efficiently and effectively. By leveraging these technologies, organizations can improve their ability to respond to changing market needs and deliver value to customers more quickly. However, it is important to carefully evaluate the suitability of these technologies for a given project and to use them in combination with human testing to ensure the best results.

What is Codeless Automated Testing?

Codeless automated testing is a testing approach that allows testers to create and execute automated test cases without the need to write code. Instead of writing code, testers use a visual interface or a set of pre-defined commands to create and execute test cases.

One of the main benefits of codeless automated testing is that it allows testers with limited coding skills to create and execute automated tests. This can help to accelerate the testing process and make it more accessible to a wider range of testers. For example, a tester who is not familiar with programming languages can still create and run automated tests using a codeless testing tool.

Another benefit of codeless automated testing is that it can reduce the time and effort required to maintain test cases. Since no code needs to be written, there is less need to update and maintain test cases as the software changes. This can help to reduce the overall cost of testing and make it more efficient.

There are several different tools and platforms available for codeless automated testing. These tools typically provide a visual interface or a set of pre-defined commands that testers can use to create and execute test cases. Some common features of codeless automated testing tools include:

Record and playback functionality: This allows testers to record their actions as they test the software manually, and then play them back automatically to create an automated test case.

Object recognition: This allows the tool to identify and interact with specific elements on the screen, such as buttons or input fields.

Test case management: This allows testers to organize and manage their test cases, including the ability to create and edit test cases, view test results, and track defects.

Test data management: This allows testers to create and manage test data, including the ability to create and edit test data, view test results, and track defects.

Integration with other tools: Many codeless automated testing tools can be integrated with other tools and platforms, such as defect tracking systems, continuous integration systems, and test management systems. This can help to streamline the testing process and make it more efficient.

While codeless automated testing can offer many benefits, it is important to note that it may not be suitable for all testing scenarios. In some cases, writing custom code may be necessary to fully test the software. For example, custom code may be required to test complex logic or to interact with third-party systems or APIs. Additionally, codeless automated testing may not provide the same level of flexibility and control as code-based automated testing.

Despite these limitations, codeless automated testing can be a useful approach for testers who want to create and execute automated tests without the need to write code. It can help to accelerate the testing process and make it more accessible to a wider range of testers, while also reducing the time and effort required to maintain test cases.

In conclusion, codeless automated testing is a valuable tool for testers who want to create and execute automated tests without the need to write code. It can help to accelerate the testing process and make it more efficient, while also making it more accessible to a wider range of testers. However, it is important to carefully evaluate the suitability of codeless automated testing for a given testing scenario, as it may not always be the best fit.

There are several codeless automation tools available in the market, each with its own unique features and capabilities. Some of the more popular codeless automation tools include:

Selenium IDE: This is an open-source browser extension that allows testers to record and play back test cases in the browser. It supports a wide range of browsers, including Chrome, Firefox, and Safari.

TestComplete: This is a commercial automated testing tool that allows testers to create and execute test cases for desktop, web, and mobile applications. It features an easy-to-use visual interface and supports a wide range of programming languages.

TestProject: This is an open-source automated testing platform that allows testers to create and execute test cases for web, mobile, and API applications. It features a visual interface and integrations with popular defect tracking and continuous integration tools.

UiPath: This is a commercial robotic process automation (RPA) platform that allows users to automate repetitive tasks by creating and executing automated workflows. It features a visual interface and integrations with a wide range of applications and systems.

Katalon Studio: This is a free, open-source automated testing platform that allows testers to create and execute test cases for web, mobile, and API applications. It features a visual interface and supports a wide range of programming languages.

Testim: This is a commercial automated testing platform that allows testers to create and execute test cases for web and mobile applications. It features a visual interface and integrations with popular defect tracking and continuous integration tools.

These are just a few examples of the many codeless automation tools available in the market. It is important to carefully evaluate the features and capabilities of each tool to determine which one is the best fit for your specific testing needs.

Defect/Bug Life Cycle

Defect Life Cycle:

• Defect life cycle, also known as Bug Life cycle is the journey of a defect cycle, which a defect goes through during its lifetime.
• It varies from organization to organization and also from project to project as it is governed by the software testing process and also depends upon the tools used.
• Defect Life Cycle is a cyclic process, which describes how a defect or bug passes through different stages from the identification stage to the Fixing stage. it begins when a tester finds or logs a bug and it ends when the bug is fixed.
• If Developer reject a defect understand the reason why defect is rejected , if developer is correct we can close the defect or else we can discuss it with test lead or project lead and than reopen the defect.

Some of the familiar values used for defects, during their life cycle are :

• New : New defect is reported.
• Open : The developer is currently working on the defect.
• Fixed : The code changes are completed and the defect is resolved .
• Deferred : Developers will fixed the defect later.
• Duplicate : The defect is same like one of the previous defect. When previous is fixed it also fixed.
• Retest : the tester starts the task of retesting the defect to verify if the defect is fixed or not.
• Rejected : Developers did not accept the defect .
• Close : After re test if defect is working correctly .
• Reopen : After re test if defect is still exist then we reopen the defect.
• Not a Bug : If the defect does not have an impact on the functionality of the application, then the status of the defect gets changed to “Not a Bug”.
• There are others of course, and some groups might use combinations of these values (such as Closed-Fixed, Closed-WontFix, etc.).

Defect Report | Priority and Severity

Defect Report: 

• If application is not working as expected we can report that as defect in defect report. 
• A defect report is a document that has concise details about what defects are identified, what action steps make the defects show up, and what are the expected results instead of the application showing error (defect) while taking particular step by step actions.
• Defect Reporting, Defect Tracking, and Status Tracking is called Defect Management. Some companies use Manual Process (Excel workbook), and some companies use Tool-based processes for Defect Management. 
• Defect Management Tools Examples: Bugzilla / Issue-Tracker / PR-Tracker etc.
  Important fields of a Defect Report template:
• Defect Id :  It is a unique number for every defect we found while testing.
• Summary :  Full description of the defect .
• Detected By : Name of the tester who found the defect .
• Assigned to :  Currently the defect is assign to whom. When a tester found a defect the it has to assign to any developer.
• Severity : Severity defines how impactful a bug can be to the system. It can values either high or medium or low specifies the seriousness of the defect.
• Priority : Priority indicates how soon the bug should be fixed. It can values either high or medium or low specifies the importance of the defect or functionality. The defect are fixed based on priorities.
  
  
  
  Defect Status in defect life cycle is the present state from which the defect or a bug is currently undergoing. The goal of defect status is to precisely convey the current state or progress of a defect in order to better track and understand the actual progress of the defect lifecycle. 
• Build version : It show currently build version in which we are testing. We  can check this from release note document. 
• Module : In which module the defect is found.
• Environment :  The defect is found in which environment like : Test environment, UAT or Production environment.
• Defect Type :  Specify the type of defect like functional , network , data , performance or UI ( User Interface) etc.
• Reproduceable : It has value either YES or NO:

                YES: Every time the defect is occurring .
                NO: Most of the time its working correctly, only few cases it is failing and not able to reproduce  

• ( If the defect is non reproduceable we can take screen shot of the defect and report it along with the defect.)
• Reproduce Steps : Specify the navigation steps to reproduce the defect.

Test Execution Process | Environment setup

Test Execution:

• Test execution is the process of executing the test cases and comparing the expected and actual results.
• After developers finish the coding and give the build to the tester , tester will conduct the testing and validate the application as per the requirement.
• The developers will prepare the below document and give to the testing team during the build release :

SRN (software release note)
DD (Deployment Document)

• Tester deploy the build in test environment a per the instruction in the release document note .
• The build is deployed in the test environment either by tester or developer or n/w team. 

• As we know after build release 1st test should be performed is sanity test .
• After Sanity test is pass we will continue test execution and validate all the functionality.
• Test execution can be done either manual aur automation.
• Testing performed by tester without using any tools is called manual testing.
• Testing conducted with the help of tool is called automation testing.
• During execution validate all the test cases and specify actual result and status.
• If the status is fail we can report that as defect to the developers.

SRN (software release note)

• A release note refers to the technical documentation produced and distributed alongside the launch of a new software product or a product update.
• It briefly describes a new product or specific detail level changes included in a product update.
• A software release notes template is a simple document that companies use to document any changes to their product. Elements of release notes template are like : 
• Build version , build location , requirement in build , Precondition , environment , deployment steps , known issue , defect files , prepare by.

Requirement Traceability Matrix

Traceability Matrix:

• In this document the test cases are mapped to the corresponding requirement to ensure the coverage of test cases, to find any gap between requirement and test cases.
• It is also known as Requirement Traceability Matrix (RTM) or Cross Reference Matrix (CRM).
• It is prepared before the test execution process.
• This document is designed to make sure that each requirement has a test case. 
• The test engineer will prepare TM for their respective assign modules, and then it will be sent to the Test Lead. Then test lead consolidate all and prepare one TM document for project.

Goals of Traceability Matrix:

• It allows you to see if a requirement is fully documented or not. A requirement traceability matrix can even call attention to missing requirements. 
• It ensures that the software completely meets the customer's requirements.
• A traceability matrix can help in the effort to provide proper and consistent documentation for your team. 
• It helps in detecting the root cause of any bug.

Types of Traceability Matrix:

The traceability matrix can be classified into three different types which are as follows:  

• Forward Traceability
• Backward or reverse Traceability
• Bi-directional Traceability

Forward Traceability:

Forward traceability is used to map the requirements to the test cases.

• Not only this will establish that every requirement is being tested from top to bottom, but it will also assist in confirming that a project’s trajectory is sound. 
• The main objective of this is to verify whether the product developments are going in the right direction.

Backward or reverse Traceability:

You can make a backward traceability matrix by mapping test cases with the requirements. 

• The reverse or backward traceability is used to check that we are not increasing the space of the product by enhancing the design elements, code, test other things which are not mentioned in the business needs. 
• The main objective of this that the existing project remains in the correct direction.

Bi-directional Traceability:

Bidirectional traceability essentially combines forward and backward traceability into one document. 

• This type is useful because it establishes that each requirement has relating test cases. 
• It also evaluates the modification in the requirement which is occurring due to the bugs in the application.

Test Case Review Process and Guidelines

 Test Case Review : 

• Test case review process is an important process to follow in software testing. Test case should be effective and also follow the standards to write test case.
• After preparation of the test cases review are conduct to ensure the completeness and correctness of the test case, proper flow, and maximum test coverage.
• The test lead or project manager have to approve the test cases.
• During this review process, if the reviewer found any mistake, he/she writes it in a separate document, which is known as Review document and sends it back to the author.

Test Case Review Techniques : 

• Self-review: This is carried out by the tester who wrote the test cases. By looking at SRS/FRD, he/she can see if all of the requirements are met or not.
• Peer review:  Before test lead the test cases reviewed by another team member who is not familiar with the system is called peer review. Maker and Checker are two other names for the same thing.
• Supervisory review: This is done by a team lead or project manager who is higher in rank than the tester who wrote the test cases and has an extensive understanding of the requirements and system.

Common mistakes which are check during Test Case Review  : 

• Incomplete Test Cases. Missing negative test cases. No Test Data. Inappropriate/Incorrect Test data.
• Spelling errors can sometimes cause a lot of confusion or make a statement difficult to grasp.
• While review process, it is very important to check whether all the standards and guideline are properly followed.
• If proper template is followed then it becomes easy to add/modify test cases in future and test case plan looks organized.
• If the grammar is incorrect, the test case can be misinterpreted, leading to incorrect findings. 
• Test cases should have a very simple language which is easy to understand.
• Replication: It refers to the duplicate test cases removal. It is possible that two or more test cases test the same thing and can be merged into one, this would save time and space.
• Test case which are uselessness due to change in requirements or some modifications. Such test cases must be removed.

Test Case Repository  : 

• A test case repository is a centralized location where all the baseline test cases (written, review, and approved) are stored.
• Test repository comprises test cases that encompass all key possibilities of permutations and combinations in workflow execution and transaction, ensuring that all variations in system and user interactions are covered.
• A test case repository is used to store the approved test cases only.
• Any test engineer wants to test the application, then he/she needs to access the test case only from the test case repository.
• If we do not require any test case, we can drop them from the test case repository.
• Each version have a separate test case repository.

Test Design Testing Techniques

 Test Design Testing Techniques :

•  BAV (Boundary Value Analysis )
•  ECP (Equivalence Class Partition)
•  Decision Table Based Testing
•  State Transition
•  Error Guessing Testing

1. BAV (Boundary Value Analysis):

•  The technique specify  to validate the boundary validation.
•  It is based on testing at the boundaries.
•  We will be testing both the valid and invalid input values in the BVA.

 Conditions are like :

              Min                       Max 

            Min-1                     Max-1

            Min+1                    Max+1

The above 6 conditions are enough.

BAV (Boundary Value Analysis ) Example:

Password field accept 6-32 character then we only test for :-

       Min : 6                Max  : 32

      Min-1 : 5             Max-1 : 31

      Min+1 : 7            Max+1 : 33

These 6 conditions are enough for password field testing.

2. ECP (Equivalence Class Partition):

• The technique specify to test for valid and invalid combination.
•  The idea behind this technique is to divide a set of test conditions into groups or sets that can be considered the same.
•  It  is a black-box testing technique or specification-based testing technique in which we group the input data into logical partitions called equivalence classes.

ECP Example:

Any mail id field accepts alpha and numeric data :

        Valid Data                                      Invalid Data

           A – Z                                           All special character 

           a – z 

           0 – 9 

If a Text field accept 1000 -1500 the partition should be:

         Valid Data                                      Invalid Data 

         1000 – 1500                                   a – z 

                                                                   A – Z

                                                                  Numbers < 1000

                                                                  Numbers > 1500

                                  All special character

3. Decision Table Based Testing:

• Decision table testing is a software testing technique used to test system behavior for different input combinations.
• In this methodology the various input combinations and the accompanying system behavior (Output) are tabulated.
• This is a systematic approach. 
• Decision Table Testing is a Black Box test design technique (behavioral or behavior-based technique).
• When a system has complex business rules, then the decision table testing technique helps in identifying the correct test cases.

Example:  How to Create a Login Screen Decision Base Table

Let's make a login screen with a decision table. A login screen with User id and Password Input boxes and submit button.

The condition is simple if the user provides correct username and password the user will be redirected to the homepage. If any of the input is wrong, an error message will be displayed.

T –  Make sure to use Correct username/password

F – Incorrect username/password

E – An error message is displayed

H – The home screen is displayed

Interpretation:

 Case 1 – Username and password both were correct, and the user navigated to homepage

 Case 2 – Username was correct, but the password was wrong. The user is shown an error message.

 Case 3 – Username was wrong, but the password was correct. The user is shown an error message.

 Case 4 – Username and password both were wrong. The user is shown an error message.

While converting this to test case, we can create 2 scenarios :

First one :

Enter correct username and correct password and click on Submit button, and the expected result will be the user 

Should be navigated to homepage.

Second one from the below scenario: 

• Enter Correct username and incorrect password and click on Submit button, and the expected result will be the user should get an error message.
• Enter incorrect username and incorrect password and click on Submit button, and the expected result will be the user should get an error message.
• Enter incorrect username and correct password and click on Submit button, and the expected result will be the user should get an error message.

As they essentially test the same rule.

4. State Transition:

• State transition testing helps to analyze behavior of an application for different input conditions.
• In this test outputs are triggered by changes to the input conditions or changes to 'state' of the system.
• In other words, tests are designed to execute valid and invalid state transitions.
• Testers can provide positive and negative input test values and record the system behavior. It is the model on which the system and the tests are based.
• It is a black box testing which is used for real time systems with various states and transitions involved.

When to Use State Transition?

• This can be used when a tester is testing the application for a finite set of input values.
• When we have sequence of events that occur and associated conditions that apply to those events
• This will allow the tester to test the application behavior for a sequence of input values. 

When to Not Rely On State Transition?

• When the testing is not done for sequential input combinations.
• If the testing is to be done for different functionalities like exploratory testing.

Example:

Let’s consider an Login page function where if the user enters the invalid password three times the account will be locked.

In this system, if the user enters a valid password in any of the first three attempts the user will be logged in successfully. If the user enters the invalid password in the first or second try, the user will be asked to re-enter the password. And finally, if the user enters incorrect password 3rd time, the account will be blocked.

In the table when the user enters the correct PIN, state is transitioned to S5 which is Access granted. And if the user enters a wrong password he is moved to next state. If he does the same 3rd time, he will reach the account blocked state.

5. Error Guessing Testing:

• Testing is conducted by performing invalid operations and validate the error massage is displaying or not .
• The Error massage should meaningful to understand.
• It is a type of testing method in which prior experience in testing is used to uncover the defects in software. It is an experience based test technique in which the tester uses his/her past experience or intuition to gauge the problematic areas of a software application.

Example:

• We need to test a program which read’s a file. What happen if the program gets a file which is empty OR  The file does not exist??? 
• Enter blank space into text fields
• Use max limits of files to be uploaded

Please watch below video for more details:

All you need to know about test cases

 Test Case Design 

• Test case design refers to how you set-up your test cases. It is important that your tests are designed well, or you could fail to identify bugs and defects in your software during testing.
• It is responsibility of a tester to design the test cases.
• To design the test cases tester should :
• Understand the requirement 
• Identify the scenario
• Design the test case 
• Review the test case 
• Update the test case based on review 

How to create good test cases 

• Test Cases need to be simple steps, transparent and easy to understand.
• Each and every test case should be traceable and it should be linked to “Requirement ID”.
• Test cases should have only necessary and valid steps(Brief And Short) .
• Implement Testing Techniques – Positive And Negative Test Cases
• Test cases should be written in such a way that it should be easy to maintain.
• Test cases should cover the usability aspects in terms of ease of use.
• Different set of test cases should be prepared for the basic performance testing like multi-user operations and capacity testing.
• Test cases for Security aspects should be cover for example user permission, session management, logging methods.

Test cases Design Format:

Follow below steps to create Test cases 

Test Case Id : It is a unique number to represent each test cases. It’s good practice to follow some naming convention for better understanding and discrimination purposes. Like   Tc_proj_module_number(001)

For example: Tc_Yahoo_Inbox_001

Test Scenario :  A Test Scenario is defined as any functionality that can be tested. It is a collective set of test cases which helps the testing team to determine the positive and negative characteristics of the project. Test Scenarios are derived from test documents such as BRS and SRS.

Test Cases : A Test Case is a set of actions executed to verify a particular feature or functionality of your application. Test Cases are focused on what to test and how to test. Test Case is mostly derived from test scenarios.

Precondition :  The condition to be satisfied to test the requirement. Conditions that need to meet before executing the test case.

Priority :  The importance of the test case is called priority. It is a parameter to decide the order in which defects should be fixed. Priority means how fast defect has to be fixed.

Test Steps :   Test Steps describe the execution steps. To execute test cases, you need to perform some actions. Each step is marked pass or fail based on the comparison result between the expected and actual outcome.

Test Data:  It is data created or selected to satisfy the execution preconditions and inputs to execute one or more test cases. We need proper test data to execute the test steps.

Expected result :  The output result as per customer requirement (As per SRS or FRS). The result which we expect once the test cases were executed. 

Post Condition :  Conditions that need to achieve when the test case was successfully executed.

Actual Result :  The output result in the application once the test case was executed. Capture the result after the execution. Based on this result and the expected result, we set the status of the test case.

Status :  The status as Pass or Fail based on the expected result against the actual result. If the actual and expected results are the same, mention it as Passed. Else make it as Failed. If a test fails, it has to go through the bug life cycle to be fixed.

Other important fields of a test case template:

Project Name: Name of the project the test cases belong to.

Module Name: Name of the module the test cases belong to.

Reference Document: Mention the path of the reference documents (if any such as Requirement Document, Test Plan , Test Scenarios, etc.,)

Author (Created By) : Name of the Tester who created the test cases.

Date of Creation: When the test cases were created.

Date of Review: When the test cases were reviewed.

Reviewed By: Name of the Tester who created the test cases.

Executed By: Name of the Tester who executed the test case.

Date of Execution: When the test case was executed.

Comments: Include value information which helps the team.

Please refer below video on test cases:

Please refer below video on real time test case template: