In a previous blog post, I promised that I will talk about T.A.S - short for Test Automation System.

The Challenge

Back in 2016, I’ve got the opportunity to become the test automation Architect of T.A.S. – a framework specialized in testing the core components of Alfresco Platform - a global leader in the field of Enterprise Content Management Platform for Business and Transactional Services.

My goal was to accelerate the time to market of Alfresco’s new features, by reducing the manual burden of

• testing
• provisioning environments
• stack testing (differed DB, Operating Systems, versions of libraries)
• compatibility testing,
• integration and upgrade testing,
• validation of extension points
• installer testing and much more.

(all with the help of a new unknown solution at that time).

The challenge was to architect and design from scratch a MVP (Minimum Viable Product) for test automation purposes that should be:

• easy to use for junior engineers
• easy to understand and use
• easy to extend
• easy to integrate into existing projects
• with custom reports that show bugs, errors, critical failure and logs
• the backbone of test automation approach through all engineering teams
• capable of testing multiple Alfresco versions
• integrated with test case management system to automatically generate the test cases from automated scripts (not manual intervention)
• adoptable by ALL development teams: a really, really hard objective backed up but hands-on workshops, clear documentation, even hours of “How To” and “step by step videos”

The Solution

During a three-week discovery period I’ve capture the existing processes, tools, cultural perspective and roles in the engineering teams in order to analyse the bottlenecks in the testing process.

The final design ideas were to define differed Maven projects interconnected (using Spring Bean capabilities), built entirely with open source technologies, that are testing in a human friendly Domain Specific Language (DSL) core APIs and Protocols of Alfresco.

Each Protocol and API of Alfresco displayed above had a corresponding maven project

• alfresco-tas-cifs
• alfresco-tas-webdav
• alfresco-tas-ftp
• alfresco-tas-emai
• alfresco-tas-aos
• alfresco-tas-restapi
• alfresco-tas-cmis

The DSL was defined into a common alfresco-tas-utility project and implemented by each project above.

In utility project I’ve incorporated common helpers or test validation assertions (like checking server health), data preparation mechanisms, reporting templates, test data files core DSL, interfaces that will make my life much easier in the implementation phase; plus much more goodies.

Checkout the interfaces defined and examples from two projects. Notice the similarities of the DSL

The code snippets presented above will implement the interfaces of the alfresco-tas-utility project and use the existing opensource library to drive the execution. This is just a glimpse of the design aspects of the DSL.

At the end, T.A.S. was used as a way of validating differed types of testing (Sanity, Regression, etc.)

Did I mentioned that we also had an Integration project built, that will use all TAS components in combination to generate new integration workflows?

The Results

Now teams have:

• more time to focus on development and testing other areas not touch already by automation – in order to improve the product for customers
• strong confidence in the quality of the product due to robustness of the T.A.S
• high level of test coverage across the platform
• provision reduce from hours (sometimes days) to minutes on differed technology stacks
• compress the cycle time from days to hours
• modularized test framework: they will pick and choose only the necessary components of T.A.S in order to fulfil their testing needs.
• a common way of writing functional tests using business friendly DSL as you saw above.

Graphics resources used in this page (not technical ones)

• Designed by Naulicreative / Freepik
• Designed by rawpixel.com / Freepik