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(a)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.
