It's all about the answers!

Ask a question

RQM - Test Environments, Lab Resources, and TCER relationship when using a custom adapter


Michael Haun (4921924) | asked Jun 25 '14, 12:28 p.m.
We test a database/hardware combination product (not a web or workstation product).

Currently, we have setup RQM test execution in the following way:

"Test Environment" = name is the hostname of the test machine where the test will run
Adapter machine = communicates between RQM and test environment


We have many different test machines that represent one *type* of environment.  For example, we may have a "full-rack" hardware environment type, and we have 5 machines that match this type.  Meaning, we may have a breakdown like the following for our test machines:

Full-Rack:                           Half-Rack:                           Quarter-Rack:
lxnz-fr01.lenexa.ibm.com    lxnz-hr01.lenexa.ibm.com    lxnz-qr01.lenexa.ibm.com
lxnz-fr02.lenexa.ibm.com    lxnz-hr02.lenexa.ibm.com    lxnz-qr02.lenexa.imb.com
lxnz-fr03.lenexa.ibm.com
lxnz-fr04.lenexa.ibm.com
lxnz-fr05.lenexa.ibm.com


A test on a "full-rack" could be done on any of the 5 machines.  The problem is the following...

If I understand things correctly, it is ideal to create your TCERs at the beginning of an iteration.  This helps to show how many tests you have planned and can help show progress.  However, we can't create a TCER for "TC1" and assign it to a test environment at the beginning of an iteration as we don't know exactly what test environment will be used when it comes time to execute the test (could be lxnz-fr01, or lxnz-fr02, etc.).  It would be ideal to be able to create more generic TCERs at the beginning of an iteration and then choose the test environment at run time.  But, I don't see how to do this.  From everything I can tell a TCER is tied to a test environment.

I'd imagine a lot of other organizations have this same conundrum but I can't see how to resolve this.  If we just create the TCERs at execution time then we lose some of the reporting/planning capabilities of RQM.

Anyhow, I can see the ideal is to define Test Environments to be more generic and representative of a type of environment (i.e. full-rack, half-rack, quarter-rack, etc.).  This is a bit of a wrench for us though, as this is the way we are defining command line adapter.  If you see my screenshot above you can see the "Machine" is the command line adapter instance.  It seems like the "Machine" should represent the lab resource (test machine).  This makes sense but then I don't see where we'd define/choose the command line adapter instances.  Is it completely incorrect to have our command line adapter machine set as the "Machine" in RQM?  If so, where should the command line adapter machine be defined in RQM?

Based on the way we have things now we need to be able to choose the following at execution time:

- Adapter instance
- Lab resource (test machine)

Is it possible to choose both of these things at execution time?  Or do we need to tie an adapter to a specific lab resource (have an adapter instance for each lab machine)?

To me it is sounding like we have two options:
1) Define an adapter for each lab resource (test env) so that when we are choosing the "Machine" we are essentially choosing a specific adapter/test env.
2) Rework things to have "lab resources" defined as our test environments.  This is the area I believe we need guidance as I am not sure how we would define our adapter and how the adapter would be chosen.


PLEASE HELP!  :-)

Thank you.




Comments
Michael Haun commented Jun 26 '14, 11:01 a.m.

This is a significant blocker for us.  Any direction, education, or comments will be greatly appreciated.

One answer



permanent link
Michael Haun (4921924) | answered Jul 03 '14, 3:35 p.m.
I've received some feedback from others outside of this forum and it seems the consensus is to use an instance of an adapter for each lab resource (machine).

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.