[Cloud Security][Test Design] AWS Organization support

[JordanSh]

Test Requirements were add to the RTC

• Add test cases designs
• Open for review

cc: @kfirpeled

[elasticmachine]

Pinging @elastic/kibana-cloud-security-posture (Team:Cloud Security)

[JordanSh]

@opauloh Since you worked closest with those forms i would like to get your review on the test plan

[opauloh]

@opauloh Since you worked closest with those forms i would like to get your review on the test plan

It's looking good @JordanSh, thinking about some steps when we do QA tests, I just have a couple of questions:

1. Should we add one FTR test for each available Manual option?

2. An FTR test that fills all manual fields and then makes sure it's saving only the manual credential selected and nothing else.

3. The same for the edit page, when switching from an old manual option to a new one it should only save the new one.

4. Should we add an FTR test for testing the auto-increment feature? cspm-1, cspm-2

5. Is it only for the CSPM organization feature, or should we start adding tests for the other integration policies as well?

6. Do you know if FTR tests support testing the integration upgrade? there's a feature that if we install CloudFormation with a template for a version (ex. 1.5.0) and then Kibana auto upgrades the integration (to 1.5.2 for ex.) when adding the Agent in the Agent Flyout it should show CloudFormation template of the integration version one (1.5.2) instead of the stored in the Agent Policy one (1.5.0).

[JordanSh]

1. Should we add one FTR test for each available Manual option?

In general, yes probably, because each switch here calls a different function. but this specific task was opened for the aws org changes in the form, so I'm not sure if we want to test every switch for this one. given that some of the elements are shared between forms as well.

2. An FTR test that fills all manual fields and then makes sure it's saving only the manual credential selected and nothing else.
3. The same for the edit page, when switching from an old manual option to a new one it should only save the new one.
4. Should we add an FTR test for testing the auto-increment feature? cspm-1, cspm-2

Those are all very good tests that we should definitely add. This task is focusing on the AWS Org feature so it will not be in this context, those tests are relevant to all forms.

5. Is it only for the CSPM organization feature, or should we start adding tests for the other integration policies as well?

In general the idea was to plan specific tests to the feature we recently delivered. but we didn't do that to most of our forms so we do need to feel up the blanks. I'll add the tests you suggested for starter but you can feel free to add more.

6. Do you know if FTR tests support testing the integration upgrade? there's a feature that if we install CloudFormation with a template for a version (ex. 1.5.0) and then Kibana auto upgrades the integration (to 1.5.2 for ex.) when adding the Agent in the Agent Flyout it should show CloudFormation template of the integration version one (1.5.2) instead of the stored in the Agent Policy one (1.5.0).

No idea sorry

[kfirpeled]

Do you know if FTR tests support testing the integration upgrade? there's a feature that if we install CloudFormation with a template for a version (ex. 1.5.0) and then Kibana auto upgrades the integration (to 1.5.2 for ex.) when adding the Agent in the Agent Flyout it should show CloudFormation template of the integration version one (1.5.2) instead of the stored in the Agent Policy one (1.5.0).

yes @opauloh, I can suggest multiple kind of checks here.
You can try and create another integration version with a different value - but that would be a very flaky test to set up because of the auto-upgrade process.

Another suggestion, is to change the variable on the package-policy. That way you assert the value that is used is deffinitly the one from the epr manifest and not from the package-policy.

makes sense?

[opauloh]

Another suggestion, is to change the variable on the package-policy. That way you assert the value that is used is deffinitly the one from the epr manifest and not from the package-policy.

makes sense?

Definetly, that's a good way of handling that

[JordanSh]

added version update to the tests list

[JordanSh]

since the aws tests designs were approved, im moving to done. the general form behaviours and integrations upgrades were also added to the requirement list but will probably need a deeper planning in order to create test cases