ETL Metrics and ETL Process Definitions and Deliverables

    Introduction

Metrics are the means by which the software quality can be measured; they give you confidence in the product. You may consider these product management indicators, which can be either quantitative or qualitative. They are typically the providers of the visibility you need.

Metrics

Metrics usually fall into a few categories: project management (which includes process efficiency) and process improvement. People are often confused about what metrics they should be using. You may use different metrics for different purposes. For example, you may have a set of metrics that you use to evaluate the output of your test team. One such metric may be the project management measure of the number of bugs found. Others may be an efficiency measure of the number of test cases written, or the number of tests executed in a given period of time.

---

The goal is to choose metrics that will help you understand the state of your product.

---

Ultimately, when you consider the value of a metric, you need to ask if it provides visibility into the software product's quality. Metrics are only useful if they help you to make sound business decisions in a timely manner. If the relevancy or integrity of a metric cannot be justified, don't use it. Consider, for example, how management analysis and control makes use of financial reports such as profit/loss, cash flow, ratios, job costing, etc. These reports help you navigate your business in a timely manner. Engineering metrics are analogous, providing data to help perform analyses and control the development process. However, your engineers may not be the right people to give you the metrics you need to help in making business decisions, because they are not trained financial analysts. As an executive, you need to determine what metrics you want and tell your staff to provide them.

For example, coverage metrics are essential for your team. Coverage is the measure of some amount of testing. You could have requirements coverage metrics, platform coverage metrics, path coverage metrics, scenario coverage metrics, or even test plan coverage metrics, to name a few. Cem Kaner lists over 100 types of coverage measures in his paper "Negligence and Testing Coverage." Before the project starts, it is important to come to agreement on how you will measure test coverage. Obviously, the more coverage of a certain type, the less risk associated with that type.

The goal is to choose metrics that will help you understand the state of your product. Wisely choose a handful of these metrics specific to your type of project and use them to give you visibility into how close the product is to release. The test group needs to be providing you plenty of useful information with these metrics.

Conclusion

The metrics provided by testing offer a major benefit to executives: visibility into the maturity and readiness for release or production, and visibility into the quality of the software product under development. This enables effective management of the software development process, by allowing clear measurement of the quality and completeness of the product.

ETL Process Definitions and Deliverables

• 1.0 Define Requirements – In this process you should understand the business needs by gathering information from the user.  You should understand the data needed and if it is available.  Resources should be identified for information or help with the process.
• Deliverables
• A logical description of how you will extract, transform, and load the data.
• Sign-off of the customer(s).
• Standards
• Document ETL business requirements specification using either the ETL Business Requirements Specification Template, your own team-specific business requirements template or system, or Oracle Designer.
• Templates
• ETL Business Requirements Specification Template
• 2.0 Create Physical Design – In this process you should define your inputs and outputs by documenting record layouts.  You should also identify and define your location of source and target, file/table sizing information, volume information, and how the data will be transformed. 
• Deliverables
• Input and output record layouts
• Location of source and target
• File/table sizing information
• File/table volume information
• Documentation on how the data will be transformed, if at all
• Standards
• Complete ETL Business Requirements Specification using one of the methods documented in the previous steps.
• Start ETL Mapping Specification
• Templates
• ETL Business Requirements Specification Template
• ETL Mapping Specification Template
• 3.0 Design Test Plan – Understand what the data combinations are and define what results are expected.  Remember to include error checks.  Decide how many test cases need to be built.  Look at technical risk and include security.  Test business requirements.
• Deliverables
• ETL Test Plan
• ETL Performance Test Plan
• Standards
• Document ETL test plan and performance plan using either the standard templates listed below or your own team-specific template(s).
• Templates
• ETL Test Plan Template
• ETL Performance Test Plan Template
• 4.0 Create ETL Process – Start creating the actual Informatica ETL process.  The developer is actually doing some testing in this process.
• Deliverables
• Mapping Specification
• Mapping
• Workflow
• Session
• Standards
• Start the ETL Object Migration Form
• Start Database Object Migration Form (if applicable)
• Complete ETL Mapping Specification
• Complete cleanup process for log and bad files – Refer to Standard_ETL_File_Cleanup.doc
• Follow Informatica Naming Standards
• Templates
• ETL Object Migration Form
• ETL Mapping Specification Template
• Database Object Migration Form (if applicable)
• 5.0 Test Process – The developer does the following types of tests: unit, volume, and performance.
• Deliverables
• ETL Test Plan
• ETL Performance Test Plan
• Standards
• Complete ETL Test Plan
• Complete ETL Performance Test Plan
• Templates
• ETL Test Plan Template
• ETL Performance Test Plan
• 6.0 Walkthrough ETL Process – Within the walkthrough the following factors should be addressed:  Identify common modules (reusable objects), efficiency of the ETL code, the business logic, accuracy, and standardization.
• Deliverables
• ETL process that has been reviewed
• Standards
• Conduct ETL Process Walkthrough
• Templates
• ETL Mapping Walkthrough Checklist Template
• 7.0 Coordinate Move to QA – The developer works with the ETL Administrator to organize ETL Process move to QA.
• Deliverables
• ETL process moved to QA
• Standards
• Complete ETL Object Migration Form
• Complete Unix Job Setup Request Form
• Complete Database Object Migration Form (if applicable)
• Templates
• ETL Object Migration Form
• Unix Job Setup Request Form
• Database Object Migration Form
• 8.0 Test Process – At this point, the developer once again tests the process after it has been moved to QA.
• Deliverables
• Tested ETL process
• Standards
• Developer validates ETL Test Plan and ETL Performance Test Plan
• Templates
• ETL Test Plan Template
• ETL Performance Test Plan Template
• 9.0 User Validates Data – The user validates the data and makes sure it satisfies the business requirements.
• Deliverables
• Validated ETL process
• Standards
• Validate Business Requirement Specifications with the data
• Templates
• ETL Business Requirement Specifications Template
• 10.0 Coordinate Move to Production - The developer works with the ETL Administrator to organize ETL Process move to Production.
• Deliverables
• Accurate and efficient ETL process moved to production
• Standards
• Complete ETL Object Migration Form
• Complete Unix Job Setup Request Form
• Complete Database Object Migration Form (if applicable)
• Templates
• ETL Object Migration Form
• Unix Job Setup Request Form
• Database Object Migration Form (if applicable)
• 11.0 Maintain ETL Process – There are a couple situations to consider when maintaining an ETL process.  There is maintenance when an ETL process breaks and there is maintenance when and ETL process needs updated.
• Deliverables
• Accurate and efficient ETL process in production
• Standards
• Updated Business Requirements Specification (if needed)
• Updated Mapping Specification (if needed)
• Revised mapping in appropriate folder
• Updated ETL Object Migration Form
• Developer checks final results in production
• All monitoring (finding problems) of the ETL process is the responsibility of the project team
• Templates
• Business Requirements Specification Template
• Mapping Specification Template
• ETL Object Migration Form
• Unix Job Setup Request Form
• Database Object Migration Form (if applicable)

So ETL Testing implies - Testing this entire process using a tool or at table level with the help of test cases and Rules Mapping document.

In ETL Testing, the following are prima facie validated -
1) Data File loads from Source system on to Source Tables.
2) The ETL Job that is designed to extract data from Source tables and then move them to staging tables. (Transform process)
3) Data validation within the Staging tables to check all Mapping Rules / Transformation Rules are followed.
4) Data Validation within Target tables to ensure data is present in required format and there is no data loss from Source to Target tables.

What I have mentioned here is just a tip of the ice-berg and a description of ETL Testing from a very high level but hope this gives an insight about ETL Testing.

ETL testing really isn't all that complicated. Though, it requires a lot of attention to detail.

What does a tester do in an ETL environment? This is what I do:

1. Review the requirements
2. Review the source data - data profiling.
3. Modify the source data to meet any requirements that weren't already met with the original source data.
4. Execute the ETL job(s)/transformation(s).
5. Validate the results.
6. Validate that the data is usable. If the data isn't usable, then you really haven't gained anything.

As to what tools are used, it depends on the individual and the environment that they're working in. Personally, I want/need access to two applications at a bare minimum:

1. The ETL tool itself
2. Some sort of db gui tool (i.e., Toad, etc.)

Regardless of how the ETL code is exercised - directly through the ETL tool or through some command line script, I want to be able to go into the code so I can understand how the developer is meeting a specific requirement. If a set of data is to be grouped together, I like to be able to go in and understand how the code is grouping that data. Ultimately, I want to be an asset to the developers (and the rest of the project) and not a line item to be checked off prior to implementation. (Besides, sometime down the road I may turn into an ETL developer...and it's good to understand what is involved.)

Lastly, there is one test that I usually start off with before really diving in-depth to what I'm working on. Formally, it's a smoke test. Personally, it's the "surprise me" test. If I can execute the ETL job and it completes successfully, that's half the battle right there. What this tells me is that all of the pieces are in place to execute the job...be it database structure, file system structure, and/or data itself. It's surprising how often that something is missed. The plus side of this is that, regardless of whether data has been set up for specific tests, I do have a starting point to start validating data.

Everyone wants success. Everyone strives for it. But unfortunately everyone does not get it. Those who do not get success get dejected and start thinking that success is not in their fate. Contrary to this pessimistic view of denouncing oneself we are told that fate does not foist it on them. Only those are deprived of success who start with wrong notions and assumptions and are not willing to pay the price for it.
We advise you to have a look at what our great thinkers have said about success and how to attract it. It has been said
"Success is a process, not an event",
"Success is a journey, not a destination",
"Success means winning the war, not every battle",
"Success comes to those who dare and act",
"Success seldom goes to the timid who is always afraid of consequences",
"Success is old ABC - Ability, Brave and Courage",
"Success comes before work only in a dictionary",
"Success is a slow process, so never be hasty".
A galaxy of such inspiring statements about success can be multiplied from literature.
These statements are expressed in simple language, easy to understand and easier to digest. The essence of all these and such other statements is that success lies in passion, purpose, planning, perseverance and pride. Learn, if you can, from us that secret of success lies in your enthusiasm. The difference between impossible and possible lies in your determination. If you have the will to win, you have achieved half the success. A golden rule for you is to think only for the best. Work only for the best and expect only the best. Sooner or later you will get the best.
What we are trying to impress upon you and implant in your mind is to make yourself ready, with sincerity and determination, to be successful in life and start working for it. At SADHANA YOUTH EMPOWERMENT SCHOOL we are engaged to give you best possible study material and give you best guidance and coaching for your success. We consider your success as reward for our efforts.
Join and recommend SADHANA YOUTH EMPOWERMENT SCHOOL confidently and intelligently. It gives you the power to master your career and shape your destiny.

Golden Words By Hitler-
"Think Thousand Time Before Take a Decision,
But Never Turn Back Even If u Get Thousand Difficulties After Such Decision"
"You will never reach your destination if you stop & throw stones at every dog that barks."
-WINSTON CHURCHILL     "Better we keep biscuits"
SOME IMPORTANT QUOTES FROM CHANAKYA NEETI
chanakya Neeti(must read good)

"A person should not be too honest. Straight trees are cut first and honest people are screwed first."
Chanakya quotes (Indian politician, strategist and writer, 350 BC-275 BC)

"Even if a snake is not poisonous, it should pretend to be venomous."
Chanakya quotes (Indian politician, strategist and writer, 350 BC-275 BC)


"The biggest guru-mantra is: Never share your secrets with anybody. It will destroy you."
Chanakya quotes (Indian politician, strategist and writer, 350 BC-275 BC)


"There is some self-interest behind every friendship. There is no friendship without self-interests. This is a bitter truth."
Chanakya quotes (Indian politician, strategist and writer, 350 BC-275 BC)


"Before you start some work, always ask yourself three questions - Why am I doing it, What the results might be and Will I be successful. Only when you think deeply and find satisfactory answers to these questions, go ahead."
Chanakya quotes (Indian politician, strategist and writer, 350 BC-275 BC)

"As soon as the fear approaches near, attack and destroy it."
Chanakya quotes (Indian politician, strategist and writer, 350 BC-275 BC)


"The world's biggest power is the youth and beauty of a woman."
Chanakya quotes (Indian politician, strategist and writer, 350 BC-275 BC)


"Once you start a working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest."
Chanakya quotes (Indian politician, strategist and writer, 350 BC-275 BC)

************************************************** *
"The fragrance of flowers spreads only in the direction of the wind.
But the goodness of a person spreads in all direction."
Chanakya quotes (Indian politician, strategist and writer, 350 BC-275BC)

************************************************** *
"Whores don't live in company of poor men, citizens never support a
weak company and birds don't build nests on a tree that doesn't bear fruits."
Chanakya quotes (Indian politician, strategist and writer, 350 BC-275BC)

************************************************** *
"God is not present in idols. Your feelings are your god. The soul is
your temple."
Chanakya quotes (Indian politician, strategist and writer, 350 BC-275 BC)

************************************************** *
"A man is great by deeds, not by birth."

Chanakya quotes (Indian politician, strategist and writer, 350 BC-275 BC)

************************************************** *

"Never make friends with people who are above or below you in status.
Such friendships will never give you any happiness."
Chanakya quotes (Indian politician, strategist and writer, 350 BC-275 BC)

************************************************** *

"Treat your kid like a darling for the first five years. For the next
five years, scold them. By the time they turn sixteen, treat them like a friend. Your grown up children are your best friends."
Chanakya quotes (Indian politician, strategist and writer, 350 BC-275 BC)

************************************************** *

"Books are as useful to a stupid person as a mirror is useful to a blind person."
Chanakya quotes (Indian politician, strategist and writer, 350 BC-275 BC)

************************************************** *

"Education is the best friend. An educated person is respected everywhere. Education beats the beauty and the youth."
Chanakya quotes (Indian politician, strategist and writer, 350 BC-275 BC)

Golden Words of Hitler:

When u r in light, everything will follow u. But when u enter dark, even your own shadow
will not follow u that is life

God made relatives. Thank God we can choose our friends

Money glitters, beauty sparkles, and intelligence shines.

Keep a very firm grasp on reality, so you can strangle it at any time.

Life is like a box of chocolates, you never know what you're getting.

People may not always believe what you say, but they will believe what you do.

I've always wanted to be somebody, but I should have been more specific.

You can't have everything - where would you put it?

Laugh and the world ignore you. Crying doesn't help either.

God is not moved or impressed with our worship until our hearts are moved and impressed by Him.

Life is like a mirror, if you frown at it, it frowns back; if you smile, it returns the greeting.

Never trust a person who isn't having at least one crisis.

Goodness is the only investment that never fails.

The only thing lazy people do fast is get tired.

Never deprive someone of hope; it may be all they have.

Silence is the only thing that can't be misquoted!

If we don't control our money, it will control us.

Life Insurance: A contract that keeps you poor all your life so that you can die rich..

Some drink at the fountain of knowledge. Others just gargle.

Everyone has a photographic memory. Some don't have film.

If you r living on the edge, make sure you're wearing your seat belt.

A classic is something that everybody wants to have read and nobody wants to read.

Minds, like parachutes, only function when they are open.

The shortest distance between two points is under construction.

Learn from other people's mistakes, life isn't long enough to make them all yourself.

On the road, never argue with a vehicle heavier than yours.

One thing you can give and still keep is your word.

Life is funny if you don't think about it.

Life is like a grammar lesson. You find the past perfect and the present tense.

There are two kinds of lawyers, those who know the law and those who know the judge.

More doors are opened with 'please' than with keys

ETL testing and the role of a QA?

ETL stands for extract, transform, and load. It can consolidate the scattered data for any
organization while working with different departments. It can very well handle the data
coming from different departments.
For example, a health insurance organization might have information on a customer in
several departments and each department might have that customer's information listed in
a different way. The membership department might list the customer by name, whereas
the claims department might list the customer by number. ETL can bundle all this data
and consolidate it into a uniform presentation, such as for storing in a database or data
warehouse.
ETL can transform not only data from different departments but also data from different
sources altogether. For example, any organization is running its business on different
environments like SAP and Oracle Apps for their businesses. If the higher management
wants to take discussion on their business, they want to make the data integrated and used
it for their reporting purposes. ETL can take these two source system data and make it
integrated in to single format and load it into the tables.


Generally the normal testing steps are:
• Requirements Analysis
• Testing Methodologies
• Test Plans and approach
• Test Cases
• Test Execution
• Verification and Validation
• Reviews and Walkthroughs

The main difference in testing a ETL is that we basically involve the
SQL queries in our test case documents. It is vital to test both the initial loads of the Data
Warehouse from the source i.e. when it gets extracted and then updating it on the target
table i.e. the loading step. In specific cases, where trouble shooting is required, we verify
intermediate steps as well.

A defect or bug detection can be appreciated if and only if it is detected early and is fixed
at the right time without leading to a high cost. So to achieve it, it is very important to set
some basic testing rules. They are:
• No Data losses
• Correct transformation rules
• Data validation
• Regression Testing
• Oneshot/ retrospective testing
• Prospective testing
• View testing
• Sampling
• Post implementation

Ans2) ETL testing really isn't all that complicated. Though, it requires a lot of attention to detail.

What does a tester do in an ETL environment? This is what I do:

1. Review the requirements
2. Review the source data - data profiling.
3. Modify the source data to meet any requirements that weren't already met with the original source data.
4. Execute the ETL job(s)/transformation(s).
5. Validate the results.
6. Validate that the data is usable. If the data isn't usable, then you really haven't gained anything.

As to what tools are used, it depends on the individual and the environment that they're working in. Personally, I want/need access to two applications at a bare minimum:

1. The ETL tool itself
2. Some sort of db gui tool (i.e., Toad, etc.)

Regardless of how the ETL code is exercised - directly through the ETL tool or through some command line script, I want to be able to go into the code so I can understand how the developer is meeting a specific requirement. If a set of data is to be grouped together, I like to be able to go in and understand how the code is grouping that data. Ultimately, I want to be an asset to the developers (and the rest of the project) and not a line item to be checked off prior to implementation. (Besides, sometime down the road I may turn into an ETL developer...and it's good to understand what is involved.)

Lastly, there is one test that I usually start off with before really diving in-depth to what I'm working on. Formally, it's a smoke test. Personally, it's the "surprise me" test. If I can execute the ETL job and it completes successfully, that's half the battle right there. What this tells me is that all of the pieces are in place to execute the job...be it database structure, file system structure, and/or data itself. It's surprising how often that something is missed. The plus side of this is that, regardless of whether data has been set up for specific tests, I do have a starting point to start validating data.

E-Banking Test plan

Project Overview

Ranford Home page allows different users such as admin, bank employee, various customers (Individual customers, corporate customers, International Customers) to login and access the application for further usage and also it provides information about various services offered by Ranford Bank.

The objective of the RANFORD BANK Admin module in project is to create new branches, to create the new users and Bankers along with the privileges. Admin is the super user, which has all the privileges for creating the Branches, Users and Bankers and along with all the other privileges.

The Objective of the RANFORD BANK Banker module in project is to register and manage the customers of the bank and to book the day-to-day transactions in the bank such as deposits and withdrawals etc.

The Objective of the RANFORD BANK Customer module in project is designed for the registered customers to perform various activities such as Accounts Summary, Money Transfer, Smart Money Order, Online bill payments and online request for chequebook etc.,

Purpose

The purpose of this document is to provide an overview for System Testing (ST) of RANFORD Bank. This document covers the testing scope, Entry-Exit criteria, QA Deliverables, QA Schedule, High Level Test Scenarios, Assumptions & Dependencies, Test Management and Risks & Mitigations.

1.1          Referred Documents

The RANFORD Bank Business Requirements Specifications (BRS)

The RANFORD BANK Functional Specifications document (FRS)

2.0      Scope

2.1           In Scope

• Testing the Admin, Banker and Customer (Personal Banking) modules in            E-Banking project.
• Functional / system testing of all test scenarios mentioned under sec 10.0.
• Creation of Test Requirements, Test Cases and Test Sets in Quality center.
• Preparation of Test Data for executing the Test Cases.
• Test case Execution for 2 cycles and defect Tracking.
• Test case execution on the following Operating System Windows2000.
• Test case execution using the following browsers - IE .0.

2.2          Out of Scope

·         Load & Performance testing.

·         Unit and Integration testing is not part of this scope.

3.0      Assumptions and Dependencies

3.1          Assumptions

·         The main drivers for System Testing are the functionalities contained within the functional specification documents.  These will define the scope of the testing and it is assumed that once functionality from these has been tested then full coverage has been achieved.

·         Staging server will be accessible.

·         Contact details of person(s) concerned with resolving environmental issues will be provided.

·         Formal and Intensive Unit and Integration testing will be done by the Dev Team.

·         Defects will be dealt with in timely fashion by all teams involved.

·         New builds will be deployed in QA environment as per build schedule.

·         All identified High-level test scenarios can be simulated in test environment.

3.2          Dependencies

·         Knowledge transfer on Functionality as well as Technology to offshore testing team

·         Availability of Development environment to validate test scripts.

·         Availability of ACL connection to applications from offshore.

·         Availability of ACL connection to Databases from offshore.

·         Availability of Database schema description to understand the Database Structure.

·         Availability of All necessary software’s and Operating System’s

• Test data as specified by the QA team, injected into the stage environment.
• All necessary User ID’s & passwords provided to the QA team

4.0      Risks and Mitigations

Risk	Likelihood	Impact	Mitigation
Application not accessible or not responding properly during test execution due to environmental issue.	Low	High	Perform an environment sanity check before starting the formal testing Obtain Mobile / Pager numbers of IT team members to escalate P1 environment issues.
Test team does not have adequate knowledge of the application	Low	High	Organize extensive knowledge transfer sessions with offshore team
Development team having less knowledge of Quality center.	Low	High	QA team will provide clarifications to the Development team.
Presence of large number of blocking Defect‘s during test execution, this would prevent or delay testing.	Low	High	Daily defect meeting will be utilized to prioritize defects QA co-ordinator will work closely with the IT team lead to provide
Changes to requirements	Medium	Medium	All new Requirements that arise are initiated through Change Control process

5.0      System Testing Entry and Exit Criteria

5.1           Entry Criteria

The following must be in place prior to the onset of QA System Testing

Business

·         The Business Requirements Document is “frozen

·         All new Requirements that arise are initiated through Change Control process

QA

·         Daily communication plan in place

·         Test Cases Reviewed & signed-off

·         Cross-functional, dependent teams & resources identified

·         QA Data Requirements identified & all necessary passwords/accesses obtained

·         Daily Defect Meeting Day/Time/Attendance established in the execution phase

·         All appropriate team members have access to Quality center

·         Test cases have been linked to test sets in Quality center

5.2           Exit Criteria

The following must be in place prior to the sign-off of QA System Testing:

·         No open P1 or P2 defects

·         All P3-P5 (enhancements) defects have a documented resolution plan

·         A minimum of 2 test cycles (100% execution) is completed.

·         95% Pass Rate of all test cases

·         Regression testing of defects fixed during system testing

·         All defects logged in Quality center

·         QA sign-off on system test

·         System test Close-out report Provided 

·         Documented list of any outstanding (open) defects

6.0      QA Deliverables

The following items will be delivered:

·         System Test Plan

·         Test Cases (Maintained in Quality center)

·         Daily Test Execution Report

·         System Test Exit Report

·         Defect Log (Maintained in Quality center)

·         Traceability Matrix

·         Exit Report.

·         Project Metrics.

7.0      QA Schedule

QA Activities	QA Deliverable	Start Date	End Date
Analysis of the Documents	Understanding Document	10/12/2008	10/12/2008
Test Planning	Test plan document	11/12/2008	11/12/2008
Test Scenarios Identification & documentation	Test Scenarios document	12/12/2008	12/12/2008
Test case preparation and validation	Test cases, Test Data	13/12/2008	15/12/2008
Test Environment Setup, Traceability Matrix Preparation	Traceability Matrix	17/12/2008	18/12/2008
Test case execution and Defect tracking	Complete the execution and defect log maintained in Quality center	19/12/2008	23/12/2008
End-to-End Test Scenarios Identification & End-to-End test cases preparation	End-to-End Test Scenarios & End-to-End test cases	24/12/2008	24/12/2008
System Testing Sign-off	Exit report	24/12/2008	24/12/2008

8.0       Build Schedule

New builds will only be deployed in stage environment as per build schedule. Only emergency builds can be deployed on other dates. Each build should have version number. Email to QA coordinator has to be sent after successful installation of build. Sanity test by IT team should be conducted after build installation.

Sl.No	Activity	No of Resources	Start Date	End Date	No of Days
1	Build#1	1	19/12/2008	22/12/2008	3
2	Build#2	1	23/12/2008	23/12/2008	1

9.0      Test Environment

The following list of software will be required in the System Test Environment

QA URLs	RANFORD BANK – http://192.18.1.42/Ebanking1
Web Browser	IE .0
Test management Tool	Quality Center – 9.0 SP2 http://localhost/qcbin/start.htm Domain: Banking   Project: E-Banking
Operating System	Microsoft windows 2000
H/W	Intel (R) Pentium, 2.8 GHZ, 501MB

10.0  High Level Test Scenarios

S#	Test Scenario
Admin Module
0.1	Ranford Home Page
0.2	Admin Home Page
1	Branches
1.1	New Branch Creation
1.2	Branch Edit
1.3	Branch Delete
1.4	Branch Search
2	Roles
2.1	New Role Creation
2.2	Role Edit
2.3	Role Delete
3	Users
3.1	New User Creation
3.2	User Edit
3.3	User Delete
3.4	User Search
4	Employee (Banker)
4.1	New Employee Creation
4.2	Employee Edit
4.3	Employee Delete
Banker
5	Customer
5.1	New Customer Registration
5.2	Edit Customer
5.3	Delete Customer
	Receipts
.1	Cash Deposit
.2	DD Deposit
.3	Cheque Deposit
7	Payments
7.1	Cash withdrawal
7.2	Cheque withdrawal
7.3	DD withdrawal
Customer (Personal Banking)
8.0	Accounts Summary
9.0	Money Transfer
10.0	Smart Money Order
11.0	Biils Pay
01.0	Request for Cheque Book

 

11.0  Test Approach

11.1       Test Preparation

·         The QA Team will prepare Test Scenarios and Test Requirements based on all the project related documents provided by the project team.

·         The QA Team will prepare the system test cases to validate each Test Scenario and Test requirement.

·         The system test cases will check the application functionality by supplying a set of valid and invalid inputs.

·         The system test cases will be reviewed by the development PL. The Test Lead/Analyst will approve the document. The test cases will be stored in Quality center from the draft stage itself. The test coordinator will export the test cases in excel format for ease of review.

·         SQL queries will be attached to the relevant steps of the test scripts to validate the information on the screen will be validated against the information contained in the database.

11.2        Test Execution

·         The test scripts will be executed manually. The results will be validated against the expected results listed in the test scripts. Any defect found in this process will be logged in Quality center.

·         Where applicable the information on the screen will be validated against the information contained in the database. Pre-defined SQL queries will be attached to the relevant steps of the test scripts. The tester will copy and paste these queries in Toad SQL window and execute them to obtain the result. The comparison will be done by manual method.

·         The application development team will review defects raised by the QA team. The tester will provide all necessary information about the defect in Quality center. Attachment tab of Quality center will be used for providing any screen shots, files required for investigating the defects.

·         After the completion of the testing run, the peer team member of the Testing Team reviews the results.  The test results are reported to the project PL who will approve the test results. This process may repeat till the number of bugs found is within the acceptable limits and the test exit criteria previously determined is achieved.

·         There will be at least six complete cycles of tests executed. The last cycle should go through without any P1 or P2 defects. If there are P1 and P2 defects are found in the last cycle, more testing cycles will be executed until all P1 and P2s are removed.

Appendix A

1           Test Planning

1.1          Quality center

Test cases, test sets and defects will be stored and maintained in the RANFORD BANK - (Domain – E-Banking) domain in Quality center, http://localhost/qcbin/start.htm

Quality center: Requirements - Requirements will be documented in the Requirements module and associated with applicable test cases.

Quality center: Test Plan - Test cases will be written in the Test Plan tab.  Test cases will be organized by subject (or function/ use case).  At this time, all test cases are written for manual execution.

Quality center: Test Lab - Test Sets containing test cases to be executed during System Test will be created in and executed from the Test Lab tab.  Test cases will be executed manually. 

Quality center: Defects - The Quality center Defects tab will be used to log and communicate status of defects.  If a test case does not meet the expected result, the test case will be “failed” and a defect will be logged identifying the problem.

2           Defect Management

2.1          Prioritization of Defects

During system, business, and user-acceptance testing, defects will be logged in Quality center and assigned a status and priority.  Any “show stopper” issues will be assigned a priority of P1.  Issue priorities are defined as follows:

P1– High - affects core functionality; prevents availability or interrupts testing; no workaround available.  Must be resolved ASAP.

P2 – Medium High - affects core functionality; interrupts testing; workaround available.  Must be resolved within 2 business days.

P3 – Medium - interrupts isolated test cases; UI problems; workaround available.  Resolution pending schedule.

P4 – Medium Low - affects isolated test cases; nice-to-haves; UI enhancements; workaround available.   Resolution pending schedule. 

P5 – Low – Cosmetic defects; workaround available.   Resolution pending schedule. 

P – Very Low – Deferred for future releases 

2.2          Entering Defects

Before entering a new defect, be sure to check for similar defects to avoid logging duplicates.  If you find a potential defect that is within the functionality of another track/module, be sure to work with the appropriate member of your QA team.  A daily defect meeting will be scheduled and is mandatory if you have any defects opened by you or assigned to you that are not of the status Closed.  Appropriate developer(s) and Business team members will also attend this meeting.

When logging a new defect for this track/module, field values should be set as follows:

Field	Required	Values
Assigned To	Yes
Browser	Yes	Firefox Internet Explorer Konquerer Mozilla Multiple Browsers Netscape Safari
Created Date	N/A
Defect ID	N/A
Defect Status	Yes	New Open Fixed Rejected Reopen Deferred Duplicate Closed Pending
Description	Yes
Detected By	N/A
Detected in Version	Yes
Modified	N/A
Priority	Yes	P1 - High P2 - Med High P3 - Medium P4 - Med-low P5 - Low P - Very Low
Project	Yes
Subject	Yes	drop down values automatically will be populated through the requirements tab For UAT – The Use cases have been listed in Subject for each build
CR - Cross Reference	No
Actual Fix Time	No
Closed in version	N/A	Linked to Version defined
Closing Date	N/A
Comments	No
Estimated Fix Time	No
Fix Date	No
OS	Yes	Operating System – Windows 2000, Windows XP, Macintosh and Linux
Planned closing Version	No	Linked to Version defined in the requirement
Reproducible	N/A	y-n field = when NO, Status will be closed
Re-work Counter	No	Should be behind the scenes
Root Cause	No	Boundary System Duplicate Caused by Environment Design Issue Development Issue New Requirement Changed Requirement Deleted Requirement Not in Use Case Prod/ Env. Issue Not Reproducible Pre Existing User Training Not a bug Cosmetic/Grammatical Database Issue Data Issue
CR Type	No	In/Out Cycle

2.3          Defect Status Workflow

An email will automatically be created and sent to the person in the Detected By field as well as the person in the Assigned To and Biz Owner field each time an issue is created or updated within Quality center.  As many “Closed” issues as possible will be included in the regression testing to occur in the production environment (pre-go-live).  Daily, cross-functional defect meetings will be held to ensure proper prioritization of all defects.

The following table lists the status values available for a defect, who a defect with each status should be assigned to, which Quality center Fields require updating when the status is updated, and any notes regarding the status.

Status	Assign To	TD Fields to Update	Notes
New	Dev Lead	All required	IT Track leads listed above.
Open	Developer, IT QA Analyst, Business QA, Business Owner	Status, Assign to, R&D Comments, Estimated Fix Time	Developers should resolve P1 issues prior to P2, P3, or P4 issues.  Open status is used for assigned, researching, in-progress, etc. tasks.
Fixed	QA team lead	Status, R&D Comments, Actual Fix Time	Coding completed and unit testing passed.
Closed	User who closed defect	Status, R&D Comments, Closing Date, Closed in Build, Closing Reason
Reopen	Dev Lead	Status, Assign to, R&D Comments	Include test scenario details during re-test.
Deferred	Business PM/ Business Owner	Status, Assign to, R&D Comments, Deferral Reason, Planned Closing Version	Business review and approval required for this status. Biz owners listed above.