The main test case will be based on the test case of REQ-182 which was delivered for FRankfurt release (described in https://docs.onap.org/projects/onap-integration/en/frankfurt/docs_vFW_CNF_CDS.html). REQ-341 modifies the way how vFW service is instantiated however the overall result of instantiation should be exactly the same from the perspective of the final result. The overall testing scenario can be split into the following steps

1. [Script] Manual (scripts outside ONAP) Creation of dedicated K8s cluster for vFW service instantiation - The cluster is KUD instance with ovn4nfv, multus and virtlet plugins required fir vFW helm charts
2. [AAI] Creation of configuration in AAI with Postman:
   1. Create Customer
   2. Create Owning-entity
   3. Create Platform
   4. Create Project
   5. Create Line Of Business
3. [OOM] We DO NOT modify SO BPMN endpoint for VNF adapter (was required in REQ-182 - now it should not be needed)
4. [AAI] Registration of cloud region in AAI & k8s Plugin: 
   1. Create Complex
   2. Create Cloud Region
   3. Create Complex-Cloud Region Relationship
   4. Create Service
   5. Create Service Subscription
   6. Create Cloud Tenant
   7. Create Availability Zone
5. [K8s Plugin] Upload Connectivity Info with kube-config generated in 1.
6. [SO] We do not modify cloud-sites table in catalogdb (Required in REQ-182, here should not be needed). SO should read k8s cluster tenant Info from AAI
7. [SDC] Create VSP in SDC including helm package (tar.gz) + CBA (zip). The helm package should be visible as HELM type. VSP cannot have any HEAT templates associated
8. [SDC] Create VF (Macro) by the import of VSP with HELM artifact type inside.
9. [SDC] Edit VF properties by the inclusion of: sdnc_artifact_name, sdnc_model_name, and sdnc_model_version parameters.
10. [SDC] Create Service including VF with HELM artifact type
11. [SDC] Distribute the service - Helm artifact should be uploaded into k8s plugin as new RB Definition, the service should be also visible in SO catalogdb
12. [SO] Send first Service instantiation request with Default RB Profile. The
    1. SO request must be completed successfully.
    2. SO should return successful result status only when all k8s resources are instantiated properly
    3. Verification of k8s resources with kubectl shows resources are instantiated properly
13. [SO] Send a second Service instantiation request with RB Profile that will create extra ssh service for vPGN. 
    1. SO request must be completed successfully.
    2. SO should return successful result status only when all k8s resources are instantiated properly
    3. Verification of k8s resources with kubectl shows resources are instantiated properly
14. [SO] Send a third Service instantiation request with RB Profile that will corrupt the successful instantiation of vPGN.
    1. The SO request must fail. 
    2. SO should return failed result because not all the k8s resources are instantiated properly
    3. SO should rollback instantiated resources and on k8s cluster there should be no leftovers