| || |
Action1 = the whole test
Hey all... New here.
So, I've recently started working in this test automation group, and I'm seeing that all of the test scripts written by my new counterparts all seem to contain QTP tests with a single "Action1" (they don't bother renaming it) which contains all the code for tests... with many many calls to UDF's in shared function libraries.
I think I understand how and why this is wrong... but what I'd like to know is: How common of a problem is this?
When I google something like "QTP difference between action and function", I keep seeing the same basic answers... but when I google something like "QTP when to use actions Vs functions", all I see are the same answers to the above - the difference. I don't find anyone who explains WHY you should use an action vs a function.
Just to clarify: I'm coming at this from the angle of: My group has this dream of automating everything and teaching non-programmers to create automated scripts.
Well, since you've just said that the way I do things is "wrong" and "a problem", I feel I should respond. I think the reason you're not finding the answer you want is because the answer you want isn't correct. I get the impression that you are searching for justification to tell the team they're doing things wrong. They aren't (not necessarily, anyway). Different methods work better in different environments.
I'm guessing you don't come from a strong coding background (because you call function libraries wrong and think a keyword-driven framework is a dream). Every team I've worked on that had a strong coding background, worked in exactly the way you describe. I would never recommend using actions in place of functions. Actions are harder to organize and harder to maintain. The main benefit of actions is that they allow UFT to handle iterations and input data for you. If your team can write the code for looping and data consumption, then there's not much need for UFT to do it.
You're right - It was rather brazen of me to call it "wrong" or "a problem"... I will acknowledge that there are many ways to solve a problem, and there is nothing inherently "wrong" with that approach, as long as it works.
Let me change my question...
How common is the use of a framework which focuses on QTP Actions as the basis for creating building blocks that can allow non-programmers to create automated test scripts?
You ask HP Sales rep's - Its very common
Originally Posted by MTerpstra
You ask UFT professional users - It's not common
I prefer the flexibility of function based code. IMHO UFT framworks build on functions are far more flexible than those based on Actions.
Originally Posted by mwsrosso
Actions seem like a great idea when you read the user guide and see the demo however in practice they are very difficult to manage and maintain.
Granted I've only been doing this for ~10 years, but in my experience (mainframe, web, desktop, database and a tiny bit of mobile) what Mark has said is absolutely correct.
If you want building blocks for automated tests that can allow non-programmers to create scripts, look at "BPT".
This sits inside both ALM and UFT and is exactly what you're dreaming of - drag and drop test creation - and it does work very well.
(and you'll still see "Action1" ;-) )
... just another Tester ...
Yeah, it sounds like BPT is exactly what your team is looking for. Also, sorry for the high level of snark in my first response. It was early and I was un-caffeinated.
Warning do NOT approach Dennis until he is "All Coffee'd Up"
VBScript has 2 constructs, Subroutines and actions. Sub routines do not return values, and functions do.
An Action is similar to a subroutine, but is a QTP construct that allows it to be used in their keyword framework.
So ideally, you want your low level reuseable code to be in the form of Functions, and SubRoutines (such as utilities like processing data). Then create composable test units (reusable levels of work, such as 'login', 'sign up'). Then in their Keyword tool, use these units of work, to compose tests in a human readable form that non-techies can read.
Switching from a reusable action design to calling reusable function libraries instead drastically reduced our automation run time. Actions have so much overhead that is just bloatware.
You don't need actions to build a framework that implements reusable blocks that can be put together by non-programmers.
Last edited by NoUse4aName; 03-15-2016 at 10:02 AM.
I generally write my UFT scripts using one action as a flow control (no decisions, loops, branches etc.) and everything else in Subs & Functions.
Works for me and anyone can "get the jist" of what the script is doing.