Preferable way to run UFT scripts in ALM/QC - for someone with no UFT experience.
If you have to ask someone, who has very little or no UFT experience (in short Manual Testers), to run your UFT automated scripts setup in ALM/QC, what would be the best way or preferable way?
Show him/her how to execute the tests in ALM/QC (like the way the automators would do)
Execute the tests using a batch file in CMD prompt
Please share any example, if you have any.
Last edited by Gilbert; 03-03-2017 at 09:23 AM.
Reason: additional info
Doesn't get much easier than pressing the run button in QC. I would prefer that over a command line run. Best to just have the whole execution automated itself and running nightly and then just have manual testers check any failed scenarios to determine if it was an application bug or an automation failure. If you're watching automation any time other than debugging you're doing it wrong.
Last edited by NoUse4aName; 03-03-2017 at 12:44 PM.
Post Thanks / Like - 1 Thanks, 0 Likes, 0 Dislikes
I agree with NoUse4aName.
In a case where the user does not have ALM I would recommend running from a batch file that starts UFT.
The script could create reports that the user can get to without having to open UFT.
There is now a version of UFT that is only for running scripts. I have not tried using this but it may be a good way to make sure that the user does not have access to change the scripts.
When in Florida, Don't Tampa with the code. I made this up.
1. I would teach my tester how to use templates in HP ALM/QC and ask them to attach screenshots to their templates (assuming its GUI)
2. I would teach myself to have HP UFT function to follow the template names used by the testers
3. teach more to my testers in testcases (build out of templates) to use shorthand specification(s) like click, check, snapshot as dataparameters which then
a. easily can be interpreted for manual testing
b. easily can be transformed for automated testing
4. over time more communication on whats the input for automated testing (the more structure the quicker automating will go) and the specification of testcases will improve for manual and automated testing
Starting scripts from testlab is probably easiest if testers already know hp alm/qc product.
I start my scripts from a powershell and not from hp alm during creation/maintenance of the scripts
Powershell meets HP UFT
and with the runtime it just becomes
$qtApp.Test.Run Nothing, true, False
Thank you guys for your suggestions.
This is all for our offshore team in India. The automators there do the execution of the automated scripts. Manual testers refuse to run because they say it's too complicated for them. They know QC/ALM but not UFT.
My suggestion is to create a very easy to follow step-by-step instructions full of screenshots and examples. Plus some hands-on Training of course. If they can't follow that, then that's another problem - why they got hired in QA in the first place? If tools like Camtasia Studio is available, that is even better for creating the instructions with voice/video that can be saved in different formats.
Others are suggesting to create a new tool with much easier GUI than ALM/QC. I said "We paid lots of money for ALM/QC and will create something from scratch?".
Still others suggested to use MS Excel for executing the automated tests. These people have very little idea on automation, I guess.
So until now, no decision has been made after so many hours spent in meetings already and more coming. Wow!
Last edited by Gilbert; 03-23-2017 at 09:13 AM.
Reason: additional info...
Yeah should be very easy to get offshore candidates familiar with ALM/QC(including running automated tests from it). Unless the existing ones have highly valuable product knowledge that is not in house I would definitely advocate to replace. No reason to train off shore folks on basic industry standard tooling. What are you paying for exactly then?
The age of the "manual tester" is coming to an end. Most roles require automation experience as well where it is expected to do both while embedded in an agile development team.
I can't ever see manual testers disappearing, I think there will be a big move away from manual testing to automation, 85% auto / 15% manual perhaps but never 100%. Well not until they can replace the 'Mark One Eye Ball"
Just my opinion but one I strongly believe.
There will still be a need to manually test things absolutely. But that is becoming more often the side job of an automated tester rather than a job in itself.
The preferable way to run UFT scripts in this case is undoubtedly via ALM/QC. Manual testers are familiar with ALM/QC and I assume that they execute manual test cases from ALM/QC.
Originally Posted by Gilbert
Executing automated scripts is no different than this. Automated scripts are also executed from Test Lab. The only additional step here is to changing 'Automation Parameters' for the UFT scripts, assigning Testing Hosts and analyzing results. Guess this is very intuitive for them.
This is an interesting case and is very much similar to the issue I am facing & trying to solve. This usually points an underlying problem with the automation framework. At least that's the case with me.
Originally Posted by Gilbert
I suggest you take a closer look at the framework to understand how test scripts are setup and executed. In addition, look at how test results are generated and how easy is it to interpret results and analyze failures(i.e distinguish between technical failures and application failures). And most importantly, look at how Test Data is linked/consumed by the Test Scripts. Is it easy for Manual Testers to change/update test data for say each run or different test environments. This would help find answers for why manual testers see test execution as complicated.
In my case, the Manual Testers would like to run the Test Scripts themselves but they can't because of framework issues. The framework is too complex & the design is bad, that you can't run a script by clicking the Run button in UFT or from Test Lab. In order to re-run a script, you have to reset certain 'Flags' in the DB, for each script (DB is used by the Test framework). This 'Reset' activity is not part of the automation script but performed manually via a Framework GUI, before each test run. Also you have to set Test Environment values, by editing config files manually on the Testing Host, for running test scripts against different environments.
Therefore we can't schedule our tests or run our tests automatically but can only perform 'Manual Automation'. We have 'test executors' trained to execute these tests. In short, it's not just Manual testers that feel automation as complex but also automaters.
It's very important to find the core issue that, stops automated scripts to be run in an automated fashion or makes it complex, that only specialized resources can execute and analyze results. We have to solve this issue to make test automation available to all, in order to succeed with Test Automation.