Agile Requirements Designer

 View Only
  • 1.  Variables resolution in block's fields

    Posted Oct 14, 2017 08:34 AM

    Hi all,

    I want to ask if someone may help me. I have the following need.

    I’ll soon come to the problem but first of all a preamble.

     

    I use CA-ARD v. 2.3.200.2 and in a flow I define variables and their values entering the block’s Properties pane, navigating to the Process tab, selecting  the entry from the left column called Test Data and clicking Add variable/value pair. Making so I create a fresh line with a value pair to fill out. The left field has a drop-down menu of selectable items (new or existing variables) while the right field is for entering data as a constant value or a Data Painter expression.

    I can also use the Find and Make CA-ARD ability to find data which is interesting for me (data attributes that match my visual flow) or if I cannot find them I can even make the data. This is possible because in my company I use Test Data Manager (TDM) with the Datamaker’s toolset and therefore I can set up Make or Find Data and then execute by block’s Find and Make data properties.

     

    Here it is my need.

     

    Subsequently when I generate and store the flow paths using path explorer with test case optimizer,  the defined variables rightly feed the Test Data and I can see it clicking the right button to open Test Data dialog.

     

    In my company  I use HP-ALM as test management system (TMS); so after having generated paths I export them to HP-ALM as manual test cases in a HP-ALM test plan tree folder associating visual flow blocks to test case steps.

     

    Because the actual CA-ARD/HP-ALM integration is not able to export to an HP-ALM test case test configuration the CA-ARD corresponding path row of Test Data table, is useless to reference into the blocks fields (for example the description or the expected result which I use to feed respectively the step action and expected results of the test case step corresponding to the visual flow block) the so-called HP-ALM parameters using the HP formalism <<<name of parameter>>> . In fact, in such a case I feed the HP parameter table of the test case but without an appropriate test configuration I can’t assign a value to parameters.

      

    So, trying to bypass the problem, I directly refer variables (defined by block tab Test Data in some block fields as for example description or expected result) using  the formalism ~variable name ~; but when I generate paths and export them as test cases to HP-ALM I find no variable substitution, as indeed I hoped, with the value assumed by the variable along the path.

     

    Therefore I ask to everyone is able to answer: Is indeed the described behavior  the product expected behavior or there is some mistake I did in the way I referred variables? (maybe I had to use the notation ^variable name^).

     

     If the observed behavior is right I think It would be an important product enhancement to implement variables substitution during “path generation and storing” to better a lot the interface between CA-ARD and HP-ALM making happy all TMS users.

     

    Thanks a lot and in advance.



  • 2.  Re: Variables resolution in block's fields

    Posted Oct 16, 2017 10:41 AM

    Hi Gaetano, 

     

    Thank you for the background and details around your question. We will review this and research an answer for you. I hope to have an update to you by end of day or tomorrow. 

     

    Best regards,

    Taylor



  • 3.  Re: Variables resolution in block's fields
    Best Answer

    Broadcom Employee
    Posted Oct 16, 2017 02:54 PM

    Let me answer with how I would like to see this solved in the long run, but would depend on the enhancement request being approved, but predicate that with two different ways of working around the issue.

     

    The issue here is you can't directly map a resolvable expression to ALM, nor can block fields like description, or notes, themselves be resolvable. This means getting data inline into a test case can be difficult.


    Workaround 1: When you upload to ALM, you can actually send the test data for each test case as an attachment, in the export screen just before you upload, there is a checkbox "Test Data as Attachments" - selecting this will send each row of test data up as a .csv attachment to it's corresponding use case.

     

    Workaround 2: Use the 'Automation' feature to create manual steps for users to follow, which can be interwoven with data. 

     

    Since you can make new Automation snippets on a new 'layer' whenever you please, you can create an automation snippet that simply loads the block description, then allows for some data reference:

     

     

    Then, you can add this to any block as usual, and provide a test data parameter value for ~DataRef~:

     

     

     

    Then, once we've added the reference to all of the blocks, we can generate Manual scripts like so: 

     

     

    Also, it's worth noting, just as I suggested how one would upload test data per path to ALM, the same option is available for our new Manual scripts too!

    Long term: I would agree, that all fields within ARD should be resolvable, which would allow you to write a description like: "Do this to ^that^, using the ^item^ for @randrange(100,500)@ ms".

    I will leave that to PM however. 

    Regards,

    Ben



  • 4.  Re: Variables resolution in block's fields

    Posted Oct 17, 2017 12:20 AM

    Hi Ben,

    let me thank you for the answer but as CA-ARD and HP-ALM user I want to make some remarks about the workaround.

    First of all keep in mind the preamble: I should like to generate HP-ALM manual test cases using CA-ARD interface.

     

    Therefore I model fine graned requirements by CA-ARD visual flow making a significant effort to describe step action and expected results in details of process blocks in the same way I would do using directly HP-ALM. Then making use of the various types of decision blocks I create the paths in the flow to coverage the requirement with the desired optimization technique. Subsequently I should like to export paths as “complete and definitive” manual test cases to HP-ALM test plan folder.

     

    Now by workaround 1 to make an effective use of csv attachment in HP-ALM test case, after having referred  step parameter in CA-ARD entity fields (for example block description) using HP-ALM notation (<<<parameter name>>>),  I should “translate” the spreadsheet row in a test configuration because  CA-ARD/HP-ALM interface does not perform this “translation” for me. Worst of all I must do this everytime I regenerate HP-ALM test cases after a functional change to the CA-ARD flow, so losing one of the most important (for me) CA-ARD advantage in terms of requirements change management effectiveness.  

     

    About workaround 2 it could be followed but in reality working in such a way it seems to me too cumbersome and ineffective.

     

    I indeed fully agree with your long term (that I hope short) solution, overall remembering that test cases are basically action, expected results and data.

    Finally I ask me and everyone why, and how difficult is, during HP-ALM test cases feeding, for CA-ARD interface to resolve variables, everywhere they are referred, just as it already happen in flow Test Data table?

     

    Hoping in PM I give you greetings.



  • 5.  Re: Variables resolution in block's fields

    Posted Oct 17, 2017 08:18 AM

    Maybe tayjo06 can comment as well. 



  • 6.  Re: Variables resolution in block's fields

    Posted Oct 22, 2017 06:02 AM

    Hi Taylor,

    please can you tell me if there are some good news about adding my need to the CA-ARD product backlog?

    I think, and I hope in the PM's same thought, substitution of variables with their value (constant or obtained via TDM) during path generation and storing would be a desiderable and powerful product enhancement, useful to improve significatively the export of CA-ARD flow paths as definitive test case (with inline data) in the several test management systems interfaced by CA-ARD.

     

    Thank you a lot and in advance

    Gaetano