HP Quality Center - ALM(Application Layer Management)

HP Quality Center - ALM(Application Layer Management)

HP ALM formerly known as Quality Center is a Test Management tool to manage entire Quality Assurance and testing process for an organization. Before being called HP Quality center it used to be Mercury Test Director.

• HP's  Quality Center is a comprehensive test management tool and is a topped - up version of Test Director
• Quality Center is a  web- based  tool ( client - server architecture) and  helps maintain a database of tests. 
• Quality Center is a one stop shop for all testing related tasks and provides for easier analysis , test management and test tracking.

Why is Quality Center/ALM used?

Quality Center/ALM helps project management, from requirements to deployment easier. It acts as a framework to manage projects from a central repository.  With the help of Quality Center/ALM we will be able to handle the following things:

1. Define requirements.
2. Create Tests.
3. Execute Tests.
4. Log Defects.
5. Integrate with HP testing tools such as QTP, load runner.
6. Collect metrics.
7. Track a progress of a project.

Application LifeCycle of Quality Center/ALM flow:

How to access Quality Center/ALM?

Step 1: To start Quality Center/ALM, type the address http://<IP address>[<:Port number>]/qcbin

Step 2:  Click “Application LifeCycle Management”.

Step 3: Enter the user name and password. “Authenticate “button gets activated. Click on it. The Domain and Project fields get activated. Depending on your login credentials you have access to certain projects. (This information is set by your ALM Admin).

Step 4: Choose the Domain and Project as required and click “Login”. Once you are logged in, ALM window opens up and displays the module in which you were working last. 

Domain is nothing but a logical division of departments for your organization. Example: Banking, Retail, Health Care etc.

Projects are the different teams working within the domain. For example in a Retail project, they could be working on the front end store Point of sale app or the back end inventory module.

Step 5: The user domain, Project and user information is displayed on the upper right hand corner. Also notice the side bar. It contains the components from the Quality Center/ALM flow.

• Dashboard
• Management
• Requirements
• Testing
• Defects

Why We Need Stubs And Drivers?

Stubs and drivers handle in integration testing being a top down integration testing and bottom up integration Testing.

While doing Integration, if we don’t hold all the modules get covered and urge to test a particular module which is covered then We Use Stubs and Drivers.

Stubs are dummy modules that are distinguish as "called programs", that is handle in integration testing (top down approach), it used when sub programs are under construction.

Stubs are the dummy modules that simulate the low level modules.

Drivers are also form of dummy modules which are distinguished as "calling programs”, that is handled in bottom up integration testing, it used when main programs are under construction.

Drivers are the dummy modules that simulate the high level modules.

Example of Stubs and Drivers is given below:-

Considering example if we have modules login, home, user. Login module is ready and urges to test it, but we call functions from home and user (which is not ready).

To test at a selective module we write a short dummy piece of a code which simulates home and user, which will return values for Login, this piece of dummy code is always called Stubs in a top down integration.  

Resembling to the above example: If we have Home and User modules get ready and Login module is not ready, and we urge to test Home and User modules Which return values from Login module,

So to extract the values from Login module We write a Short Piece of Dummy code for login which returns value for home and user, So these pieces of code is always called Drivers in Bottom Up Integration.

Acceptance Testing

This type of testing is done by the engineers sitting in the customer place just after the product is delivered.

Let say Wipro has signed a contract with Fedx to deliver a product on X th day. Assume that a critical bug has occurred just few days before the delivery of the product.
   Now if the company asks for more time from the customer, then the company will be accountable for the further billing i.e.company will be accountable/pay the expenses till the product is released.
But the project manager cant delivery the product having bugs on the release date bcoz the customer will not accept the product blindly, instead will the test the product in detail. This verification is done by test engineers. This kind of testing is called as Acceptance Testing.
     Almost every company will have its own IT division. If a company wants a software to be developed, it will send the requirements across companies and its own IT division will bid for it.
 The company with the best bid and good plan/layout will get the contract and the preference will be given to its own IT division if only it has the best bid or best bid will get the contract.
For Eg: Wipro will do only Functional testing, Integration Testing and System Testing. But Fedx will do Acceptance testing with the other 3 types of testing .

The acceptance testers will have domain knowledge on the product or will hire the domain experts or train them.

Case1: Engineers at the customer place will do acceptance testing based on the real time scenarios, these engineers will have enough domain knowledge.

Case2: If the project is too big and the IT division is too small. The customer doesn't have enough engineers to do acceptance testing, then the product is given to some of the staff of the Fedx (for whom the product is developed) for do testing it for a particular period of time(dummy implementation of real time business takes place). The staff is trained on the product and  then they start testing it or experiment it.
Here the acceptance testing is done by a user who is an end user.so it is called as UAT.

The end user uses the product in real time scenarios and tests the application or is the product is working fine without any error before release of the product on the production floor,

Case3: If the customer doesn't have sufficient staff to test the product once it released and customer doesn't have enough budget to hire new engineers or outsource the product for doing AT. In this case, customer will call the wipro engineers to do the acceptance testing who already on domain knowledge and have done testing on the product. The test lead of the customer monitors these engineers who will have to execute the real time scenarios.

Case4: Instead of calling the test engineers, the test lead will go to the company and monitors the test engineers by providing new real time scenarios for testing

Acceptance testing takes 2 to 3 cycles of testing.

What is Defect?
Deviation for requirement specification is called as Defect.

Difference between Defect, Bug, Error and Failure?

Deviation for requirement specification
Bug is an informal name given to defect.
Mistaken done in program resulting unable to compile or run.
Defect causes Failure. One defect can cause multiple failures.

Why Defect is rejected?

Case 1: Misunderstanding of requirement - if a feature is misunderstood as a bug or sometimes Dev may give justiifcation saying its a feature not a bug.

Case 2: Referring to an old requirement - if the feature is removed from the template and the tester is testing the module and raises a defect.

Case 3: Extra implemetation - extra feature is developed which is not there in the requirement specification.

Duplicate Bug:

For example Tester 1 and Tester 2 are testing some common application and find a defect with the application. Both the testers raise the defect for the same. If tester 1 has raised the defect first and tester 2 raises the defect second, then tester 2 defect become duplicate bug.

Case 1: Commom Features - Common features are tested among the testers.

Case 2: the above example

Case 3: Known bug - if tester1 has already raised a defect for the application1 and starts testing application2. Tester2 starts testing application1 and finds the same issue in app2 and raises a defects then this defect becomes duplicate bug.

Why a defect/bug cannot be fixed?

Case 1: Technology only is not supporting, there is no solution for fixing this bug in that programming lang.

Case 2: Its a minor bug and the technology itself is not supporting for fixing this defect.

Case 3: Cost of fixing the bug is more than cost of the bug.

Case 4: if the defect is present in the root of the product.
Eg: if youfind a defect in the root of java, then fixing that bug will affect the other features in java.

Defect is not able to Reproduce?


Case 1: Improper Defect Report - steps to reproduce the defect is not mentioned correctly

Case 2: Data Mismatch - login as abc and click on inbox page, results in blank page. So log a defect and the dev team will login as xyz and click on inbox page, pages opens. Here mismatch of account id)

Case 3: Inconsistent Defects  - Reproducing the defect is inconsistent.

Case 4: Platform Mismatch - OS / Browser mismatch


Why a defect is postponed/deferred?

Case 1:If the defect is minor one.

Case 2: Dev team accept the defects, but takes time in confirmation fromcustomer if this is valid or invalid.


Why a bug is RFE(Request for Enchancement)

When you find a defect and the feature is nto available in the requirement, but developer accepts the bug, so that can be RFE.  Getcutomer approval and fix the RFE.

cross scripting attack demo

click here to know about XSS attack

Web Application Load, Stress and Performance Testing Using WAPT

Why most of the manual testers fail when testing websites for performance? There are couple of reasons.
- They don’t have proper tools to test website for performance and
- They don’t have required skills for performance testing.

Does that mean you should wait till your stakeholder report the performance glitches in web application you developed? Definitely not. Many testers are good at testing websites manually and they report almost every defect while testing under standard tests. BUT, when same tester performs load or stress tests they stuck either at resource (required tools) or skill level.

I suggest not to take any risk if you are committed to defect free service. Ask for required tools and train your staff for necessary skills. Today, I’m going to review load, stress and performance testing tool for websites. The tool is called WAPT – Web Application Load, Stress and Performance Testing

WAPT allows you to perform website load and performance testing by creating heavy load from a single or multiple workstations. When you set and run your tests with this tool within a matter of minutes you can get performance report of your website or web application. WAPT uses powerful virtual users same as the real world users with full control over how to customize these virtual users.

Measuring website performance:

Did you ever wonder?
- How many users can work simultaneously on your website with acceptable quality of service?
- How many visitors your website can handle by day or hour?
- What is your website response time under load?

These all questions are nothing but the measure of website “performance characteristic”.

WAPT – website performance tool performs test by emulating activity of many virtual users. Each virtual user can have its own profile settings. You can have thousands of virtual users acting simultaneously on your website performing any activity like reading or writing with your web server. Once you set number of virtual users to act on your website you have option to run your tests for specified time or specified user sessions.

Analyzing the test report:
Test result consists of charts updated in real time which you can monitor when your tests are running. The final comprehensive report is provided at the end of the tests.

Here are the important parameters to be monitored on the test report:
Error Rate: Failure rate against total number of tests run. The error may be due to the high load on server or due to the network problems and timeouts.

Response Time: Obviously a great parameter to check when you run tests for website performance. This response time indicates time required by server to provide correct reply to the request.

Number of pages per second: Number of page requests successfully completed by server per second.
How to conclude performance tests?
These performance criteria change during each test-pass with different load conditions. You need to conclude what is your acceptable load limit and whether your server is able to serve this load.

E.g.: If you expect your server to handle 100 requests successfully per second then anything below this will be failure of your server which needs to be tackled.

How to Record tests:

WAPT works like any other record and playback tool but the real strength is behind it’s parametrization where you can configure any parameter from website url or user session to act as a real user.

Testing with WAPT in simple 5 steps:
Record->Configure->Verify->Execute->Analyze

WAPT uses inline Microsoft internet explorer which is used to record your interaction with website. When you record your test all dynamic parameters are recorded as static values which can be configured later while test execution. You then need to configure each user with different settings like unique sessions, number of virtual users, values for dynamic parameters etc. Once you done with recording and configuration just verify your test if it’s ready to run and then execute performance tests if everything looks ok. Finally analyze reports to decide website performance test as accepted or failed against your set of defined standards. That’s it.

WAPT is available in two versions
- Standard version (Latest WAPT 7.1)
- Professional version of this stress and performance testing tool (Latest WAPT Pro 2.1)

What WAPT Pro can do for you?
- Use several computers to generate load on website
- Measure web server performance in terms of CPU, RAM or network usage
- You can include the execution of a JavaScript code into virtual user profiles.

If you don’t want to specify every parameter manually you can use some technology specific modules to significantly improve your test experience.

Following additional modules can be downloaded and installed along with standard or professional version of WAPT:
- Module for ASP.NET testing
- Module for Adobe Flash testing
- Module for JSON format

Finally, any review can’t be complete without the list of Pros and cons.

WAPT Pros:

- Easy to install – Takes only 5 minutes to install
- Easy to use with very short learning curve
- You get run-time reports so that you can decide whether to continue the test or not, saving your big time.
- Detailed test report with graphical representation.
- Supports secure HTTPS protocol.
- 30 days free trial available!

WAPT Cons:

- Only windows platform supported to install this tool. (But you can test your website running under any OS and technology)
- No scripting ability
- It’s not free

How to try this tool?
You can download 30 day trial version of WAPT from here.

What is difference between Performance Testing, Load Testing and Stress Testing?

1) Performance Testing:

Performance testing is the testing, which is performed, to ascertain how the components of a system are performing, given a particular situation. Resource usage, scalability and reliability of the product are also validated under this testing. This testing is the subset of performance engineering, which is focused on addressing performance issues in the design and architecture of software product.

Performance Testing Goal:

The primary goal of performance testing includes establishing the benchmark behaviour of the system. There are a number of industry-defined benchmarks, which should be met during performance testing.

Performance testing does not aim to find defects in the application, it address a little more critical task of testing the benchmark and standard set for the application. Accuracy and close monitoring of the performance and results of the test is the primary characteristic of performance testing.

Example:

For instance, you can test the application network performance on Connection Speed vs. Latency chart. Latency is the time difference between the data to reach from source to destination. Thus, a 70kb page would take not more than 15 seconds to load for a worst connection of 28.8kbps modem (latency=1000 milliseconds), while the page of same size would appear within 5 seconds, for the average connection of 256kbps DSL (latency=100 milliseconds). 1.5mbps T1 connection (latency=50 milliseconds) would have the performance benchmark set within 1 second to achieve this target.

For example, the time difference between the generation of request and acknowledgement of response should be in the range of x ms (milliseconds) and y ms, where x and y are standard digits. A successful performance testing should project most of the performance issues, which could be related to database, network, software, hardware etc…

2) Load Testing:

Load testing is meant to test the system by constantly and steadily increasing the load on the system till the time it reaches the threshold limit. It is the simplest form of testing which employs the use of automation tools such as LoadRunner or any other good tools, which are available. Load testing is also famous by the names like volume testing and endurance testing.

The sole purpose of load testing is to assign the system the largest job it could possible handle to test the endurance and monitoring the results. An interesting fact is that sometimes the system is fed with empty task to determine the behaviour of system in zero-load situation.

Load Testing Goal:

The goals of load testing are to expose the defects in application related to buffer overflow, memory leaks and mismanagement of memory. Another target of load testing is to determine the upper limit of all the components of application like database, hardware and network etc… so that it could manage the anticipated load in future. The issues that would eventually come out as the result of load testing may include load balancing problems, bandwidth issues, capacity of the existing system etc…

Example:

For example, to check the email functionality of an application, it could be flooded with 1000 users at a time. Now, 1000 users can fire the email transactions (read, send, delete, forward, reply) in many different ways. If we take one transaction per user per hour, then it would be 1000 transactions per hour. By simulating 10 transactions/user, we could load test the email server by occupying it with 10000 transactions/hour.

3) Stress testing

Under stress testing, various activities to overload the existing resources with excess jobs are carried out in an attempt to break the system down. Negative testing, which includes removal of the components from the system is also done as a part of stress testing. Also known as fatigue testing, this testing should capture the stability of the application by testing it beyond its bandwidth capacity.

The purpose behind stress testing is to ascertain the failure of system and to monitor how the system recovers back gracefully. The challenge here is to set up a controlled environment before launching the test so that you could precisely capture the behaviour of system repeatedly, under the most unpredictable scenarios.

Stress Testing Goal:

The goal of the stress testing is to analyse post-crash reports to define the behaviour of application after failure. The biggest issue is to ensure that the system does not compromise with the security of sensitive data after the failure. In a successful stress testing, the system will come back to normality along with all its components, after even the most terrible break down.

Example:

As an example, a word processor like Writer1.1.0 by OpenOffice.org is utilized in development of letters, presentations, spread sheets etc… Purpose of our stress testing is to load it with the excess of characters.

To do this, we will repeatedly paste a line of data, till it reaches its threshold limit of handling large volume of text. As soon as the character size reaches 65,535 characters, it would simply refuse to accept more data. The result of stress testing on Writer 1.1.0 produces the result that, it does not crash under the stress and that it handle the situation gracefully, which make sure that application is working correctly even under rigorous stress conditions.