In a world where we had xRes fully automated, how would the workflow of a new feature look like? Here I create a imaginary scenario, and describe what would be needed for it to happen. Hypothetical scenario: Early Booking Everything starts with the requirements *Story* As a Hotel Provider, I'd like to inform special conditions for reservations considered "Early Booking". Such information should be kept by xres and furthermore exported to midOffices systems. *Details *An Early Booking can happen when a room reservation is made in a long term advance. The criteria to define the booking an Early Booking stays at the Hotel Provider side, so it decides when to apply and inform it. *Acceptance Criteria* 1. Initial Providers that should support EB information: MTS, HBD 2. Tags informed for EB: Deposit Price, Currency, Initial Deposit Date, Final Deposit Date 3. xRes must retain the EB information in the Booking 4. EB information should be displayed in the Booking Details page in xAdmin 5. EB Tags must be present in the XML Request of the exports for Midoco and xMid *Assumptions* 1. The EB information will be provided by the Hotel Provider in its XML response from Actions BA or B. 2. The EB Tags to be exported for MidOffices will follow the example provided and attached in this task. After all the requirements clarified, the story can be broken down into smaller tasks. The development should make sure that not only the new functionality has been achieved, but also that there is enough evidence for it to be validated in both automated and human ways. In parallel, the Test Cases can be written, asserting that all the requirements will be satisfied and without any side effects. Test Cases *#TC1* *Scenario* One Hotel Room with a single bed and all services included is booked for one man 6 months in advance. *Steps* 1. With any booking interface, perform an Action BA. 2. Perform an Action B. 3. Export the new booking to MidOffices. *Expected Results* 1. A new Booking should be created. 2. In the booking details page, information about Early Booking should be visible in the Hotel block. 3. The Request XML of the export for xMid should contain the EB info in the correct standards. 4. The Request XML of the export for Midoco should contain the EB info in the correct standards. More complex scenarios could be created, or even scenarios considering failures from third parties could also be considered. For example, a family of two adults, one child and one infant book two rooms, but the provider responds with invalid format dates in one of the EB tags. The Test Case should follow the same concept, and the Expected Results should be established. But for this example, I we will keep only the Happy Path. Functional Test Automation The Functional tests should be running in a controlled and isolated environment, with a dedicated xRes instance and Database. That way, it is possible to break it without consequences. Here's how it'd look like: Explaining the diagram above, as said before, everything starts with the Requirements (Test Cases). As many Test Cases as possible are transcribed into Automated Functional Tests, on a Test Automation Platform. The Test Automation Platform can be any tool or technology that supports High level automations. It could be Postman, Behat, Selenium, Codeception, etc. The list goes on. Regardless of the solution, the Automated Tests Platform should be capable of: * Have access to the Config files for Tests Setup; * Have access to the DB for Setup, Cleanup, and Assertions; * Have access to Log files for Assertions; * Have access to Shell Command Line input and output for Tests executions and Assertions; * Be able to perform HTTP requests; Given that the solution which I have more experience with is Behat, and I know for a fact that it supports such low level actions behind the system, we'll use it in this example. In Behat Gherkin language, a test would be something like this: Feature:In order to see the Early Booking information As a xAdmin user, I want to book a room and export it. Scenario:Book an Early Booking Hotel Room and export it. Given my name is "Rodrigo Cinto", 31 years old, email "r.cinto@traso.de" And I live in "Leipzig", address "Nonnenstrasse42", Zipcode "04229" And I book a Hotel BERLIN with services DZZA And from "201120" to "221120" When I make an Action BA And I make an Action B And the Hotel Provider responds an Early Booking with Deposit Price '100.00', Currency 'EUR', Initial Payment Date '2020-02-05', Final Payment Date '2020-11-05' And I execute the MidOffices export queue Then I would like to see "Early Booking" and "2020-02-05 - 100.00 EUR" in the "Last booking details page" And I would like to see "Early Booking: 2020-02-05 - 100.00 EUR" in the "Midoco export logs" And I would like to see "Early Booking: 2020-02-05 - 100.00 EUR" in the "xMid export logs" It seems a little sorcery, but Behat allows you to create a PHP function for each one of those statements with help of Regular Expressions. To possibilitate full environment control, the responses from the External Services Providers like Hotel, Flights and Transfers must be provided by a Fake API Server, or Provider Simulator. This Fake API Server is a very important component, which can be configured to answer to any request, with any response, following the Tests Requirements. To make sure the Tests don't compromise other environments, a separated instance of xRes and Databases should be provisioned as well, with copy cats of Hotels, Flights, Users, and so on. The new tests are then stashed among all the other previously created tests, each one of them with their own setup, execution, assertions, and tear down. Now it is time to integrate the Automated Functional Tests with the rest of the workflow. Good thing about automation is that we can run it whenever we want. Therefore, we should be able to decide whether we'd like to run the tests or not during a new Release launch. Is it a heavy push? We should wait for the tests to be executed. Is it a hotfix that needs to be pushed as quick as possible? Leave the Functional Tests for later. It would even be possible to schedule periodic executions, in order to make sure the system is tidy and there are no hidden surprises in old delivered features. Still speaking of Releases, after it is done, only then we can finally check manually the Test Cases we couldn't or didn't want to automate, but in a perfect world they should be minimal verifications. How far are we from it to become reality? Not much. 1. The xRes developers are significantly mature regarding the concept of mocking API responses, and we have more then one solution for that, from the lowest interaction level to the highest. The only thing we'd have to do would to provision an actual machine for the tool. 2. We'd need to install a brand new instance of xRes. But we have the needed expertise and it would be a perfect opportunity to learn more about how xRes essence works. 3. For the Test Cases, we'd have to change our mindset regarding reading and writing requirements, and documenting our Tests. Big challenge at this one. 4. The testing platform would require a learning curve, but we are smart people, and we are used to learn something new every day. 5. We already have customizable deploying tools like Bamboo, so adding a new optional routine to it wouldn't be too hard.
