Search This Blog

Thursday, August 19, 2010

HP QTP 10.0 and QC 10.0 Certification Details



Basically HP has come up with two types of Certifications, HP AIS(Foundation) & HP ASE(Advanced)
1. HP AIS Stands for Hewlett Packard Accredited Integration Specialist
* Below Exams need to be cleared for accomplishing HP AIS
--> HP0 M16 (QTP 9.2) -These got Expired
--> HP0 M15 (QC 9.0) -These got Expired
OR

--> HP0-M39 (QTP 10.0)
--> HP0-M31(QC 10.0)

HP0-M31 (old HP0-M15) and HP0-M39 (old HP0-M16)





2. HP ASE Stands for Hewlett Packard Accredited Systems Engineer
* HP AIS clearance is mandatory for appearing HP ASE

Before appearing HP AIS Certification exams, follow the below steps

Points to be known for appearing HP AIS Certification(QTP & QC).


Step 1: Navigate to the HP Partner Portal using the below link
http://h20375.www2.hp.com/portal/site/publicpartnerportal-ap/in/en/

Step 2: Click on Register link & complete the registration process.

Step 3: You will receive an email regarding your User Id & a Link Create New Password from Premium.support@hp.com & create a new pwd.

Step 4: Login into HP Partner Portal by your User Id & password , click on Train & Certify --> Request Access, it will take around 3 business days for creation of HP Learner Id.

Step 5: HP Partner Portal -->Train & Certify --> Access the Learning Center ->My Profile --> Edit Profile Snapshot change the required ISD time frames --> Save

Step 6: Login to HP Partner Portal --> Train & Certify --> Access the Learning Center --> Note down your HP Learner Id --> Contact Prometric Testing Center in any NIIT institute in your city for appearing the HP AIS exam.


After clearing the HP AIS Certification exams, below steps are required for achieving the HP AIS Certification - Soft Copy

Step 7: Once you have cleared HP0 M15 & HP0 M16 Exams, navigate to below path for knowing your Exam Successful Completion Status.
Login to HP Partner Portal -->Train & Certify --> Access the Learning Center -->My Learning --> My Transcripts

Step 8: Login to HP Partner Portal -->Train & Certify --> Access the Learning Center -->My Learning -->My Certification
Click on Add Certification & search for required certification (AIS HP Quality Center V9) & select the checkbox & then your certification will be added to the Certifications table & status field will be given as Assigned.

Step 9: Login to HP Partner Portal -->Train & Certify --> Access the Learning Center -->My Learning -->My Certification--> In Certification table,
check the Status field, if it is updated as Acquired in 1 week your certification will be uploaded into your HP Learner id Account.

Step 10: After 1 week , Login into HP Partner Portal --> Certification Program click on My E-Certificates, In E-Certificates HP Certified Professional Program page AIS HP Quality Center V9 Professional Letter A4 can be seen.

Step 11: click Letter or A4 & Save the soft copy/attachment into your system

How to view Results if error occurs while trying to open Results



Two files which got affected in displaying Results:
1) Results.xml and 2) GeneralInfo.ini.

Results.xml – contains all the test result data in the structured format. Due to abnormal closing of QTP, some tags in this xml file does not close properly, due to which test result viewer is not able to read it properly.

GeneralInfo.ini – once QTP execution is successfully done, it creates this ini file which initiates the result viewer and contains the required information to populate the result.

So whenever you get such an error, go to your result path (report folder). You will notice that there is no general info file has been created. In case it is there trying opening in notepad. You will find that no data is there. That means you will have to create this file in order to view the result.

Create a txt file in your report folder name it as ‘GeneralInfo.ini’ and Open it in notepad.

Write the text mentioned below –

[General] ‘ini file tag. Keep this intact
Product= ‘name of the product which will be QuickTest Professional
Version = ‘Version of your QTP
Total = ‘the number of total lines in the xml file for result (explained below)
Title= ‘Script Title
OSVersion = ‘version of operating system
TestLocation= ‘Test Path

Parameter ‘Total’ can be retrieved from the incomplete results.xml file.

Open the file in any file editor. Go to the end of the file. Search the first tag which contains from bottom.You will see a value assigned there to rID as in the below piece of xml.




Wednesday, August 18, 2010

Automated Regression Testing Challenges in Agile Environment

Abstract
Recently, when I wanted to start my new Automated Testing Project with four resources, I thought of applying any one of the Agile methodologies. But I was not able to continue because, a series of questions were raised inside my mind. The questions are like “Is it possible to use Agile methodologies in Automated Testing?”, “Can I use traditional tools”, “Should I have to go for open-source tools”, “What are the challenges I have to face if I am implementing automation in Agile Environment”. In this article let us analyze some of challenges we face while implementing Automation with Agile methodologies. Automated testing in the Agile environment stands a risk of becoming chaotic, unstructured and uncontrolled.

Agile Projects present their own challenges to the Automation team; Unclear project scope, Multiple iterations, Minimal documentation, early and frequent Automation needs and active stakeholder involvement all demand lot of challenges from the Automation Team. Some of these challenges are:

Challenge 1: Requirement Phase
Test Automation developer captures requirements in the form of “user stories”, which are brief descriptions of customer-relevant functionality.

Each requirement has to be prioritized as follows:

High: These are mission critical requirements that absolutely have to be done in the first release
Medium: These are requirements that are important but can be worked around until implemented.
Low: These are requirements that are nice-to-have but not critical to the operation of the software.

Once priories are established, the release “iterations” are planned. Normally, each Agile release iteration takes between 1 to 3 months to deliver. Customers/software folks take liberty to make too many changes to the requirements. Sometimes, these changes are so volatile that the iterations are bumped off. These changes are greater challenges in implementing Agile Automation testing process.

Challenge 2: Selecting the Right Tools

Traditional, test-last tools with record-and-playback-features force teams to wait until after the software is done. More over, traditional test automation tools don’t work for an Agile context because they solve traditional problems, and those are different from the challenges facing Agile Automation teams. Automation in the early stages of an agile project is usually very tough, but as the system grows and evolves, some aspects settle and it becomes appropriate to deploy automation. So the choice of testing tools becomes critical for reaping the efficiency and quality benefits of agile.

Challenge 3: Script Development Phase

The Automation testers, developers, business analysts and project stakeholders all contribute to kick-off meetings where “user-stories” are selected to next sprint. Once the “user-stories” are selected for the sprint, they are used as the basis for a set of tests.

As functionality grows with each iteration, regression testing must be performed to ensure that existing functionality has not been impacted by the introduction of new functionality in each iteration cycle. The scale of the regression testing grows with each sprint and ensures that this remains a manageable task the test team use the test automation for the regression suite.

Challenge 4: Resource Management

The Agile approach requires a mixture of testing skills, that is, test resource will be required to define unclear scenarios and test cases, conduct manual testing alongside developers, write automated regression tests and execute the automated regression packages. As the project progresses, specialist skills will also be required to cover further test areas that might include integration and performance testing. There should be an appropriate mix of domain specialist who plan and gather requirements. The challenging part in the Resource management is to find out test resources with multiple skills and
allocate them.

Challenge 5: Communication

Good communication must exist among Automation testing team, developers, business analysts and stake holders. There must be highly collaborative interaction between client and the delivery teams. More client involvement implies more suggestions or changes from the client. It implies more bandwidth for communication. The key challenge is that the process should be able to capture and effectively implement all the changes and data integrity needs to be retained. In traditional testing, developers and testers are like oil and water, but in agile environment, the challenging task is that they both must work together to achieve the target.

Challenge 6: Daily Scrum Meeting

Daily Scrum Meeting is one of the key activities in Agile Process. Teams do meet for 15 minutes stand up sessions. What is the effectiveness of these meetings? How far these meetings help Automation practice Developers?

Challenge 7: Release Phase

The aim of Agile project is to deliver a basic working product as quickly as possible and then to go through a process of continual improvement. This means that there is no single release phase for a product. The challenging part lies in integration testing and acceptance testing of the product.

If we can meet these challenges in a well optimized manner, then Automated Regression Testing in Agile environment is an excellent opportunity for QA to take leadership of the agile processes. It is better placed to bridge the gap between users and developers, understand both what is required, how it can be achieved and how it can be assured prior to deployment. Automation practice should have a vested interest in both the how and the result, as well as continuing to assure that the whole evolving system meets business objectives and is fit for purpose.

How to Manage Automation Expectations:

How to Manage Automation Expectations:
In order to implement a successful automation effort, testers need to educate management on a number of different issues. Educating management on these issues could mean the difference between a successful automation effort and a failed automation attempt.


One such important issue addresses integrating test automation into the entire development process. Testers need to educate senior management as well as script writers on how a specific tool will fit into their software development environment and software development life cycle. It is equally important to remind everyone that manual testing does not end when automation is implemented.


Another issue concerns the purchasing of tools and their impact on test planning. Test planning, planning what to test and how to test, becomes much more complex and more important when a tool is purchased. For example, test automation is rarely justified for all testing. The tester needs to determine what tasks make sense to automate and what does not make sense to automate.


Moreover, the organization needs to understand that automation does not eliminate manual efforts on the part of testers. Testers need to maintain automation scripts and verify the execution of automated scripts. This is manual work that needs to be factored into the test team's testing activities.


In addition, in order to automate successfully, testers need training and time to master the test tools. Many managers view the test tools as simple capture / playback programs which a tester can learn and implement in his spare time. This is a misconception. Successful test automation frequently requires the use of complex tools — tools which are much more complex than the just capture / replay tools. In order to use these tools effectively, testers need considerable training. Management needs to be committed to training testers on these tools and to establishing the infrastructure in which the tool operates.


Also successful test automation requires the involvement of the software development team as well as testers. In the past, developers and testers had minimal contact. Frequently, the philosophy was to "throw code over the wall and see if it works". This type of interaction does not work when automating the testing process. Developers and testers need to work much more closely together. Developers have to provide support personnel and technical information on their development methods. They can be asked to use the automation tools during their unit and integration testing. More troubling to the developer will be that test automation may raise concerns about the testability of their code. This especially will be the case if standards are not followed, or if developers use odd, homegrown or even very new libraries / objects.


The organization’s project management team must have a clear understanding about the types of roles and responsibilities required for a successful automation effort. The creation of the test environment starts when an organization purchases hardware and installs a tool. Then the test team and development team need to work together to build and maintain a test automation environment that may include dedicated servers, workstations, databases and the like. Management needs to include development of the test environment in the overall project plan. They should also budget for the resources needed to successfully automate testing.


Successful tool automation depends not only on the test tools but also on a standard testing process and the right test team roles, duties and skills. Tools, process and test teams are the three essential legs of the test automation stool.


Moreover, the automation test team needs to have a blend of testing, programming, and tool knowledge. If an organization wants to reap the automation benefits promised by tool vendors, it needs to use the tool as a complement to manual testing. It also means adopting a strong test methodology and training the test team on the ins and outs of the selected tool in an organization's unique development environment.