Test Scenario Template and Test Case Template

-

Test Scenario ​: ​

A Scenario is any functionality that can be tested. It is also called Test Condition, or Test Possibility. 
 
Test Scenario Template :  
● Test Scenario ID  
● Test Scenario name 
● Objective 
● Pre-Condition 
● Test Condition  

Test Scenario ID ​: 
​Each test Scenario should have a unique ID.  
Test Scenario name ​: ​
The title is important because it’s often the first or only thing you see when you are scanning a list of Test Scenarios.Clear titles are the key to help testers to find quickly the right test Scenario.  
Objective​ : ​
To mention the functionality name of the test scenario.  
Pre-Condition ​: ​
Any requirement that needs to be done before the execution of this test case.  
Test Condition​ : ​
Test Steps section gives the tester a numbered list of the steps to perform in the system, which makes it easier to understand the test Scenario. It is recommended to have 3-8 test steps per one test Test Scenario. Too many steps make it difficult for developers and testers to reproduce the steps when a bug report is filed against the test Test Scenario. 
  

Test Case​ : ​

A test case is the smallest unit of the testing plan which includes a description of necessary actions and parameters to achieve and verify the expected behavior of a particular function or the part of the tested software.
  
Test Case Template​ :  
● Test case ID 
● Test case objective 
● Pre-condition 
● Step ID 
● Step ​Description 
● Input data 
● Expected result 
● Actual result 
● status 

Test case ID ​: ​
Each test case should have a unique ID.  
Test case objective ​: ​
To mention the functionality name of the test case.  
Pre-condition​ : ​
Any requirement that needs to be done before the execution of this test case.  
Step ID​ : ​
Test Steps section gives the tester a numbered list of the steps to perform in the system, which makes it easier to understand the test case.  
Step ​Description​ : ​
Step description in which we describe each step details which we are going to perform during testing.    
Input data ​: ​
You can enter test data directly in the test data field, or refer to a separate file that contains test data for one or more test cases.  
Expected result ​: 
​Mention the expected result including error or message that should appear on the screen. The tester needs to know the expected result in order to assess whether the test case is successful. The optimal level of detail in this field varies from situation to situation.  
Actual result ​: ​
What would be the state of the system after running the test case as per client requirement?  
Status ​:  
​Mark this field as failed, if the actual result is not the same as the expected result.

Comments

Post a Comment

Popular posts from this blog

Implicit and Explicit requirements

-
Implicit and Explicit requirements Explicit Requirements​ :    ● The Things business analyst Wrote Down.  ● These are the requirements explicitly stated or mentioned by the customer.  ● Explicit requirements are most commonly found in documents communicated by stakeholders to the development team.   ● This is the simplest type and the easiest to test.  ● The development team might take the form of an elaborate design specification, a set of acceptance criteria.  ● Explicit requirements in the form of claims that is, communications to end-users about things the software can do.   Implicit Requirements​ :  ● The Things client Will Expect  ● These are the requirements that are not explicitly stated by the customer, but implied or derived from the requirement stated by the customer.  ● These are all the things that users are going to expect that were not captured explicitly.  ● Examples include performance...
Read more

Software Configuration Management (SCM)

-
Software configuration management (SC) is a software engineering discipline consisting of standard processes and techniques often used by organizations to manage the changes introduced to its software products. SC helps in identifying individual elements and configurations tracing changes and version selection control and baselining.   SC is also known as software control management. SC aims to control changes introduced to large complex software systems through reliable version selection and version control.   Software Configuration Management does​ ​   ● Introduction to Software Configuration management and Configuration management for software Testers.  ● Software configuration management (SC) is the discipline for systematically controlling the changes that tae place during Software evelopment.  ● Software development software consists of a collection of items (such as program documents etc..) that can easily be changed. uring software...
Read more

Identified for Configuration Management

-
The term configuration item (CI) refers to the fundamental structural unit of a configuration management system. Examples of CIs include individual requirements documents software models and plans. The configuration-management system oversees the life of the CIs through a combination of processes and tools by implementing and enabling the fundamental elements of identification change management status accounting and audits. This system aims to avoid the introduction of errors related to lack of testing as well as incompatibilities with other CIs.     Configuration Management Activities ​:     1. ​Configuration Item Identification ​:  ​In this phase, the item will be identified for making changes.  Example: ​Requirement document design document source code etc    2. ​Change Control ​: ​ Controlling the release and changes of the product throw out the software life cycle here CCB team will approve or disapprove changes prioritize the change...
Read more