From 4aa5296f99edddff130e34bf48816e874e60a9e2 Mon Sep 17 00:00:00 2001 From: Maximilian Wesener Date: Tue, 19 Sep 2023 15:53:40 +0200 Subject: [PATCH] Revert "chore: TRACEFOSS-XXX remove feature files." This reverts commit 9a31a7d30d6ee73e5489a64f4c37b045921d6800. --- .../features/10_TRACEFOSS-1125.feature | 67 +++++ .../features/1_TRACEFOSS-1393.feature | 277 ++++++++++++++++++ .../features/2_TRACEFOSS-600.feature | 265 +++++++++++++++++ .../features/3_TRACEFOSS-936.feature | 145 +++++++++ .../features/4_TRACEFOSS-938.feature | 156 ++++++++++ .../features/5_TRACEFOSS-1625.feature | 46 +++ .../features/6_TRACEFOSS-382.feature | 59 ++++ .../features/7_TRACEFOSS-1090.feature | 43 +++ .../features/8_TRACEFOSS-608.feature | 55 ++++ .../features/9_TRACEFOSS-2354.feature | 81 +++++ 10 files changed, 1194 insertions(+) create mode 100644 tx-cucumber-tests/src/test/resources/features/10_TRACEFOSS-1125.feature create mode 100644 tx-cucumber-tests/src/test/resources/features/1_TRACEFOSS-1393.feature create mode 100644 tx-cucumber-tests/src/test/resources/features/2_TRACEFOSS-600.feature create mode 100644 tx-cucumber-tests/src/test/resources/features/3_TRACEFOSS-936.feature create mode 100644 tx-cucumber-tests/src/test/resources/features/4_TRACEFOSS-938.feature create mode 100644 tx-cucumber-tests/src/test/resources/features/5_TRACEFOSS-1625.feature create mode 100644 tx-cucumber-tests/src/test/resources/features/6_TRACEFOSS-382.feature create mode 100644 tx-cucumber-tests/src/test/resources/features/7_TRACEFOSS-1090.feature create mode 100644 tx-cucumber-tests/src/test/resources/features/8_TRACEFOSS-608.feature create mode 100644 tx-cucumber-tests/src/test/resources/features/9_TRACEFOSS-2354.feature diff --git a/tx-cucumber-tests/src/test/resources/features/10_TRACEFOSS-1125.feature b/tx-cucumber-tests/src/test/resources/features/10_TRACEFOSS-1125.feature new file mode 100644 index 0000000000..6d3fb39572 --- /dev/null +++ b/tx-cucumber-tests/src/test/resources/features/10_TRACEFOSS-1125.feature @@ -0,0 +1,67 @@ +@TRACEFOSS-1125 +Feature: ⭐[BE] User select severity for Quality Investigation + #*As a* User, + #*I want* to be able to assign a severity status for the part(s) of a notification + #*so that* I am able to inform the supplier (within the notification) about the criticality of my request for investigation. + #h3. Outcome + # * User can select the severity based on the list in the documentation + # ** MINOR + # ** MAJOR + # ** CRITICAL + # ** LIFE-THREATENING + # * Severity is sent to the receiver of the notification in the corresponding field + # * The severity of the parts is changed on sender and receiver side based on the information in the notification. + # + #h2. Hints + # * Today severity is hard coded "minor" in Notification + # * [Concept|https://confluence.catena-x.net/pages/viewpage.action?pageId=69429778] + + #Check if *severity* is processed correctly for created quality investigations which contains following checks: + # * correct creation + # * correct reception on receiver side + # + #h2. Sprint Planning 2 + # * Make sure to not have duplicate lines of gherkin language which link to the same technical methods + # * Write test + # * Validate github action against e2e environment + # * Give Feedback to Alex and make suggestions of gherkin and technical steps + # * Request two new technical users (see reference ticket here: https://jira.catena-x.net/browse/CPLP-2808)  with client id / secret for + # ** ADMIN role + # ** USER role + # * Request system team ticket (see reference ticket here: [https://github.com/eclipse-tractusx/sig-infra/issues/66) |https://github.com/eclipse-tractusx/sig-infra/issues/66] + # ** For the mapping of the secrets in github + # * Add new secrets to the code + # + #  + @TRACEFOSS-1220 @TRACEFOSS-1920 @TEST-1217 @TRACEFOSS-1138 @TRACEFOSS-1139 @TRACEFOSS-1101 @TRACEFOSS-1673 @TEST-904 @INTEGRATION_TEST + Scenario Outline: [BE] Check correct processing of severity in quality investigation + When I am logged into TRACE_X_A application + And I create quality investigation + | "severity" | | + | "description" | "Testing severity TRACEFOSS-1220" | + Then I check, if quality investigation has proper values + | "severity" | | + | "description" | "Testing severity TRACEFOSS-1220" | + | "status" | "CREATED" | + When I approve quality investigation + Then I check, if quality investigation has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality investigation has been received + Then I check, if quality investigation has proper values + | "severity" | | + | "description" | "Testing severity TRACEFOSS-1220" | + | "status" | "RECEIVED" | + When I acknowledge quality investigation + Then I check, if quality investigation has proper values + | "status" | "ACKNOWLEDGED" | + When I am logged into TRACE_X_A application + Then I check, if quality investigation has proper values + | "status" | "ACKNOWLEDGED" | + + Examples: + | severity | + | "MINOR" | + | "MAJOR" | + | "CRITICAL" | + | "LIFE-THREATENING" | diff --git a/tx-cucumber-tests/src/test/resources/features/1_TRACEFOSS-1393.feature b/tx-cucumber-tests/src/test/resources/features/1_TRACEFOSS-1393.feature new file mode 100644 index 0000000000..9bedc5be6d --- /dev/null +++ b/tx-cucumber-tests/src/test/resources/features/1_TRACEFOSS-1393.feature @@ -0,0 +1,277 @@ +@TRACEFOSS-1393 +Feature: ⭐ [BE][QUALITY_ALERTS] Create (POST) quality alerts (Rest API) + #h2. User Story + # + #*As a* user + #*I want to* be able to see all quality alerts / notifications based on their status and type with the date created in a separate Quality Alerts inbox + #*so that* I can have an overview and perform actions like view details on the notifications. + # + #h2. Outcome + # + #- (-) New table is added which shows "Quality Alerts" + + #Check if *CANCELLATION* of quality alerts is processed correctly which contains following checks: + #* correct CANCELLATION on receiver side + #* correct reception of status update on sender side + #* correct reason on receiver and sender side + @TRACEFOSS-1864 @TRACEFOSS-1920 @TEST-1217 @TEST-904 @TRACEFOSS-1673 @TRACEFOSS-1101 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of CANCELLATION of quality alerts + When I am logged into TRACE_X_A application + And I create quality alert + | "severity" | "MAJOR" | + | "description" | "Testing ACCEPTANCE TRACEFOSS-1864" | + Then I check, if quality alert has proper values + | "description" | "Testing ACCEPTANCE TRACEFOSS-1864" | + | "status" | "CREATED" | + When I cancel quality alert + Then I check, if quality alert has proper values + | "status" | "CANCELED" | + + When I am logged into TRACE_X_B application + Then I check, if quality alert has not been received + + #Check if *CLOSURE* of quality alerts is processed correctly which contains following checks: + #* correct CLOSURE on receiver side + #* correct reception of status update on sender side + #* correct reason on receiver and sender side + @TRACEFOSS-1863 @TRACEFOSS-1920 @TEST-1217 @TEST-904 @TRACEFOSS-1101 @TRACEFOSS-1673 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of CLOSURE of quality alerts + When I am logged into TRACE_X_A application + And I create quality alert + | "severity" | "MAJOR" | + | "description" | "Testing ACCEPTANCE TRACEFOSS-1863" | + Then I check, if quality alert has proper values + | "description" | "Testing ACCEPTANCE TRACEFOSS-1863" | + | "status" | "CREATED" | + When I approve quality alert + Then I check, if quality alert has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality alert has been received + And I check, if quality alert has proper values + | "status" | "RECEIVED" | + When I acknowledge quality alert + Then I check, if quality alert has proper values + | "status" | "ACKNOWLEDGED" | + + When I am logged into TRACE_X_A application + Then I check, if quality alert has proper values + | "status" | "ACKNOWLEDGED" | + When I close quality alert + Then I check, if quality alert has proper values + | "status" | "CLOSED" | + + When I am logged into TRACE_X_B application + Then I check, if quality alert has proper values + | "status" | "CLOSED" | + + #Check if *several parts* are processed correctly in *one* created quality alert which contains following checks: + #* correct sending of several parts in *one* alert + #* correct reception of several parts in *one* alert on receiver side + #* correct update of *one* alert with several parts + @TRACEFOSS-1670 @TRACEFOSS-1920 @TRACEFOSS-1101 @TRACEFOSS-1673 @TEST-904 @TEST-1217 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of several parts in quality alerts + When I am logged into TRACE_X_A application + And I create quality alert with two parts + | "severity" | "MINOR" | + | "description" | "Testing severity TRACEFOSS-1670" | + Then I check, if quality alert has proper values + | "description" | "Testing severity TRACEFOSS-1670" | + | "status" | "CREATED" | + | "assetIdCount" | "2" | + When I approve quality alert + Then I check, if quality alert has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality alert has been received + Then I check, if quality alert has proper values + | "description" | "Testing severity TRACEFOSS-1670" | + | "status" | "RECEIVED" | + | "assetIdCount" | "2" | + When I acknowledge quality alert + Then I check, if quality alert has proper values + | "status" | "ACKNOWLEDGED" | + When I am logged into TRACE_X_A application + Then I check, if quality alert has proper values + | "status" | "ACKNOWLEDGED" | + | "assetIdCount" | "2" | + + #Check if *bpn names* of *sender and receiver* are processed correctly for created quality alerts which contains following checks: + #* correct creation on sender side + #* correct reception on receiver side + @TRACEFOSS-1547 @TRACEFOSS-1101 @TRACEFOSS-1920 @TRACEFOSS-1673 @TEST-904 @TEST-1217 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of bpn names in quality alerts + When I am logged into TRACE_X_A application + And I create quality alert + | "description" | "Testing BPNs TRACEFOSS-1547" | + | "severity" | "MINOR" | + Then I check, if quality alert has proper values + | "description" | "Testing BPNs TRACEFOSS-1547" | + | "createdBy" | "BPNL00000003CML1" | + | "sendTo" | "BPNL00000003CNKC" | + | "status" | "CREATED" | + When I approve quality alert + Then I check, if quality alert has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality alert has been received + Then I check, if quality alert has proper values + | "description" | "Testing BPNs TRACEFOSS-1547" | + | "createdBy" | "BPNL00000003CML1" | + | "sendTo" | "BPNL00000003CNKC" | + | "status" | "RECEIVED" | + + #Check if *targetDate = null* is processed correctly for created quality alerts which contains following checks: + #* correct sending of _targetDate_ = *null* + #* correct reception on receiver side + @TRACEFOSS-1546 @TRACEFOSS-1101 @TRACEFOSS-1920 @TRACEFOSS-1673 @TEST-904 @TEST-1217 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of targetDate = null in quality alerts + When I am logged into TRACE_X_A application + And I create quality alert + | "severity" | "MINOR" | + | "description" | "Testing without targetDate TRACEFOSS-1546" | + Then I check, if quality alert has proper values + | "description" | "Testing without targetDate TRACEFOSS-1546" | + | "targetDate" | "" | + | "status" | "CREATED" | + When I approve quality alert + Then I check, if quality alert has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality alert has been received + Then I check, if quality alert has proper values + | "description" | "Testing without targetDate TRACEFOSS-1546" | + | "targetDate" | "" | + | "status" | "RECEIVED" | + + #Check if *DECLINATION* of quality alerts is processed correctly which contains following checks: + #* correct DECLINATION status on receiver side + #* correct reception of status update on sender side + #* correct reason on receiver and sender side + @TRACEFOSS-1545 @TRACEFOSS-1101 @TRACEFOSS-1920 @TRACEFOSS-1673 @TEST-904 @TEST-1217 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of DECLINATION of quality alerts + When I am logged into TRACE_X_A application + And I create quality alert + | "severity" | "MAJOR" | + | "description" | "Testing DECLINATION TRACEFOSS-1545" | + Then I check, if quality alert has proper values + | "severity" | "MAJOR" | + | "description" | "Testing DECLINATION TRACEFOSS-1545" | + | "status" | "CREATED" | + When I approve quality alert + Then I check, if quality alert has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality alert has been received + Then I check, if quality alert has proper values + | "severity" | "MAJOR" | + | "description" | "Testing DECLINATION TRACEFOSS-1545" | + | "status" | "RECEIVED" | + When I acknowledge quality alert + Then I check, if quality alert has proper values + | "status" | "ACKNOWLEDGED" | + When I decline quality alert + | "reason" | "declined in TRACEFOSS-1545" | + Then I check, if quality alert has proper values + | "status" | "DECLINED" | + When I am logged into TRACE_X_A application + Then I check, if quality alert has proper values + | "status" | "DECLINED" | + And I check, if quality alert has proper values + | "description" | "declined in TRACEFOSS-1545" | + + #Check if *ACCEPTANCE* of quality alerts is processed correctly which contains following checks: + #* correct ACCEPTANCE on receiver side + #* correct reception of status update on sender side + #* correct reason on receiver and sender side + @TRACEFOSS-1544 @TRACEFOSS-1101 @TRACEFOSS-1920 @TEST-904 @TRACEFOSS-1673 @TEST-1217 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of ACCEPTANCE of quality alerts + When I am logged into TRACE_X_A application + And I create quality alert + | "severity" | "MAJOR" | + | "description" | "Testing ACCEPTANCE TRACEFOSS-1544" | + Then I check, if quality alert has proper values + | "severity" | "MAJOR" | + | "description" | "Testing ACCEPTANCE TRACEFOSS-1544" | + | "status" | "CREATED" | + When I approve quality alert + Then I check, if quality alert has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality alert has been received + Then I check, if quality alert has proper values + | "severity" | "MAJOR" | + | "description" | "Testing ACCEPTANCE TRACEFOSS-1544" | + | "status" | "RECEIVED" | + When I acknowledge quality alert + Then I check, if quality alert has proper values + | "status" | "ACKNOWLEDGED" | + When I accept quality alert + | "reason" | "accepted in TRACEFOSS-1544" | + Then I check, if quality alert has proper values + | "status" | "ACCEPTED" | + When I am logged into TRACE_X_A application + Then I check, if quality alert has proper values + | "status" | "ACCEPTED" | + And I check, if quality alert has proper values + | "acceptReason" | "accepted in TRACEFOSS-1544" | + + #Check if *targetDate* is processed correctly for created quality alerts which contains following checks: + #* correct sending of _targetDate_ + #* correct reception on receiver side + @TRACEFOSS-1543 @TRACEFOSS-1920 @TEST-904 @TRACEFOSS-1673 @TRACEFOSS-1101 @TEST-1217 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of targetDate in quality alerts + When I am logged into TRACE_X_A application + And I create quality alert + | "severity" | "MINOR" | + | "description" | "Testing targetDate TRACEFOSS-1543" | + | "targetDate" | "2055-05-30T20:43:06.333827Z" | + Then I check, if quality alert has proper values + | "description" | "Testing targetDate TRACEFOSS-1543" | + | "targetDate" | "2055-05-30T20:43:06.333827Z" | + | "status" | "CREATED" | + When I approve quality alert + Then I check, if quality alert has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality alert has been received + Then I check, if quality alert has proper values + | "description" | "Testing targetDate TRACEFOSS-1543" | + | "targetDate" | "2055-05-30T20:43:06.333827Z" | + | "status" | "RECEIVED" | + + #Check if *severity* is processed correctly for created quality alerts which contains following checks: + #* correct creation + #* correct reception on receiver side + @TRACEFOSS-1539 @TRACEFOSS-1920 @TRACEFOSS-1101 @TRACEFOSS-1673 @TEST-904 @TEST-1217 @INTEGRATION_TEST + Scenario Outline: [BE] Check correct processing of severity in quality alerts + When I am logged into TRACE_X_A application + And I create quality alert + | "severity" | | + | "description" | "Testing severity TRACEFOSS-1539" | + Then I check, if quality alert has proper values + | "severity" | | + | "description" | "Testing severity TRACEFOSS-1539" | + | "status" | "CREATED" | + When I approve quality alert + Then I check, if quality alert has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality alert has been received + Then I check, if quality alert has proper values + | "severity" | | + | "description" | "Testing severity TRACEFOSS-1539" | + | "status" | "RECEIVED" | + When I acknowledge quality alert + Then I check, if quality alert has proper values + | "status" | "ACKNOWLEDGED" | + When I am logged into TRACE_X_A application + Then I check, if quality alert has proper values + | "status" | "ACKNOWLEDGED" | + + Examples: + | severity | + | "MINOR" | + | "MAJOR" | + | "CRITICAL" | + | "LIFE-THREATENING" | diff --git a/tx-cucumber-tests/src/test/resources/features/2_TRACEFOSS-600.feature b/tx-cucumber-tests/src/test/resources/features/2_TRACEFOSS-600.feature new file mode 100644 index 0000000000..86fdbcc9dd --- /dev/null +++ b/tx-cucumber-tests/src/test/resources/features/2_TRACEFOSS-600.feature @@ -0,0 +1,265 @@ +@TRACEFOSS-600 +Feature: ⭐ [BE][QUALITY_ALERTS] Enable Quality Alerts + #h2. User Story + # + #*As a* user + #*I want to* be able to use all quality alerts + #*so that* can report quality problems in upstream visibility. + #h2. Outcome + # * (x) Quality Alerts are implementd (HAPPY PATH) + # + #h2. Consolidation for pbis + # * TRACEFOSS-1388 + # + #h2. Sprint Planning 2 + # * Part 1 -> Pull Request 1 + # ** Make sure to not duplicate code instead of base class or reuse existing logic (e.g. state transitions) + # ** Implement a service + # ** Publisher Service + # ** Receiver Service + # ** Implement a repository + # * Part 2 -> Pull Request 2 ( Do not start with it before PR 1 is merged) + # ** Make sure all condiitions which exclude quality alerts are removed + # ** Make sure that the existing api which creates a contract will be able to create it for quality alerts + # *** /api/edc/notification/contract + # ** Make sure that the logic of receiver side does filter for quality alert assets (currently only for quality investigations) + # ** Send alert from a to b + # ** Send alert from b to a + # * Part 3 -> Pull Request 3 -> Enable frontend -> [~martin.maul@doubleslash.de]  + # ** [https://github.com/catenax-ng/tx-traceability-foss/pull/264/files#diff-de4cfce80ee64138f3cdf6ab0af7b29aed8687212738a0a2d18567e29e7b9472R31] + # **   + + #Check if *CANCELLATION* of quality alerts is processed correctly which contains following checks: + #* correct CANCELLATION on receiver side + #* correct reception of status update on sender side + #* correct reason on receiver and sender side + @TRACEFOSS-1864 @TRACEFOSS-1920 @TEST-1217 @TEST-904 @TRACEFOSS-1673 @TRACEFOSS-1101 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of CANCELLATION of quality alerts + When I am logged into TRACE_X_A application + And I create quality alert + | "severity" | "MAJOR" | + | "description" | "Testing ACCEPTANCE TRACEFOSS-1864" | + Then I check, if quality alert has proper values + | "description" | "Testing ACCEPTANCE TRACEFOSS-1864" | + | "status" | "CREATED" | + When I cancel quality alert + Then I check, if quality alert has proper values + | "status" | "CANCELED" | + + When I am logged into TRACE_X_B application + Then I check, if quality alert has not been received + + #Check if *CLOSURE* of quality alerts is processed correctly which contains following checks: + #* correct CLOSURE on receiver side + #* correct reception of status update on sender side + #* correct reason on receiver and sender side + @TRACEFOSS-1863 @TRACEFOSS-1920 @TEST-1217 @TEST-904 @TRACEFOSS-1101 @TRACEFOSS-1673 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of CLOSURE of quality alerts + When I am logged into TRACE_X_A application + And I create quality alert + | "severity" | "MAJOR" | + | "description" | "Testing ACCEPTANCE TRACEFOSS-1863" | + Then I check, if quality alert has proper values + | "description" | "Testing ACCEPTANCE TRACEFOSS-1863" | + | "status" | "CREATED" | + When I approve quality alert + Then I check, if quality alert has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality alert has been received + And I check, if quality alert has proper values + | "status" | "RECEIVED" | + When I acknowledge quality alert + Then I check, if quality alert has proper values + | "status" | "ACKNOWLEDGED" | + + When I am logged into TRACE_X_A application + Then I check, if quality alert has proper values + | "status" | "ACKNOWLEDGED" | + When I close quality alert + Then I check, if quality alert has proper values + | "status" | "CLOSED" | + + When I am logged into TRACE_X_B application + Then I check, if quality alert has proper values + | "status" | "CLOSED" | + + #Check if *bpn names* of *sender and receiver* are processed correctly for created quality alerts which contains following checks: + #* correct creation on sender side + #* correct reception on receiver side + @TRACEFOSS-1547 @TRACEFOSS-1101 @TRACEFOSS-1920 @TRACEFOSS-1673 @TEST-904 @TEST-1217 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of bpn names in quality alerts + When I am logged into TRACE_X_A application + And I create quality alert + | "description" | "Testing BPNs TRACEFOSS-1547" | + | "severity" | "MINOR" | + Then I check, if quality alert has proper values + | "description" | "Testing BPNs TRACEFOSS-1547" | + | "createdBy" | "BPNL00000003CML1" | + | "sendTo" | "BPNL00000003CNKC" | + | "status" | "CREATED" | + When I approve quality alert + Then I check, if quality alert has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality alert has been received + Then I check, if quality alert has proper values + | "description" | "Testing BPNs TRACEFOSS-1547" | + | "createdBy" | "BPNL00000003CML1" | + | "sendTo" | "BPNL00000003CNKC" | + | "status" | "RECEIVED" | + + #Check if *targetDate = null* is processed correctly for created quality alerts which contains following checks: + #* correct sending of _targetDate_ = *null* + #* correct reception on receiver side + @TRACEFOSS-1546 @TRACEFOSS-1101 @TRACEFOSS-1920 @TRACEFOSS-1673 @TEST-904 @TEST-1217 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of targetDate = null in quality alerts + When I am logged into TRACE_X_A application + And I create quality alert + | "severity" | "MINOR" | + | "description" | "Testing without targetDate TRACEFOSS-1546" | + Then I check, if quality alert has proper values + | "description" | "Testing without targetDate TRACEFOSS-1546" | + | "targetDate" | "" | + | "status" | "CREATED" | + When I approve quality alert + Then I check, if quality alert has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality alert has been received + Then I check, if quality alert has proper values + | "description" | "Testing without targetDate TRACEFOSS-1546" | + | "targetDate" | "" | + | "status" | "RECEIVED" | + + #Check if *DECLINATION* of quality alerts is processed correctly which contains following checks: + #* correct DECLINATION status on receiver side + #* correct reception of status update on sender side + #* correct reason on receiver and sender side + @TRACEFOSS-1545 @TRACEFOSS-1101 @TRACEFOSS-1920 @TRACEFOSS-1673 @TEST-904 @TEST-1217 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of DECLINATION of quality alerts + When I am logged into TRACE_X_A application + And I create quality alert + | "severity" | "MAJOR" | + | "description" | "Testing DECLINATION TRACEFOSS-1545" | + Then I check, if quality alert has proper values + | "severity" | "MAJOR" | + | "description" | "Testing DECLINATION TRACEFOSS-1545" | + | "status" | "CREATED" | + When I approve quality alert + Then I check, if quality alert has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality alert has been received + Then I check, if quality alert has proper values + | "severity" | "MAJOR" | + | "description" | "Testing DECLINATION TRACEFOSS-1545" | + | "status" | "RECEIVED" | + When I acknowledge quality alert + Then I check, if quality alert has proper values + | "status" | "ACKNOWLEDGED" | + When I decline quality alert + | "reason" | "declined in TRACEFOSS-1545" | + Then I check, if quality alert has proper values + | "status" | "DECLINED" | + When I am logged into TRACE_X_A application + Then I check, if quality alert has proper values + | "status" | "DECLINED" | + And I check, if quality alert has proper values + | "description" | "declined in TRACEFOSS-1545" | + + #Check if *ACCEPTANCE* of quality alerts is processed correctly which contains following checks: + #* correct ACCEPTANCE on receiver side + #* correct reception of status update on sender side + #* correct reason on receiver and sender side + @TRACEFOSS-1544 @TRACEFOSS-1101 @TRACEFOSS-1920 @TEST-904 @TRACEFOSS-1673 @TEST-1217 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of ACCEPTANCE of quality alerts + When I am logged into TRACE_X_A application + And I create quality alert + | "severity" | "MAJOR" | + | "description" | "Testing ACCEPTANCE TRACEFOSS-1544" | + Then I check, if quality alert has proper values + | "severity" | "MAJOR" | + | "description" | "Testing ACCEPTANCE TRACEFOSS-1544" | + | "status" | "CREATED" | + When I approve quality alert + Then I check, if quality alert has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality alert has been received + Then I check, if quality alert has proper values + | "severity" | "MAJOR" | + | "description" | "Testing ACCEPTANCE TRACEFOSS-1544" | + | "status" | "RECEIVED" | + When I acknowledge quality alert + Then I check, if quality alert has proper values + | "status" | "ACKNOWLEDGED" | + When I accept quality alert + | "reason" | "accepted in TRACEFOSS-1544" | + Then I check, if quality alert has proper values + | "status" | "ACCEPTED" | + When I am logged into TRACE_X_A application + Then I check, if quality alert has proper values + | "status" | "ACCEPTED" | + And I check, if quality alert has proper values + | "acceptReason" | "accepted in TRACEFOSS-1544" | + + #Check if *targetDate* is processed correctly for created quality alerts which contains following checks: + #* correct sending of _targetDate_ + #* correct reception on receiver side + @TRACEFOSS-1543 @TRACEFOSS-1920 @TEST-904 @TRACEFOSS-1673 @TRACEFOSS-1101 @TEST-1217 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of targetDate in quality alerts + When I am logged into TRACE_X_A application + And I create quality alert + | "severity" | "MINOR" | + | "description" | "Testing targetDate TRACEFOSS-1543" | + | "targetDate" | "2055-05-30T20:43:06.333827Z" | + Then I check, if quality alert has proper values + | "description" | "Testing targetDate TRACEFOSS-1543" | + | "targetDate" | "2055-05-30T20:43:06.333827Z" | + | "status" | "CREATED" | + When I approve quality alert + Then I check, if quality alert has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality alert has been received + Then I check, if quality alert has proper values + | "description" | "Testing targetDate TRACEFOSS-1543" | + | "targetDate" | "2055-05-30T20:43:06.333827Z" | + | "status" | "RECEIVED" | + + #Check if *severity* is processed correctly for created quality alerts which contains following checks: + #* correct creation + #* correct reception on receiver side + @TRACEFOSS-1539 @TRACEFOSS-1920 @TRACEFOSS-1101 @TRACEFOSS-1673 @TEST-904 @TEST-1217 @INTEGRATION_TEST + Scenario Outline: [BE] Check correct processing of severity in quality alerts + When I am logged into TRACE_X_A application + And I create quality alert + | "severity" | | + | "description" | "Testing severity TRACEFOSS-1539" | + Then I check, if quality alert has proper values + | "severity" | | + | "description" | "Testing severity TRACEFOSS-1539" | + | "status" | "CREATED" | + When I approve quality alert + Then I check, if quality alert has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality alert has been received + Then I check, if quality alert has proper values + | "severity" | | + | "description" | "Testing severity TRACEFOSS-1539" | + | "status" | "RECEIVED" | + When I acknowledge quality alert + Then I check, if quality alert has proper values + | "status" | "ACKNOWLEDGED" | + When I am logged into TRACE_X_A application + Then I check, if quality alert has proper values + | "status" | "ACKNOWLEDGED" | + + Examples: + | severity | + | "MINOR" | + | "MAJOR" | + | "CRITICAL" | + | "LIFE-THREATENING" | diff --git a/tx-cucumber-tests/src/test/resources/features/3_TRACEFOSS-936.feature b/tx-cucumber-tests/src/test/resources/features/3_TRACEFOSS-936.feature new file mode 100644 index 0000000000..58e66bb9a0 --- /dev/null +++ b/tx-cucumber-tests/src/test/resources/features/3_TRACEFOSS-936.feature @@ -0,0 +1,145 @@ +@TRACEFOSS-936 +Feature: ⭐[BE] Include reason for receiver and sender investigations + #*As a* Dev + # + #*I want to* update contract of: + # + #/investigations/created (sender side of notifications) + #/investigations/received (receiver side of notifications) + # + #with following object: + #{code:java} + #{ + # "reason" : { + # "close" : $string, + # "accept": $string, | nullable + # "decline": $string | nullable + # } + #} {code} + #Where for accept and decline reason, it's either one or another. Reasons are passed from receiver to sender and from sender to receiver via EDC and stored in the database. + # + #*so that* the information provided with the update is also stored and provided to sender and receiver sides. + + #Check if *CANCELLATION* of quality investigations is processed correctly which contains following checks: + #* correct CANCELLATION on receiver side + #* correct reception of status update on sender side + #* correct reason on receiver and sender side + @TRACEFOSS-1862 @TRACEFOSS-1920 @TEST-1217 @TEST-904 @TRACEFOSS-1101 @TRACEFOSS-1673 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of CANCELLATION of quality investigation + When I am logged into TRACE_X_A application + And I create quality investigation + | "severity" | "MAJOR" | + | "description" | "Testing ACCEPTANCE TRACEFOSS-1862" | + Then I check, if quality investigation has proper values + | "description" | "Testing ACCEPTANCE TRACEFOSS-1862" | + | "status" | "CREATED" | + When I cancel quality investigation + Then I check, if quality investigation has proper values + | "status" | "CANCELED" | + When I am logged into TRACE_X_B application + Then I check, if quality investigation has not been received + + #Check if *CLOSURE* of quality investigations is processed correctly which contains following checks: + #* correct CLOSE on receiver side + #* correct reception of status update on sender side + #* correct reason on receiver and sender side + @TRACEFOSS-1861 @TRACEFOSS-1920 @TEST-1217 @TRACEFOSS-1101 @TEST-904 @TRACEFOSS-1673 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of CLOSURE of quality investigation + When I am logged into TRACE_X_A application + And I create quality investigation + | "severity" | "MAJOR" | + | "description" | "Testing ACCEPTANCE TRACEFOSS-1861" | + Then I check, if quality investigation has proper values + | "description" | "Testing ACCEPTANCE TRACEFOSS-1861" | + | "status" | "CREATED" | + When I approve quality investigation + Then I check, if quality investigation has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality investigation has been received + And I check, if quality investigation has proper values + | "status" | "RECEIVED" | + When I acknowledge quality investigation + Then I check, if quality investigation has proper values + | "status" | "ACKNOWLEDGED" | + + When I am logged into TRACE_X_A application + Then I check, if quality investigation has proper values + | "status" | "ACKNOWLEDGED" | + When I close quality investigation + Then I check, if quality investigation has proper values + | "status" | "CLOSED" | + + When I am logged into TRACE_X_B application + Then I check, if quality investigation has proper values + | "status" | "CLOSED" | + + #Check if *DECLINATION* of quality investigations is processed correctly which contains following checks: + #* correct DECLINATION status on receiver side + #* correct reception of status update on sender side + #* correct reason on receiver and sender side + @TRACEFOSS-1223 @TRACEFOSS-1920 @TRACEFOSS-1673 @TEST-1217 @TRACEFOSS-1139 @TEST-904 @TRACEFOSS-1138 @TRACEFOSS-1101 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of DECLINATION of quality investigation + When I am logged into TRACE_X_A application + And I create quality investigation + | "severity" | "MAJOR" | + | "description" | "Testing DECLINATION TRACEFOSS-1223" | + Then I check, if quality investigation has proper values + | "severity" | "MAJOR" | + | "description" | "Testing DECLINATION TRACEFOSS-1223" | + | "status" | "CREATED" | + When I approve quality investigation + Then I check, if quality investigation has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality investigation has been received + Then I check, if quality investigation has proper values + | "severity" | "MAJOR" | + | "description" | "Testing DECLINATION TRACEFOSS-1223" | + | "status" | "RECEIVED" | + When I acknowledge quality investigation + Then I check, if quality investigation has proper values + | "status" | "ACKNOWLEDGED" | + When I decline quality investigation + | "reason" | "declined in TRACEFOSS-1223" | + Then I check, if quality investigation has proper values + | "status" | "DECLINED" | + When I am logged into TRACE_X_A application + Then I check, if quality investigation has proper values + | "status" | "DECLINED" | + | "declineReason" | "declined in TRACEFOSS-1223" | + + #Check if *ACCEPTANCE* of quality investigations is processed correctly which contains following checks: + #* correct ACCEPTANCE on receiver side + #* correct reception of status update on sender side + #* correct reason on receiver and sender side + @TRACEFOSS-1222 @TRACEFOSS-1920 @TRACEFOSS-1673 @TEST-1217 @TRACEFOSS-1139 @TRACEFOSS-1138 @TRACEFOSS-1101 @TEST-904 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of ACCEPTANCE of quality investigation + When I am logged into TRACE_X_A application + And I create quality investigation + | "severity" | "MAJOR" | + | "description" | "Testing ACCEPTANCE TRACEFOSS-1222" | + Then I check, if quality investigation has proper values + | "severity" | "MAJOR" | + | "description" | "Testing ACCEPTANCE TRACEFOSS-1222" | + | "status" | "CREATED" | + When I approve quality investigation + Then I check, if quality investigation has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality investigation has been received + Then I check, if quality investigation has proper values + | "severity" | "MAJOR" | + | "description" | "Testing ACCEPTANCE TRACEFOSS-1222" | + | "status" | "RECEIVED" | + When I acknowledge quality investigation + Then I check, if quality investigation has proper values + | "status" | "ACKNOWLEDGED" | + When I accept quality investigation + | "reason" | "accepted in TRACEFOSS-1222" | + Then I check, if quality investigation has proper values + | "status" | "ACCEPTED" | + When I am logged into TRACE_X_A application + Then I check, if quality investigation has proper values + | "status" | "ACCEPTED" | + | "acceptReason" | "accepted in TRACEFOSS-1222" | diff --git a/tx-cucumber-tests/src/test/resources/features/4_TRACEFOSS-938.feature b/tx-cucumber-tests/src/test/resources/features/4_TRACEFOSS-938.feature new file mode 100644 index 0000000000..28a43a16fe --- /dev/null +++ b/tx-cucumber-tests/src/test/resources/features/4_TRACEFOSS-938.feature @@ -0,0 +1,156 @@ +@TRACEFOSS-938 +Feature: ⭐[TEST] Update Quality Investigation (over EDC) + #h2. User Story + # + #*As* Supervisor + #*I want* to be able to update a quality investigation that I received + #*so that* the corresponding partner knows in which status the notification is on my side. + #h2. Hints / Details / . Hints & NFR (Technical, Design & Content))* :  + # + #1. BPN B receives a notification + #2. BPN B updates notification + #3. BPN A receives notification update with corresponding status + # * The right notification asset needs to be looked up in the Catalog offer of the counter side + # * Lookup based on asset:props + # * Keep in mind that some fields are optional and might be empty + # ** Handle based on documentation / agreement like for send/receive + # ** E.g. "information" will be empty for Update from REC to ACK + # * Utilize EDC Update functionality in order to send investigation update over EDC from BNP B to BPN A. + # + #Docs: [Notification Update Docu|https://confluence.catena-x.net/pages/viewpage.action?pageId=69429778#id-(TRS)[Release3]%F0%9F%93%9CTraceabilityApp(ImplementationSpecification)-HttpPOSTendpointtoupdateanotification] + # + #!screenshot-1.png|thumbnail! + #h2. TODO: + # * (-) Fill out description + # * (-) Fill out Story Points + # * (-) Assign an Assignee + # * (-) define Acceptance Criteria + # * (-) [DoR |https://confluence.catena-x.net/pages/viewpage.action?pageId=917505]  + # + #h2. LOP + # * (/) [~thomas.braun3@zf.com] Update AC and describe error handling, retry and rollback. + # * (/) Add pbi for "Close notification on sender side". --> TRACEFOSS-961 + + #Check if *CANCELLATION* of quality investigations is processed correctly which contains following checks: + #* correct CANCELLATION on receiver side + #* correct reception of status update on sender side + #* correct reason on receiver and sender side + @TRACEFOSS-1862 @TRACEFOSS-1920 @TEST-1217 @TEST-904 @TRACEFOSS-1101 @TRACEFOSS-1673 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of CANCELLATION of quality investigation + When I am logged into TRACE_X_A application + And I create quality investigation + | "severity" | "MAJOR" | + | "description" | "Testing ACCEPTANCE TRACEFOSS-1862" | + Then I check, if quality investigation has proper values + | "description" | "Testing ACCEPTANCE TRACEFOSS-1862" | + | "status" | "CREATED" | + When I cancel quality investigation + Then I check, if quality investigation has proper values + | "status" | "CANCELED" | + When I am logged into TRACE_X_B application + Then I check, if quality investigation has not been received + + #Check if *CLOSURE* of quality investigations is processed correctly which contains following checks: + #* correct CLOSE on receiver side + #* correct reception of status update on sender side + #* correct reason on receiver and sender side + @TRACEFOSS-1861 @TRACEFOSS-1920 @TEST-1217 @TRACEFOSS-1101 @TEST-904 @TRACEFOSS-1673 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of CLOSURE of quality investigation + When I am logged into TRACE_X_A application + And I create quality investigation + | "severity" | "MAJOR" | + | "description" | "Testing ACCEPTANCE TRACEFOSS-1861" | + Then I check, if quality investigation has proper values + | "description" | "Testing ACCEPTANCE TRACEFOSS-1861" | + | "status" | "CREATED" | + When I approve quality investigation + Then I check, if quality investigation has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality investigation has been received + And I check, if quality investigation has proper values + | "status" | "RECEIVED" | + When I acknowledge quality investigation + Then I check, if quality investigation has proper values + | "status" | "ACKNOWLEDGED" | + + When I am logged into TRACE_X_A application + Then I check, if quality investigation has proper values + | "status" | "ACKNOWLEDGED" | + When I close quality investigation + Then I check, if quality investigation has proper values + | "status" | "CLOSED" | + + When I am logged into TRACE_X_B application + Then I check, if quality investigation has proper values + | "status" | "CLOSED" | + + #Check if *DECLINATION* of quality investigations is processed correctly which contains following checks: + #* correct DECLINATION status on receiver side + #* correct reception of status update on sender side + #* correct reason on receiver and sender side + @TRACEFOSS-1223 @TRACEFOSS-1920 @TRACEFOSS-1673 @TEST-1217 @TRACEFOSS-1139 @TEST-904 @TRACEFOSS-1138 @TRACEFOSS-1101 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of DECLINATION of quality investigation + When I am logged into TRACE_X_A application + And I create quality investigation + | "severity" | "MAJOR" | + | "description" | "Testing DECLINATION TRACEFOSS-1223" | + Then I check, if quality investigation has proper values + | "severity" | "MAJOR" | + | "description" | "Testing DECLINATION TRACEFOSS-1223" | + | "status" | "CREATED" | + When I approve quality investigation + Then I check, if quality investigation has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality investigation has been received + Then I check, if quality investigation has proper values + | "severity" | "MAJOR" | + | "description" | "Testing DECLINATION TRACEFOSS-1223" | + | "status" | "RECEIVED" | + When I acknowledge quality investigation + Then I check, if quality investigation has proper values + | "status" | "ACKNOWLEDGED" | + When I decline quality investigation + | "reason" | "declined in TRACEFOSS-1223" | + Then I check, if quality investigation has proper values + | "status" | "DECLINED" | + When I am logged into TRACE_X_A application + Then I check, if quality investigation has proper values + | "status" | "DECLINED" | + | "declineReason" | "declined in TRACEFOSS-1223" | + + #Check if *ACCEPTANCE* of quality investigations is processed correctly which contains following checks: + #* correct ACCEPTANCE on receiver side + #* correct reception of status update on sender side + #* correct reason on receiver and sender side + @TRACEFOSS-1222 @TRACEFOSS-1920 @TRACEFOSS-1673 @TEST-1217 @TRACEFOSS-1139 @TRACEFOSS-1138 @TRACEFOSS-1101 @TEST-904 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of ACCEPTANCE of quality investigation + When I am logged into TRACE_X_A application + And I create quality investigation + | "severity" | "MAJOR" | + | "description" | "Testing ACCEPTANCE TRACEFOSS-1222" | + Then I check, if quality investigation has proper values + | "severity" | "MAJOR" | + | "description" | "Testing ACCEPTANCE TRACEFOSS-1222" | + | "status" | "CREATED" | + When I approve quality investigation + Then I check, if quality investigation has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality investigation has been received + Then I check, if quality investigation has proper values + | "severity" | "MAJOR" | + | "description" | "Testing ACCEPTANCE TRACEFOSS-1222" | + | "status" | "RECEIVED" | + When I acknowledge quality investigation + Then I check, if quality investigation has proper values + | "status" | "ACKNOWLEDGED" | + When I accept quality investigation + | "reason" | "accepted in TRACEFOSS-1222" | + Then I check, if quality investigation has proper values + | "status" | "ACCEPTED" | + When I am logged into TRACE_X_A application + Then I check, if quality investigation has proper values + | "status" | "ACCEPTED" | + | "acceptReason" | "accepted in TRACEFOSS-1222" | diff --git a/tx-cucumber-tests/src/test/resources/features/5_TRACEFOSS-1625.feature b/tx-cucumber-tests/src/test/resources/features/5_TRACEFOSS-1625.feature new file mode 100644 index 0000000000..c116149b48 --- /dev/null +++ b/tx-cucumber-tests/src/test/resources/features/5_TRACEFOSS-1625.feature @@ -0,0 +1,46 @@ +@TRACEFOSS-1625 +Feature: [BE][FE]Handling of several parts in one quality alert + #*As* a user + #*I want* to be able to create and response quality alerts with several parts as one alert + #*So that* quality alerts with several parts are able to be processed on either sender or receiver side correctly + # + #*Outcome* + #* quality alerts are created on sender side as one alert even with several parts + #* quality alerts with several parts are sent correctly as one alert to the receiver + #* receiver creates one alert with several parts as sent + #* receiver and sender can change status and update each other for alerts with several parts + # + #*Additional information* + #Currently quality alerts with several parts are created correctly as one alert on the sender side but are created as own alert for each part on the receiver side. + #(!) Quality-Investigations are processed correctly! + + #Check if *several parts* are processed correctly in *one* created quality alert which contains following checks: + #* correct sending of several parts in *one* alert + #* correct reception of several parts in *one* alert on receiver side + #* correct update of *one* alert with several parts + @TRACEFOSS-1670 @TRACEFOSS-1920 @TRACEFOSS-1101 @TRACEFOSS-1673 @TEST-904 @TEST-1217 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of several parts in quality alerts + When I am logged into TRACE_X_A application + And I create quality alert with two parts + | "severity" | "MINOR" | + | "description" | "Testing severity TRACEFOSS-1670" | + Then I check, if quality alert has proper values + | "description" | "Testing severity TRACEFOSS-1670" | + | "status" | "CREATED" | + | "assetIdCount" | "2" | + When I approve quality alert + Then I check, if quality alert has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality alert has been received + Then I check, if quality alert has proper values + | "description" | "Testing severity TRACEFOSS-1670" | + | "status" | "RECEIVED" | + | "assetIdCount" | "2" | + When I acknowledge quality alert + Then I check, if quality alert has proper values + | "status" | "ACKNOWLEDGED" | + When I am logged into TRACE_X_A application + Then I check, if quality alert has proper values + | "status" | "ACKNOWLEDGED" | + | "assetIdCount" | "2" | diff --git a/tx-cucumber-tests/src/test/resources/features/6_TRACEFOSS-382.feature b/tx-cucumber-tests/src/test/resources/features/6_TRACEFOSS-382.feature new file mode 100644 index 0000000000..8466c11be6 --- /dev/null +++ b/tx-cucumber-tests/src/test/resources/features/6_TRACEFOSS-382.feature @@ -0,0 +1,59 @@ +@TRACEFOSS-382 +Feature: Create Request for quality investigation / store in queue + #h2. Remarks + #* (-) Test the solution + #* (-) Provide test data + #* (-) TRACEFOSS-392 + #* (-) TRACEFOSS-384 + #* (-) + # + #h2. User story + #As a user + # + #I want to be able to create a quality investigation for selected parts with a description of the defect + # + #to notify the corresponding supplier(s) of the parts about a possible quality issue that needs to be investigated. The requests should be stored in a queue with status pending and not be directly send to the supplier(s). + # + #  + # + #*Detailed description* + # + #The user can create a quality investigation for one or more parts. The description added in the pop up will be added to every part. Once the user creates a quality investigation he will get an information that there is one or more investigations pending for distribution. + #The user can click on the information and will directy be redirected to pending Queue in his Quality investigation inbox. + # + #  + # + #*Additional info* + # * - Description: free text, max length: 1000  + # * - Hint: Pending state and store in Queue because *later* we might set up a rights an role concept and only specific role (Supervisor) is able to send Notifications to partners. + + #Check if *several parts* in one investigation are processed correctly which contains following checks: + #* correct sending of several parts in *one* investigation + #* correct reception of several parts in *one* investigation on receiver side + #* correct update of *one* investigation with several parts + @TRACEFOSS-1652 @TRACEFOSS-1101 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of several parts in quality investigation + When I am logged into TRACE_X_A application + And I create quality investigation with two parts + | "severity" | "MINOR" | + | "description" | "Testing severity TRACEFOSS-1652" | + Then I check, if quality investigation has proper values + | "description" | "Testing severity TRACEFOSS-1652" | + | "status" | "CREATED" | + | "assetIdCount" | "2" | + When I approve quality investigation + Then I check, if quality investigation has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality investigation has been received + Then I check, if quality investigation has proper values + | "description" | "Testing severity TRACEFOSS-1652" | + | "status" | "RECEIVED" | + | "assetIdCount" | "2" | + When I acknowledge quality investigation + Then I check, if quality investigation has proper values + | "status" | "ACKNOWLEDGED" | + When I am logged into TRACE_X_A application + Then I check, if quality investigation has proper values + | "status" | "ACKNOWLEDGED" | + | "assetIdCount" | "2" | diff --git a/tx-cucumber-tests/src/test/resources/features/7_TRACEFOSS-1090.feature b/tx-cucumber-tests/src/test/resources/features/7_TRACEFOSS-1090.feature new file mode 100644 index 0000000000..1f1126f26f --- /dev/null +++ b/tx-cucumber-tests/src/test/resources/features/7_TRACEFOSS-1090.feature @@ -0,0 +1,43 @@ +@TRACEFOSS-1090 +Feature: 🪓⭐[BE] Add information to notification inbox + #As a *User* + # + #I want to have added the information of severity, send to (BPN / name), and received from (BPN / name) as additional columns to the notifications inbox + # + #so that I am able to see on the first sign who/whom the notification was sent to as well as the severity. + #h3. Outcome + # * Add an additional field for bpn name (sender + receiver) + # * Add an additional field for severity + # + # + #h3. Hint + #* BPN name and severity is published over the API that it could be requested by the frontend API . + #* Mapping between BPN number and company name is part of the job response of IRS. + # + #h3. Sprint Planning 2 + #* Add BPN and severity to the investigation response. + + #Check if *bpn names* of *sender and receiver* are processed correctly for created quality investigations which contains following checks: + #* correct creation on sender side + #* correct reception on receiver side + @TRACEFOSS-1344 @TRACEFOSS-1920 @TRACEFOSS-1101 @TRACEFOSS-1138 @TRACEFOSS-1673 @TEST-1217 @TRACEFOSS-1139 @TEST-904 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of bpn names in quality investigation + When I am logged into TRACE_X_A application + And I create quality investigation + | "description" | "Testing BPNs TRACEFOSS-1344" | + | "severity" | "MINOR" | + Then I check, if quality investigation has proper values + | "description" | "Testing BPNs TRACEFOSS-1344" | + | "createdBy" | "BPNL00000003CML1" | + | "sendTo" | "BPNL00000003CNKC" | + | "status" | "CREATED" | + When I approve quality investigation + Then I check, if quality investigation has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality investigation has been received + Then I check, if quality investigation has proper values + | "description" | "Testing BPNs TRACEFOSS-1344" | + | "createdBy" | "BPNL00000003CML1" | + | "sendTo" | "BPNL00000003CNKC" | + | "status" | "RECEIVED" | diff --git a/tx-cucumber-tests/src/test/resources/features/8_TRACEFOSS-608.feature b/tx-cucumber-tests/src/test/resources/features/8_TRACEFOSS-608.feature new file mode 100644 index 0000000000..7847904832 --- /dev/null +++ b/tx-cucumber-tests/src/test/resources/features/8_TRACEFOSS-608.feature @@ -0,0 +1,55 @@ +@TRACEFOSS-608 +Feature: ⭐[TEST] [BE] Set and show notification target date + #*As a* User + #*I want to* be able to set a target date for my notification while creating it + #*so that* I am able to monitor if a reply was given in time. + # + #h2. Hints + #[Concept | https://confluence.catena-x.net/pages/viewpage.action?pageId=69429778] + + #Check if *targetDate = null* is processed correctly for created quality investigations which contains following checks: + #* correct sending of _targetDate_ = *null* + #* correct reception on receiver side + @TRACEFOSS-1247 @TRACEFOSS-1920 @TEST-1217 @TRACEFOSS-1139 @TEST-904 @TRACEFOSS-1673 @TRACEFOSS-1138 @TRACEFOSS-1101 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of targetDate = null in quality investigation + When I am logged into TRACE_X_A application + And I create quality investigation + | "severity" | "MINOR" | + | "description" | "Testing without targetDate TRACEFOSS-1247" | + Then I check, if quality investigation has proper values + | "description" | "Testing without targetDate TRACEFOSS-1247" | + | "targetDate" | "" | + | "status" | "CREATED" | + When I approve quality investigation + Then I check, if quality investigation has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality investigation has been received + Then I check, if quality investigation has proper values + | "description" | "Testing without targetDate TRACEFOSS-1247" | + | "targetDate" | "" | + | "status" | "RECEIVED" | + + #Check if *targetDate* is processed correctly for created quality investigations which contains following checks: + #* correct sending of _targetDate_ + #* correct reception on receiver side + @TRACEFOSS-1216 @TRACEFOSS-1920 @TEST-1217 @TRACEFOSS-1139 @TRACEFOSS-1673 @TRACEFOSS-1138 @TRACEFOSS-1101 @TEST-904 @INTEGRATION_TEST + Scenario: [BE] Check correct processing of targetDate in quality investigation + When I am logged into TRACE_X_A application + And I create quality investigation + | "severity" | "MINOR" | + | "description" | "Testing targetDate TRACEFOSS-1216" | + | "targetDate" | "2099-03-11T22:44:06.333827Z" | + Then I check, if quality investigation has proper values + | "description" | "Testing targetDate TRACEFOSS-1216" | + | "targetDate" | "2099-03-11T22:44:06.333827Z" | + | "status" | "CREATED" | + When I approve quality investigation + Then I check, if quality investigation has proper values + | "status" | "SENT" | + When I am logged into TRACE_X_B application + Then I check, if quality investigation has been received + Then I check, if quality investigation has proper values + | "description" | "Testing targetDate TRACEFOSS-1216" | + | "targetDate" | "2099-03-11T22:44:06.333827Z" | + | "status" | "RECEIVED" | diff --git a/tx-cucumber-tests/src/test/resources/features/9_TRACEFOSS-2354.feature b/tx-cucumber-tests/src/test/resources/features/9_TRACEFOSS-2354.feature new file mode 100644 index 0000000000..da2dc65f46 --- /dev/null +++ b/tx-cucumber-tests/src/test/resources/features/9_TRACEFOSS-2354.feature @@ -0,0 +1,81 @@ +@TRACEFOSS-2354 +Feature: 👍[BE][TABLE_FEATURE] Implementation of Sorting in table views + #h2. Clarification + # * (/) [~steffen.duering@bmw.de] should cascading sorting be enabled ? --> [~martin.kanal@doubleslash.de]   If possible yes. Could also be done in a further development if not possible + # * (/) [~steffen.duering@bmw.de] On which result set the sorting shall be implemented (current page vs / complete resultset? ) + #-->[~martin.kanal@doubleslash.de]  complete resultset would be great. Is it possible? + # + #h2. Business Value + # # (y) [ ] {*}User-business value:{*}: + # # (y) [ ] *Risk reduction:* + # # (y) [ ] *Regulatory value:* + # # (y) [ ] *Commercial value:* + # # (y) [ ] *Market value:* + # # (y) [ ] *Efficiency value:* + # # (y) [ ] *Future value:* + # + #h2. User Story + # + #*As a user* of Trace-X + #*I want* to be able to sort within the table views + #*so that* I only see relevant data and I'm able to better handle big amount of data + # + #--> This User Story should cover all *Backend* tasks that are necessary to cover the funcionalities in the frontend + #h2. Outcome + # + #- (/) User can sort for any colums in UI (within all table views --> parts, other parts) + #- (/) Multiple sort functionalities can be set for ascending and descending according to concept for different attributes on the same time + #- (/) enable reset of sorting + #- (/) Cascading multi-column sorting on multiple columns (Number is showing the sort order) + #- (/) Sorting of columns is based on complete resultset  + #- (/) Swagger API documentation is updated and available on DEV + #- (/) Cover specific columns where cascading sorting might causes conflict (Takeing the semantic under account) + #h2. Mockup + # + #!screenshot-1.png|thumbnail! + #h2. NFR + # + #* + #h2. Hints / Details / Design Sketch : + # + #* + Then I check, if only assets with are responded + + Examples: + | owner-filter | + | "SUPPLIER" | + | "CUSTOMER" | + | "OWN" |