Hi,

I’m looking for areas (not actual test cases) of testing for ADDM as well as CMDB-integration, the areas I have thought of so far are (and not in any order):

• ADDM LDAP integration test
• CMDB-sync. test
• CMDB-filter test
• ADDM consolidation test
• ADDM snapshot test
• Custom application test
• ADDM test of data quality against a target host

Any other points to those mentioned above that can be good to include?

BR,
Anders

I would say it depends why you are putting together such a suite of tests. If you plan to run your tests when you upgrade, deploy new instances of ADDM or make major changes to configuration, then I would list all features of ADDM that you make use of and what data you rely on.

So for example, you mention CMDB so I assume you integrate with that. And I assume you use consolidation. Something else that springs to mind is testing an initial scan v re-scans of same endpoint…depends how detailed you want to go.

If you have processes in place for detecting certain scenarios (random example – changes to deployed packages) then you could set up an end-to-end test to ensure you can get at the data you want.

Might be worth mentioning you can use playback mode to run some tests against controlled (or non-changing) endpoints

If it’s not a silly question, what for?

N.B. Record / playback only works in the same version of the product, so not across upgrades.

Tim Cannon - 08 February 2012 10:58 AM

I would say it depends why you are putting together such a suite of tests. If you plan to run your tests when you upgrade, deploy new instances of ADDM or make major changes to configuration, then I would list all features of ADDM that you make use of and what data you rely on.

So for example, you mention CMDB so I assume you integrate with that. And I assume you use consolidation. Something else that springs to mind is testing an initial scan v re-scans of same endpoint…depends how detailed you want to go.

If you have processes in place for detecting certain scenarios (random example – changes to deployed packages) then you could set up an end-to-end test to ensure you can get at the data you want.

Might be worth mentioning you can use playback mode to run some tests against controlled (or non-changing) endpoints

As of now, I’m just looking to retrieve some input of areas where I feel a test case might be suitable.

Hi Anders,

You don’t say what the purpose of your tests is, and without that it’s not possible to say what areas you would be suitable to look at. Your current scope of “ADDM and the CMDB integration” covers about 98% of the product code, so the short answer would be everything listed in the documentation. Can you tell us what gave rise to the requirement?

Hi Mark,

My apologies for not being clear enough.

Generally speaking, the test cases cover a deployment (which through regression testing should be used for updates of ADDM as well as the OS) for a solution which covers both appliances for scanning, consolidation as well as a synchronization towards a CMDB.

Naturally, I’m not looking to cover anything listed in the documentation (nor the product source code), but it should cover the most fundemental areas of such (as mentioned above) implementation. I understand that “fundemental” might be a subject up for discussion, hence the question of trying to retrieve input from various sources to what “they” (visitors of this forum) feel are those areas.

Thanks for the help.

Generally speaking, the test cases cover a deployment (which through regression testing should be used for updates of ADDM as well as the OS) for a solution which covers both appliances for scanning, consolidation as well as a synchronization towards a CMDB.

Given that, it seems that the most beneficial places to direct effort would be anywhere that might be particular to your environment, or where it interfaces with your environment.
It’s reasonable to assume for instance that a pair of newly upgraded appliances at the same version will happily consolidate; but if you have some custom patterns deployed, they would certainly warrant checking.

Don’t forget item 1 on the plan is to go through the release notes before even running the upgrade; any foreseen potential issues that might require your action will be noted in there. It could also highlight areas of product change that coincide with areas of deployed customisation.

In an ideal world there would be some sort of ‘deployment document’ for a site, which details what changes are made from a clean appliance. Each one of those customisations could then be accompanied by a test that proves it works. If you can’t define a test that shows a customisation is working when you decide you need the customisation, you probably never can.

For ADDM, much of the product tries to help here too; highlighting non default discovery scripts in the UI for instance, or using baseline to examine changes brought about by an upgrade.

Finally I’d put a calendar entry just far enough into the future to have a look when “at least one of everything” has happened; each scheduled range, etc.

Good stuff Mark thanks.