What is Business Process Testing on QC

Business Process Testing is a role-based testing model that enables Subject Matter Experts—who understand the various parts of the application being tested—to create business process tests in Quality Center. Automation Engineers—who are experts in QuickTest and automated testing—use QuickTest to define all of the resources and settings required to create business process tests. Integration between QuickTest and Quality Center enables the Automation Engineer to effectively maintain the resources and settings, while enabling Subject Matter Experts to implement business process tests.

Business Process Testing uses a keyword-driven methodology for testing, based on the creation and implementation of business components and business process tests. A business component is an easily-maintained, reusable unit comprising one or more steps that perform a specific task within an application. A business process test comprises a series of business components, which together test a specific scenario or business process. For example, for a Web-based application, a business process test might contain five components—one for logging on to the application, another for navigating to specific pages, a third for entering data and selecting options in each of these pages, a fourth for submitting a form, and a fifth component for logging off of the application. Business components and business process tests are generally created in Quality Center by Subject Matter Experts, although Automation Engineers can also create business components in QuickTest.

Components in QuickTest Professional

QuickTest enables you to create and modify two types of components: business components and scripted components. A business component is an easily-maintained, reusable unit comprising one or more steps that perform a specific task. A scripted component is an automated component that can contain programming logic. Scripted components share functionality with both test actions and business components.

Automation Engineer. The Automation Engineer is an expert in using an automated testing tool, such as QuickTest Professional. The Automation Engineer works with the Subject Matter Expert to identify the resources that are needed for the various business process tests.

The Automation Engineer then prepares the resources and settings required for testing the features associated with each specific component, and stores them in an application area within the same Quality Center project used by the Subject Matter Experts who create and run the business process tests for the specific application.

Each application area serves as a single entity in which to store all of the resources and settings required for a component, providing a single point of maintenance for all elements associated with the testing of a specific part of an application. Application areas generally include one or more shared object repositories, a list of keywords that are available for use with a component, function libraries containing automated functions (operations), recovery scenarios for failed steps, and other resources and settings that are needed for a component to run correctly. Components are linked to the resources and settings in the application area. Therefore, when changes are made in the application area, all associated components are automatically updated.

The Automation Engineer uses QuickTest features and functionality to create these resources from within QuickTest. For example, in QuickTest, the Automation Engineer can create and populate various object repositories with test objects that represent the different objects in the application being tested, even before the application is fully developed. The Automation Engineer can then add repository parameters, and so forth, as needed. The Automation Engineer can manage the various object repositories using the Object Repository Manager, and merge repositories using the Object Repository Merge Tool. Automation Engineers can also use QuickTest to create and debug function libraries containing functions that use programming logic to encapsulate the steps needed

Business Process Testing Terminology

Application Area. A collection of resources and settings that are used for the creation and implementation of business components. These include function libraries, shared object repositories, keywords, testing preferences, and other testing resources, such as recovery scenarios. An application area provides a single point of maintenance for all elements associated with the testing of a specific part of your application. You can define separate application areas for each part of your application and then associate your components with the appropriate application areas.

Business Component (or Component). An easily-maintained, reusable unit comprising one or more steps that perform a specific task. Business components may require input values from an external source or from other components, and they can return output values to other components.

Also known as Keyword-Driven Component.

Manual Component. A non-automated business component created in Quality Center. In QuickTest, you can view and work with manual components only after converting them to automated business components.

Scripted Component. An automated component that can contain programming logic and can be edited in QuickTest using the Keyword View, the Expert View, and other QuickTest tools and options.

Keyword View. A spreadsheet-like view that enables tests and components to be created, viewed, and debugged using a keyword-driven, modular, table format.

Function Library. A document containing VBScript functions, subroutines, modules, and so forth. These functions can be used as operations (keywords) in components. You can create and debug function library documents using the QuickTest function library editor.

Business Process Test. A scenario comprising a serial flow of business components, designed to test a specific business process of an application.

Component Input Parameters. Variable values that a business component can receive and use as the values for specific, parameterized steps in the component.

Component Output Parameters. Values that a business component can return. These values can be viewed in the business process test results and can also be used as input for a component that is used later in the test.

Local Input Parameters. Variable values defined within a component. These values can be received and used by a later parameterized step in the same component.

Local Output Parameters. Values that an operation or a component step can return for use within the same component. These values can be viewed in the business process test results and can also be used as input for a later step in the component.

Roles. The various types of users who are involved in Business Process Testing.

Automation Engineer. An expert in QuickTest Professional automated testing. The Automation Engineer defines and manages the resources that are needed to create and work with business components. The Automation Engineer creates application areas that specify all of the resources and settings needed to enable Subject Matter Experts to create business components and business process tests in Quality Center. The Automation Engineer can create and modify function libraries, and populate a shared object repository with test objects that represent the different objects in the application being tested. The Automation Engineer can also create and debug business components in QuickTest.

Subject Matter Expert. A person who has specific knowledge of the application logic, a high-level understanding of the entire system, and a detailed understanding of the individual elements and tasks that are fundamental to the application being tested. The Subject Matter Expert uses Quality Center to create and run components and business process tests.

QuickTest Professional for Business Process Testing

Business Process Testing is a role-based testing model. It enables Automation Engineers and Subject Matter Experts to work together to test an application's business processes during the application's development life cycle.

Automation Engineers are experts in automated testing. They use QuickTest to define the resources and settings needed to create components, which are the building blocks of business process tests.

Subject Matter Experts understand the various parts of the application being tested, as well as the business processes that need to be tested, however they may not necessarily have the programming knowledge needed to create automated tests. They use the Business Components and Test Plan modules in Quality Center to create keyword-driven business process tests.

Creating a Library Component Using SAP Test Acceleration and Optimization

You can use the SAP Test Acceleration and Optimization framework outside of components provided during implementation. SAP Test Acceleration and Optimization RTL documentation is provided with the SAP Test Acceleration and Optimization installation. This guide includes a list of the functions in the framework, as well as best practices for creating new functions in the framework. 6 Additional Information 38 October 2009
Customer modifications are made in the file

CBASE_Custom_Wrappers.vbs, which should be the only one containing customized client functions. This will allow SAP to provide better support, and keep a standard framework.
If you want to modify functions in the framework, you have to copy the original function into the file CBASE_Custom_Wrappers.vbs and modify it there.

If you want to modify functions in the framework, you have to copy the original function into the file CBASE_Custom_Wrappers.vbs and modify it there.
Standard Wrapper layout example:
Sub SAP_Wrapper_Name(FieldName, FieldValue, ReportingName)
SAP_Wrapper_Name_Location FieldName, 1, FieldValue, ReportingName
End sub
Sub SAP_Wrapper_Name_Location(FieldName, FieldIndex, FieldValue, ReportingName)
On error Resume Next
Dim OBJ
SET Obj = SAP_GetObject(FieldName, FieldIndex, "FIELDTYPE","SET/GET")
OBJ.Method FieldValue
ReportLog "INFO", "Step Description", ReportingName & " = " & FieldValue
CheckErrorHandler()
End sub

SAP TAO – Architecture

Under Development


 SAP test acceleration and optimization requires the following components:

An ABAP based component that resides on your SAP ERP server, called the SAP TAO agent for ABAP, the agent accesses data from your PC.

 A run library that provides special business process testing business for use with the HP QC. This library resides on a shared drive that all HP QC clients can access.

 SAP TAO client is the graphical user interface that performs three key functions: inspecting transactions from SAP server, exploring the transactions to the HP QC, and consolidating components or scripts from the QC.

  <Image>

UI scanner is an optional add-in to the HP QTP. The UI scanner scans most of the data in a UI screen, including dynamically generated scripts objects. It then imports the screen information to the HP QC, where add the data to a specific test scripts.

  <Image>

SAP TAO Modules

Process flow Analyzer (PFA) - Records all user interactions and the sequence of screens to execute a business process, in the SAP Tao repository. It automates inspection and creation of components.

Inspect – Captures -Captures the data in a screen o transaction and determines its visibility. It enables you to add, maintain and delete a list of transactions and screen from this list

  <Image>

Consolidated -Gather all the objects and data in an HP QC test, and creates a single component

Import/Export -To transfer data from the SAP TAO client to HP QC

  <Image>

Change Analyzer

Automatic identification of impacted components and test cases from a Business Process change Analyzer result and their reparation.

 <Image>

Repository

Deals with user interactions and the sequence of screens in a business process information specific to SAP TAO that can not retrieved by other tools.

 <Image>

 <Image>

Fiddler PowerToy - for Load runner

Fiddler PowerToy - Part 1: HTTP Debugging

Summary: Learn how to use the Microsoft Fiddler HTTP debugger when developing and testing Web applications and clients. (7 printed pages)

Contents

Introduction
Getting Started
Using Fiddler
Using Fiddler for Performance Testing
Using Fiddler for Debugging
Extending Fiddler
To be continued...

Introduction

Have you ever found yourself wondering how Microsoft Internet Explorer interacts with your Web application? Have you encountered a strange performance bottleneck that you can't track down? Are you curious about which cookies are being sent, or what downloaded content is marked as cacheable?

Microsoft Fiddler can help you answer these questions, and many more. Fiddler is an HTTP debugging proxy that logs all HTTP traffic between your computer and the Internet. Fiddler enables you to inspect all HTTP traffic, set breakpoints, and "fiddle" with incoming or outgoing data. Fiddler is much simpler to use than NetMon or other network debuggers because it exposes only HTTP traffic and does so in a user-friendly format.

Fiddler includes a simple but powerful Microsoft JScript .NET event-based scripting subsystem flexible enough to support a broad array of HTTP debugging tasks. Written in C# on the Microsoft .NET Framework, Fiddler is available as an unsupported PowerToy for Internet Explorer.

Getting Started

Installation

• Fiddler requires Microsoft Windows 2000 or above, and approximately 10 megabytes of disk space.
• First you'll need to ensure that you have the .NET Framework version 1.1 installed. If you don't have it yet, you can visit Windows Update to download it.
• Next, download Fiddler from http://www.fiddlertool.com.
• When installation successfully completes, you'll find the Fiddler icon <쪴Ϫ>on the Internet Explorer toolbar.
• If the toolbar icon is missing, right-click the Internet Explorer toolbar and click Customize. You can also launch Fiddler from the Start menu.

Running Fiddler

After you start Fiddler, the program registers itself as the system proxy for Microsoft Windows Internet Services (WinInet), the HTTP layer used by Internet Explorer, Microsoft Office, and many other products. You can verify that Fiddler is correctly intercepting requests by checking the Proxy Settings dialog. From the Internet Explorer main menu, click Tools, click Internet Options, click Connections, click LAN Setting, and finally click Advanced.

Figure 1. Internet Explorer proxy settings

As the system proxy, all HTTP requests from WinInet flow through Fiddler before reaching the target Web servers. Similarly, all HTTP responses flow through Fiddler before being returned to the client application.

Figure 2. HTTP traffic flow

When you close Fiddler, it unregisters itself as the system proxy before shutting down.

Using Fiddler

Views

Fiddler's user interface contains a list of HTTP sessions and three tabs that allow you to view different aspects of the selected sessions.

Figure 3. The Fiddler user interface

Using Fiddler for Performance Testing

HTTP Statistics view

By exposing all HTTP traffic, Fiddler easily shows which files are used to generate a given page. Using the Statistics page, the user can multiselect to get a "total page weight"—the number of requests and the bytes transferred.

Figure 4. Statistics view

Additionally, by exposing HTTP Headers in the Session list, the user can see whether pages are missing HTTP Expiration headers that permit client or proxy caching. If a response does not contain Expires or Cache-Control headers, it might not be cached by the client.

Figure 5. HTTP Expiration column

Using Fiddler for Debugging

In addition to seeing all HTTP requests and responses, Fiddler supports the notion of breakpoints. When the Enable Single Step Debugging option is checked on the Rules menu, or when the properties of the HTTP Request or Response match the target criteria, Fiddler can pause HTTP traffic and allow edits. This feature proves useful for security testing, as well as for general functionality testing, because all code paths can be exercised.

Figure 6. Session Inspector view

Users can handcraft an HTTP request on the Builder page, or they can use a drag-and-drop operation to move an existing request from the session list to the Builder page to execute it again.

Extending Fiddler

Fiddler is extensible using the .NET Framework. There are two primary mechanisms for extending Fiddler: Custom Rules and Inspectors.

Extending Fiddler Using Scripted Rules

Fiddler supports a JScript .NET event-handling engine that allows the user to automatically modify the HTTP request or response. The engine can modify the visual appearance of the session in the Fiddler user interface (UI), to draw attention to errors or to remove uninteresting sessions from the list altogether.

The following sample code changes the UI to purple to show where cookies are uploaded.

static function OnBeforeRequest(oSession:Fiddler.Session)

{

   if (oSession.oRequest.headers.Exists("Cookie")){

      oSession["ui-color"] = "purple";

      oSession["ui-bold"] = "cookie";

   }

}

Extending Fiddler by Adding Inspectors

The user can add plug-in Inspector objects written in any .NET language. RequestInspectors and ResponseInspectors provide a format-specific or an otherwise specialized view of the HTTP request or response.

Inspectors can be read-only (RO) or read-write (RW). If an Inspector is read-write, it can be used to modify the HTTP request or response before the server or the client receives it.

By default, Fiddler ships with the following Inspectors:

Request Inspectors

• [RW] Headers—Shows request headers and status.
• [RW] TextView—Shows the request body in a text box.
• [RW] HexView—Shows the request body in a hexadecimal view.
• [RO] XML—Shows the request body as an XML DOM in a tree view.

Response Inspectors

• [RW] Transformer—Removes GZip, DEFLATE, and CHUNKED encodings for easier debugging.
• [RW] Headers—Shows response headers and status.
• [RW] TextView—Shows the response body in a text box.
• [RW] HexView—Shows the response body in a hexadecimal view.
• [RO] ImageView—Shows the response body as an Image. Supports all .NET image formats.
• [RO] XML—Shows the response body as an XML DOM in a tree view.
• [RO] Privacy—Explains the P3P statement in the response headers, if present.

To be continued...

SAP TAO -SAP Testing: SAP® Test Acceleration & Optimization: -Develop ef...

SAP TAO -SAP Testing: SAP® Test Acceleration & Optimization: ...: "SAP TAO) -SAP Test Acceleration and Optimization (SAP TAO) In layman terms – SAP tao is a way to apply software testing for SAP implement..."

We will cover following using this blog-

S.      No Topic

1.0 SAP TAO Installation and Configuration
1.1 SAP TAO Introduction
1.2 Prerequisites for Installing SAP TAO
1.3 SAP TAO Installation
1.4 SAP TAO Folder Structure
1.5 SAP TAO License
1.6 Configuring SAP Quality Center
1.7 Connecting SAP TAO to SAP Managed System
1.8 Connecting SAP TAO to SAP Quality Center
1.9 Creating Application Area in QTP
1.10 Exporting Local Components to QC
1.11 Configuration Settings for different Tabs
1.12 Self-Check

2.0 Explanation of Different Tabs in SAP TAO

2.1 Process Flow Analyzer (PFA)
2.2 Inspection
2.3 Consolidation
2.4 Import/Export
2.5 Change Analyzer
2.6 Repository
2.7 Connect
2.8 Self-Check

3.0 Demo With a Test Scenario

3.1 PFA
3.2 Inspect
3.3 UI Scanner
3.4 Consolidate
3.5 Build Test Script
3.6 Execute Test Script
3.7 Results Analysis

QC BPT(Business Process Testing) knowledge
3.SAP Application Basic knowledge (Not mandatory)

Please email me on sharma.london@gmail.com. I can direct you to a website where we’re conducting free online training on weekends..

I've documents Related to "SAP, SAP Testing, HP BPT, HP QC, HP QTP, SAP TAO, TAO, Testing, Manual Testing, Automation Testing" Join this blog and send an email to sharma.london@gmail.com

Best Practices to use QC

Best Practices to use QC

Overview
Primary objective of this page is to list down the best practices and standards of software testing using Quality Centre a test management tool. It describes the best methodologies that can be followed on HP quality centre for better test management and planning activities. These best practices are based on the real time knowledge and experience rather than a theoretical advice. The target audience of this page are the testing professionals involve in typical system testing using quality centre hence it is imperative that reader is familiar with basic quality centre terminologies and basic operations. Moreover, this page can be used by senior managers or by business analyst to streamline the testing process with other project management processes.
The scope of this page is limited for internal exercises/usage, to develop a consistent approach across best testing practices. This page will not cover the ‘Know How’ of the Quality Centre but will guide only the best practices and principle to follow in a project.
To understand the quality centre reader can refer Mercury Quality Centre User’s Guide Ref:
Glossary

MQC Mercury Quality Centre
SAP TAO SAP Test Acceleration and Optimization
CM Configuration Management
SUT System Under Testing
BPT Business Process Testing
dashboard technology A modular, configurable, and extensible user interface technology..

Followings are the typical process of test management on Quality Centre.
Figure 1 - Quality Centre Process

Component of the Quality Centre

Following are the basic components of the Mercury Quality Centre to define and manage the testing process. This section will give a brief overview of each component/ tab of the Quality Centre.

Requirement Module

This is the first module of the mercury Quality centre where project team can define brief description of each individual requirement to map to testing task or give the coverage to business functionality.
Note: this requirement tab offers the facility to automate the requirement process if it is being automated.

Following are the best practices on quality centre requirement definition tab:
Testing team analyse and gather project documents from various source to scope of the testing requirements. QC requirement tab is the best area to summarise the testing requirements, scope of testing, test objectives, and strategy etc. this requirement can be gathered by test manager, test analyst or senior tester or someone in team who is involved in application understanding. This area is being used by the team to give the coverage to each requirement assigned for individual tester. Tester can clearly determine the scope of the testing in this tab , assigned priority to task and test coverage to each feature of the application, criticality of the application function, relative importance and overall object of the application testing. The information described in this section can be used by tester to develop regression suite, smoke test suite etc.

Figure 2 -Requirement specification process

Best Practices for Requirement definition in QC
Requirement subject is recorded under the requirements Tab by creating a Requirements Tree. This defines the requirement in a hierarchical graphical illustration. The name of parent requirement folder should be defined with UPPER CASE and assign a unique Req. Id, project ID and the importance of the requirement. Requirement can be broken down to lowest level of detailed testing elements and any relevant document can also be attached to each sub requirement such as use case, Visio diagram etc. Once the requirements are defined a formal review process can be applied to validate each of the testing elements with priority level, coverage etc.

Example: SM01-PBS –HISTORICAL DATA MIGRATION
• Provide high level project detail description under description heading
Example: This project is basically a migration process to be used in moving the Portman data of saving, mortgage and insurance products currently held on Portman systems to the nationwide system (Columbus). We can use detailed defined requirements as a basis for test plan.
• Use Title Case to create sub folders under project parent folder
Example:
REQ_PBS 001– Saving Accounts Migration
REQ_PBS 002– Mortgage Accounts Migration
REQ_PBS 003– Insurance Migration
Check List for Requirement Definition on Quality centre
• Is the business requirement clearly stated in requirements tab for SUT?
• Has the test strategy clearly defined?
• Is the reason for testing specific module with importance is defined?
• Is the test environment of the project consistent with the CM?
• Is it clear what will define a successful outcome of the test requirement?
• Is it clear what the preferred option to schedule test plan is available?
• Is it clear why this is the preferred testing technique selected in Req. option?
• Are the risks faced by the project explicitly stated in requirement tab?
• Are the plans for addressing those risks explicitly stated?
Test Planning in Quality Centre
Project test plan on quality centre is the area that describes / states of the objectives, scope, approach, technique of a software testing efforts. This is a very important area for application testing. The technique of preparing a test planning is a constructive way to think through the efforts needed to verify and validate the acceptability of a software application. The area on testing plan on quality helps people outside the testing group understand the 'why' and 'how' of product is being validated. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it.

Following are the typical characteristic and benefits of the test plan module of the Quality Centre.

Test Plan module on Quality Centre, helps tester to brief test requirements, individual test strategy, test techniques, test coverage and detail test steps. In best practice test plan module should be elaborated not just for defining the test cases, steps and scripts but should be used to map to the requirement definition in the first tab i.e. requirements. How we will be testing this application, such as applying top to bottom integration testing technique, system testing, or end to end business processes. What would be the test data, entry and exit points etc.

Test Coverage in Test plan Module on quality centre, this is the process and best practice which link requirement to test plan and finally with status of pass fail from test lab. By following this approach tester can identify the status of testing activities and also cover the defined requirement in test requirement tab. In practice this should be done before importing test steps to test lab.

Figure 3-Test planning and definition on Quality centre



Best Practices for test specification on QC
Check List for Quality Centre Test Plan
• Is it clear that what and how we are testing?
• Is it clear that what is the test priorities and schedule?
• Is it clear that what would be the test data for executing specified test plan?
• Is it clear that test environment is configured as defined in CM?
• Is it clear what is the preferred testing technique selected?
• Are the risks faced by the project explicitly stated in test plan?
• Are the plans for addressing those risks explicitly stated?
• Is the defined test step is logically designed to give sufficient req coverage?
• Is the test objective are clear and understood from the test plan or test scripts?
• Is the entry, exit and suspension and resumption criteria defined clearly?
Test Cases in Quality Centre Test Lab
A test case in quality centre is the part of test plan that describe an input, action, or event and an expected response, to determine if a feature of an application is working correctly. A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results. Negative and positive test cases can be defined in sequence of each others. Ensure that each test case meet the best practice and standards defined under section [4]. Quality Centre facilitates the control of test execution of tests in logical test set. Tester can set conditions, and schedule the date and time for executing your tests. You can also set the sequence in which to execute the tests. For example, run test3 only after test1 has finished and passed successfully or and run test3 only if test1 passed.

Figure 4 - Quality Centre Test Lab process
Quality Centre Test Lab process
Best Practice for Quality Centre Test Lab.
• Before starting of new manual run on test script ensures that you have not executed test cases earlier, if you would like to verify earlier test run then click on continue manual run.
• As a best practice don’t apply fiter on test lab.
• Use standard terminology to prove execution detail such as Passed, as expected with more descriptive details
• Ensure if you are running a test set executed by other team member must apply name of change on test lab tab under tester’s name.
• If test step is not applicable, set to N/A and if test can not be executed because of data unavailability ensure that you set test step as not completed with appropriate comments
• If there is test step dependency because of test data, or failure of few steps ensure you set rest of the test steps as Blocked and stop the test run.
• If test is not applicable, remove from the test set tree
Check List for Quality Centre Test Lab.
• Ensure that you import test cases from test plan module and map to test lab.
• Each test plan module has been mapped appropriate
• Test numbers and legend are consistent as per test plan
• Select appropriate test run – e.g. continue manual run, automated run.
• Is the entry criterion meets the need of test plan?
• Is the test environment ready for test execution?
• Ensure that test settings are appropriate as per the test configuration document.
• Is available test data and environment are sufficient to meet test objective?
• Is the defined schedule is clear and viable enough to meet test execution need?
• Defect raised against test step having appropriate information, attachment etc.
• Ensure that current status of the test status is set to one of the following “Failed” , “Passed”,”N/A” and if Not completed or not run the appropriate description available for test steps.

Defect Management on Quality Centre

For more details, see Defect management process on QMS

Figure 5 -Quality Centre Defect management process
Best Practices:
• If defect is related to application, ensure that defect has been added from test steps
• Indicate the severity of the defects based on the business requirement defined in requirements tab
• If not auto email is not configured on QC, send manual email to concerns that defect is assigned, and this can be done thru defect screen on Quality Centre.
• Assigned clear step-wise step description to define the problem for reproduction with appropriate comments
• Subject of the defect should be consistent and same as listed for project / application area with unique project Id e’g SM01 – Account Validation Failed – use sentence case
• Attach relevant information, screen shot etc.

Check List:
• Ensure that Defect description is relevant and well understood / No spelling mistakes
• Assigned to and assigned against is set clearly
• Subject is associated to test lab or test plan.
• Reproducible is set to yes or no with details
• Severity is set appropriately
• Application version / Build Id and description detailed accurately
• Before adding or modifying defect description ensure that you read history of the defect
• View associated test case status, should be failed
•

Test Analysis on Quality Centre
See page named “BPT testing using QC for test analyses”.

Standards for Writing Test Cases/Scenarios on QC
Very first step in software testing is the element of requirements – What is being tested?
This should be clearly defined under the requirement tab and should be aligned updated as per the Business requirement document changes.
This requirement can be defined in agreed format of scenario format or in use case for mat
For the purpose of this document we will be looking standards of manual test case using a typical test scenario definition using Quality centre.

Below is the list of standards that can be followed for better Quality centre practices.

• The First component in the Scenario/Test Case ID should be the type of testing for which the scenario being written e.g. #ST01 -
• The Second component in the Scenario/Test Case ID should be Unit Name/ Module Name–Sub Component / Module Name
• Purpose of the test plan / objectives
• Test Coverage criteria, this would be based on the requirement coverage
• All the Scenario/Test Case should be easily understandable, clear, concise and to the point.
• The pre-requisite for the Scenario/Test Case should be mentioned before the test cases. See below sample scenario
• The Scenario/Test Case for different module should be maintained in a single set of test plan or Worksheet in an Excel File. The Name of the Excel File should be TypeOfTesting_ModuleName.xls I.e. ST_BackOffice.xls
• Whenever new Scenario/Test Case is been added in between two existing one it should be named after the previous Scenario/Test ID with decimal places. i.e. If we have to add new Scenario in between scenario ID ST-SA-BKG-0015 and ST-SA-BKG-0016, then new scenario id will be ID ST-SA-BKG-0015.1 and so on.
• Defect ID of a Scenario/Test Case should match the Defect ID submitted against that defect in Defect Tracking System (QC) /Excel file. there for if this is a manual testing process a Traceable to a requirement would be easy

Sample Test Scenario

Scenario / test Case #ST01- Validation of the Account Data with Customer Data

SUMMARY DESCRIPTION AND OBJECTIVES
The objective of this Test Case is to verify that selected account data can be migrated successfully from a PBS account type named and number “First Save (404)” account to a NBS Smart account. Where the account holder is > 7 & <18 years on the day of migration, and the account has an Interest payment mandate set TEST COVERAGE The testing points covered by this Test Case include: All type of accounts where holders are > 7 & <18 on day of migration and roles are /= to JAF/JAO will be migrated into NBS Smart account type. Interest calculation and payment will be paid on migration of Portman account. All the migration of a First Save type of account must not be registered as a customer will be migrated with previous transaction. TEST DATA REQUIREMENTS This Test Case requires data that satisfies the aove test coverage : #The PBS account number 404 first Save migrated and in data file (MTF) using PSMS saving #Account Holder > 7 & < 18 years on day of migration Quality Language for manual Test Cases • Test Case Quality language means the better testability with the language being used with test specification so this can be used by a team Use active case such as do this, do that, Execute this, perform this, click on, select from. application displays this, does that, should do etc Simple as much as possible and nearer to conversational language however people has reservation with technical language Exact, consistent names of fields, not generic especially active cases Should explain Windows, Web basics such as Drop Down list this should come from the business rather technology e.g. rather writing that select drop down, it would be better to write select from the drop down
Naming conventions
• Module Names should be in all capitals and bold. E.g. to mention BackOffice Module in the Scenario/Test Case, usage should be “BACKOFFICE”.
Screen Names should be bold and have Camel Notation i.e. the first letter of the
word in Capitals and rest in Small letters. If there are multiple words on the screen
name, then the 1st letter of all the words should be in Capitals and the rest of the
word in small letters. i.e. for Account Detail screen name will be “Account Details”
All the objects like Text Box, List Box, Check Box, Radio Button, Combo Box names should be in italics and bold. i.e. Login Text box should be mentioned as Login.
The Link Names should be mentioned with an Italics, bold and underline below the
word. i.e. Sign out link will be named as Sign Out.
Database table name should be in Caps i.e. for Emp_Detail table name will be
EMP_DETAIL, ACOOUNTS, JOINHOLDER
Test Case review Check List
All the test cases should review at least once and checklist should be filled by authored team member.
General Points to be considered while reviewing the Check List:
• Test cases should follow agreed standard format.
The Test cases are complete with respect to the Specifications Document on which they are based.
Test data is mentioned explicitly for each test condition if applicable
'Expected result' section of each test case is complete
Pre-conditions for executing a test case or a set of test cases are specified.
It is specified which test cases are to be executed together (or in a specific order)
Test cases cover the entire functionality of the integrated module and available requirement is amped to test plan.
Test cases follow the order of integration as defined in requirement module or in reference document such as functional design document or test plan.


Best and effective Practice to use QC