HP Quality Center is quality management software offered from the HP Software Division of Hewlett-Packard with many capabilities acquired from Mercury Interactive Corporation. HP Quality Center offers software quality assurance, including requirements management, test management and business process testing for IT and application environments. HP Quality Center is a component of the HP Application Life cycle Management software solution set. (Taken from Wiki)
I have been working in QC right from version 9.0 to 11.0. There are so many key functionalities added to the new version.
I hope most of them worked in Quality Centre as a Management Tool. Here I will explain for those who want to learn QC and its modules.
QC is a web tool, user can access from anywhere but only in INTRANET (specific to your company we). You cannot access outside of your company. Projects will be created and by QC Admins and the access to the projects will be given by QC Admins as per your Role. Quality Center has so many functionalities and a user cannot access all of them and can use most of them based on the access given.
- If you are a Test Analyst, you will not have access to delete any entity that’s created folder level.
- If you are a Test Analyst you will not have access to move the defects from Analysis status to retest status.
- If you are a Developer you will only have access to move the defects from Analysis status to retest status.
- If you are a Test Lead / Dev Lead , you will have most of the access
- If you are a Test Manager you will have access to all the functionalities existing in Dashboard module
Logging into Quality Center:
- Use the URL (Web Link)
- Login Name – Enter your User Id (Mostly Windows Login user Name)
- Password – Enter your password (You will be entitled to a Default password @ the time of user id creation and you can change the password by Tools à Customize à Change Password.
- After entering User Name and Password and Check the Authentication of your user name and password by clicking Authentication button.
- After Clicking it, it will show the Domain and Project Name that is assigned to you, If you are assigned to more than one project the use the drop down and select the Project that you wanted to work.
- You can change the project from the QC Home Screen (Top Left Corner) Change project.
Module 1à Dashboard Module:
In Dashboard Module user can see two types of View, Analysis and Dashboard View. Analysis view can be used to get the reports for the particular Test Sets, Defects from particular Test Sets and Reports from particular project. Dashboard views will be used by the Test Managers, and they can create a report across programme level. In each View you will have two folders, Public and Private. If you create any Reports under Private then it’s visible to the creator only but if you create a report in Public then it’s visible to all the users who are accessed to the Domain and the Project.
1. Analysis View
In this user can create a Graphical Report or Standard Report. There is a button (+), if you click you can see
Graph Wizard, New Graph, New project Report, New Excel Report and New Standard Report. Click on the type of the report that you wanted and choose where you wanted to post the report either in Private or in Public.
Now I am using New Graph functionality.
- Click on New Graph (Under Private section)
- Upon clicking you will get a New Window where you need to select1.
- Entity (Defects, Tests etc.,)
- Graph Type (Progress , Age, Summary, Trend)
- Graph Name (Project Name – User Specific)
- After creating the Test Report, you can see the Project Name that you have created under the Private Section. (Left Side of the tool)
- Click on the Project then check your right hand side, you can see 3 tabs, Details, Configuration and View.
- Details tab – the use can’t edit anything, its auto populates the values that we had given when created the project.
- Configuration tab – this is the place that we need set up what we need in the report.
- X- Axis – Choose from the drop down what you need to see in the X- Axis
- Y- Axis – Choose from the drop down what you need to see in the Y- Axis
- Grouped by – Choose the entity by which the X-Axis and Y-Axis needs to be grouped by
- And you can see a button Filter (Funnel Symbol) click on that then you will get a Pop up window where you need to set the target folder from where you get the data for the Graph.
- In that window you will have Filter and Cross filter tabs. Choose Cross Filter tab and you can see different sections like Defects, Test Sets, Requirements etc,
- Choose the Entity that you need, right now I want to show to my lead how many test cases that I have executed over a period of time so I will choose Test Set section.
- Under Test Set section you will have 3 radio button, click on the radio button that shows next to None radio button.
- At the end of the text box you will have (…) 3 dots. Click on it. It will take you to the Test Lab where you can see all the Test Sets created under a given domain.
- Select the Test Set that you want from the Test Set tree.
- And Click Ok now Click on View you can see the Graphical representation of the data that you have in your Test Lab.
- By Clicking Data Grid on View tab you can see the data in Numbers.
Module 2 > Management Module:
Management module will allow the Test Managers or Test Leads to set up the Cycle Start and Cycle End date to the given Test Set in Test Lab. A user can’t access a Test Set after the Cycle End date. This module can give the data to drive the Test Metrics related to Effort.
Module 3 > Requirements Module:
Business requirements are captured in this module. You can add the actual business scenarios or you can add the test conditions as requirements. You can add requirements by simple clicking the Add New Requirement button or you can upload using the Excel upload add in manager.
By capturing the Testable requirements we can achieve the requirement traceability. Suppose if you are testing a log in screen then you will set up a test condition as
‘Verify the Login Screen is working as expected by giving valid user name and password’
This test conditions can be furthermore explained in detail steps under Test Plan module.
The key points that we need to maintain when setting up the Test Conditions are
- We need to set the Priority to each test conditions
- We need to write the meaning full test condition name
- We need to choose the correct requirement type from the drop down box (Right top most corner)
- Author name will be auto populated from your Login credential (if I logged in then my name will be populated as Author name)
- You can’t delete a created Test Requirement whereas you can Cut and Paste into Recycle Bin folder. (Requirement, Test Plan and Test Lab modules will have the Recycle Bin to keep the rubbish contents)
- The created Test Conditions will be mapped to Test Cases from the Test Plan module. If you have not mapped then you can see Direct Cover Status as Not Covered, if you have mapped but not executed then you can see it as Not Completed, you have executed the Test Case if the test case is Passed or Failed then you can see it in Direct Cover Status.
Module 4 > Testing
Under Testing module we will have below mentioned tabs
Test Resources – This tab will be used for QTP to keep the Scripts
Test Plan – Marinating all detailed steps involved in particular Test Conditions
Test Lab – We will pull the test cases under Test Lab for Execution
We can simply add a Test Case using New Test button or we can write the test cases in spread sheet and upload it into QC using QC Excel Add in Manager.
The key points that we need to maintain when setting up the Test Plan are:
- Click on the New Test button , you can see a window opened
- Enter a Valid test name, mostly it should match with the name that we had given for test conditions
- Select the type of the test that we are performing (right top most corner)
- If you see any sections are marked as Red then it’s a mandatory column and you need to enter the value.
- Select the SDLC phase from drop down box like System Test, E2E Test, Regression Test etc
- Select the Priority from the drop down box, this priority should match with the priority that we had given for Test Conditions.
- Select the Test Type from drop down , what kind of testing that you are doing, like Functional or Non Functional etc.,
- Capability mostly Do Not Know
- Select the Application that you are going to work in and this will be pre-defined by the QC Admin team
- When you are creating the Test Case please keep the Reviewed question as Not Reviewed and assign the Reviewer name.
- Once you save the Test Case the Auto Email will be sent to the Reviewer.
- Now reviewer will be reviewing the test case and will set the status as Reviewed.
- Under the Description Section we need to enter the following details, these details will be pre-defined by the QC Admin team and will be populated to all the resources associated to the domain.
- We have set up the Test Case, now we need to map this Test Case to the Test Conditions. To do that please Click on the Test Case name from the left side pan so that you can see the below mentioned tabs on your right side
- Summary – All the details related to that test cases (what we had given when creating) will be populated
- Design Steps – will have the Details steps that will be performed on the Test Conditions
- Parameters – the data that needs to be passed for Automation Frameworks
- Test Configuration – auto populates the values
- Attachments – if you like to add any documents that related to this particular scenario you can add under this tab
- Requirement Coverage – from this tab we can search the Test Requirement (test conditions) that related to the test case and drag and drop using Select Requirement button
- Linked Defects – Defects can be attached to Test Case or to Test Steps. So the attached Defects will be shown under this tab
- Dependency – This tab is used for Automation tests, where you need to create dependency between different modules.
PS: After mapping the Test Conditions to Test Cases please go to Requirement module and check the Direct Cover Status, if the Status is Covered then leave it else Refresh it reflect the status.
We have set up the Test Conditions and Test Cases and linked them now we need to pull them into Test Lab and make them available to Test Execution.
Before pulling the Test Cases into Test Lab, please create a Test Set folder using New Test Set button. By Clicking it you will be getting a window where we need to enter the logical test set name.
Now we have created the Test Set and pull the test cases into test lab by going to Execution Grid tab in the Test Lab module and Click Select Tests this will take you to Test Plan module where you browse the test cases that you wanted to move.
Pull all the test cases that you wanted. All the modules in QC you will have the Select Columns button to customize the details that you wanted to display in the Screen, so play across the needed columns and make them available in your screen.
The key points that we need to maintain when setting up the Test Lab are:
- Running the Test Case
- You have Run button to execute the test case. In Run we will have Run With Manual Runner and Continue Manual Run.
- By simply clicking Run will lead you to Run with Manual Runner option. Now you can see the test steps that are written in Test Plan module.
- To pass the Test Case, we can click CTL+P to fail the Test Case CTL+F. Please attach a Test Evidence for each Test Case that you are executing.
- Do not execute the test cases more than one, if you do then it will create an Instance for each time that you are executing this will annoy your test reports
- If you kept a Test Step as Not Completed for any reason @ first time of execution and you wanted to execute that particular test step then choose Continue Manual Run under RUN tab.
- If you are failing a Step then you can create a Defect from Test Plan module.
- After failing the Defect, go to Linked Defects tab and Click Add (+) button it will take you to defect module from there you can create defect and it automatically linked to that particular step.
- If you are keeping a Test Case as Not Applicable then you need to attach a Evidence why this test cases are chosen as Not Applicable
- If you are keeping a Test Case as Deferred then you need to attach a Evidence why this test cases are chosen as Deferred
Module 5 > Defects
Defects can be added from Test Plan module or from Defect Module. If a Defect is attached to a test cases then please do link the test case to this defect. You can raise an Orphan defects without linking them to any test cases.
Go to defect module and click Add Defect button then you will get a window where we need to input the defect details.
- Summary – Brief description about defects
- There are few columns will be auto populated as per the QC configuration
- When we raise the Defects it will be in New Status as per the Defect Life Cycle
- Defect Type – We need to select the defect type from the drop down like Application Code, Requirement Defect etc.,
- Discovery Phase – We need to select on which phase the defect is Injected like System Test, UAT, E2E etc.,
And there will be more than 10 mandatory fields that we need to enter as per the project specific details.
- Description – Testers needs to give the detailed description about the defect in Description section
Test User Name/ID
Steps to Replicate
Test Data Reference
Test Case Reference [Test Case Name (Step number)]
Defect Life Cycle in QC
- New – (When the defect is created)
- Analysis – (When the defect is moved to Developers)
- Fix – (When the fix is given by the developers)
- Deploy –(when the developers deployed the defect fixed code into test environment)
- Retest – (When the code is ready for retesting)
- Closed – (when the defect is retested and closed by the testers – once you closed the defect we can’t modify the defect.
Note: User can’t jump from one status to another status by by-passing one status in between.
Setting up the Priority and Severity to the Defects:
Do you remember we have kept Priority to a Test Requirement when we have created in Requirement module? I have raised a Defect that related to the Test Case which was set to Priority Low then keep Defect priority as Low.
Cheers – Asik
Have you created , Updated , Deleted Face book account to know about DWH concepts ? Today in this post let me explain you what is the necessity and importance of the Data types in ETL Testing.
We will start with our known examples :
Can you fill 10 liters of water into a 5 liters container?
“No, the container can have only 5 liters of water, if you fill more than its capacity then it will burst :-(”
Can you use Salt instead of sugar to make Tea?
“No, then every one will stop drinking Tea :-(”
Can we name a Kid using Numbers?
“No, if we keep numbers , then how many duplicate persons exists in this world ? just Imaging if I was named as 10215 !!!!
Can anyone have their Bank balance as absolute number ?
“No, because every money that you spent is fractional amount ! you cant have $ 5 all the time , it would be $ 5.28 most of the time.
Can you have your mobile number more than 10 digit ?or Can you have your mobile number as alphabets?
“No, because the mobile number length is pre-defined and the number cant be alphabets”
Like the above example
Our Source files, Source tables , Target tables are constructed with limitations. You cant have or keep the data that you want. You can keep or have the data that what system can accept.
In every programming we have this data types , most of them who reads this post knew about basics of Data types.
INTEGER, CHAR, VARCHAR, DECIMAL, FLOAT etc.,
Most of the time developers are testers encounters problems because of the data typing in Data warehouse world are ,
1. Correct Data type is not chosen in Source tables
2. Correct length of the data is not received from the source system in the source file
3. Source is not giving the values as per the data types mentioned
4. Data got truncated when loading it into Target tables.
5.The amount column precision is not populated correctly as Teradata changes it to make round off value.
6.Regarding Dates, source will send them as var-char but when we load it into target tables we keep as DATE and the format
The Data type and its length will be designed it its DDL – Data Definition Language . If you want to know about the tables properties then please use the blow query
a) ” SHOW TABLE Database.Table_Name ” – this will give you all about data types, data length. Not Null, Null, Primary Key definitions
b) ” HELP TABLE Database.Table_Name” – this will give you all about the table.
As a Tester what we need to verify ?
Again as I said,
Check the data is matching with the data type mentioned in the spec.
Check any data truncation happened when source data is loaded into Staging tables
Check the data is the staging tables are as per the Staging tables DDL
Check the target table columns are loaded as per the Target tables DDL.
If it a Varchar columns from source ,then please take care of the space , invalid characters etc., right from source till staging tables, because data stage will not accept special characters
If its a Decimal column then make sure the precision is carried out till the target load
If its a Integer column then make sure you should not get blanks ans spaces from source
If its is a CHAR then check the length of the character that fit into this column
Like above we can add as many as much scenarios for Data Type verification.
Hops this blog helps you to understand what is the importance of the Data Types in ETL testing,
See you in my next post
Cheers – Asik
In general BI Projects will have 3 environments
Production – where our tested code will function in real time
Development – where developers develops and Unit tests the code
Test Environment (System Test / SIT / E2E / UAT) – where the developed code will be deployed for testing
Setting up a Test Environment for Business Intelligence project is critical because the data for different level of testing is different. Developers will develop the ETL code in DEV (development) environment and when the testing phase kicks of they will point their codes to Testing environments.
Why we need a separate environment?
1. ACCESS and Test Environment
Because Developers are the one who designs the code and they will keep on changing the code until it works. We don’t have the version control in Data Stage or in Teradata. The development environment is the open space for all the Developers involved and there are high possibility of irregular updates on the code so the DEV environment is loosely controlled. Developers will have INSERT / UPDATE / DELETE access to all the designs in DEV and Test Environments. But testers will have only VIEW access on VIEWS (will explain what is Table and View in my next blog). Tester can only verify the data is as per ETL Code , they cant update any record to make them correct as per requirement. And developers also should agree what ever defects found in our environment should be open in DEV environments.
2. Data and Test Environments
Data that used for Developing the code should be different to the data is used for testing why because developers used to create Test Data for UNIT testing, they are happy when the functionality is working fine as expected. So they are not interested source data quality. If any data causing trouble to them , they simply delete it and load the rest of the data. But testers should be very conscious about the data because data is the key for us to proceed the testing. So testers should have their own data in their own Environment. They should not depend on the source data that relies on Development environment.
What all components needs access for a Tester ?
1. File Landing Directory – If your project is File to Table load then Source system will send the Files to a specified location. This location is different for both Development and Testing. Testers should get the access to this Directory.
2. Select ACCESS to Source Views – Tester can easily check whether they have Select access to the tables by simply querying the tables.If you are not having access to the tables then please create a Grants statement and send to your DBA.
[GRANT SEL ON DB_Name to User_ID;]
Good practice availing the access:
- A tester should run his queries in Views not in Tables, so Leads should make sure that the testers should not have Select access to tables before they start execution.
- Developers are creating Views over the tables, and when they deploy the code into PRODUCTION their code will points to the VIEWs not TABLEs.
- Developers might have introduced few filter statements in Views in order to stop duplicates, which might cause errors. Suppose if testers are tested the Target data using Tables then the errors related to Views could not be identified.
- Testers should not have Insert, Update, Delete access to Source and Target tables.
- Testers should have Create table access on Test Database for manufacturing data (will be explained in Test Data Management Blog)
Availability of the Source Data in Test Environment:
If the data load is into Existing warehouse tables then check the historical data is available in the Test environment by simply selecting the table. If there no records in test environment then request developer to copy sample records from PRODUCTION data into Test Environment.
[INSERT INTO TEST_DB.TABLE SEL * FROM PROD_DB.TABLE SAMPLE 1000;]
Q: Why we should have existing data into Test Environment if it is load into existing table?
A: Because our load into existing should not be delta records for the existing records. This can be verified using the record count before and after the load – the count existing count should not be disturbed.
If the data load is into new warehouse tables then the tables should not contain any data in the Test Environment.
Q: Why we should not have any data New target tables?
A: Because these tables do not exist in PRODUCTION and we are the one going to load the data into these tables.
So it should not contain any data.
Reference Tables in Test Environment
MAP and TYPE tables are used for Referential Integrity. A project can use the existing MAP or TYPE tables or they
can create their own based on the project requirement
- Testers should verify all the MAP and TYPE tables mentioned in the S2T (even if it is not used in S2T transformation) are created in the Test Environment
- If the MAP or TYPE table exists then the testers should verify the data in Test Environment and PROD environment should be same.
- If the MAP or TYPE tables are created project specific then testers should verify the data is inserted correctly as per the Insert statements provide in S2T
- Tester should cross the values inserted into MAP and TYPE tables are matching with DDS (refer Appendix section for Reference data). If you find any data missing or added in the table please raise defect to Data designer.
Now we have everything in our Environment 🙂 Now we are going for Validation of Specification on next Blog.
See you @ my next Blog.
Regards – Asik