Chapter 1: A system to an end to end quality process

We all know that the answer of what can be tested in a system is everything, but the issue arises on the part of what we can test, how much time/ budget do we have and what is our scope.

In the last three months We've been working in building and setting up a collection of what internally we call it Toolbox and will enable us to test a system that is complex in bussiness logic and technical too due constraints in legacy and old parts.

As far as my experience goes I've been building everything on 3 simple rules, which in their simplicity allows us to comeback and think if in every step Im moving in the right direction:

• It is on our own nature to fail and make mistakes. Nothing we can do about it
• Acknowledging it, allow us to provide safety nets around our engineering proccess, personal and collective.
• There is no recipe on how to bring quality, so we must engage with it in a thoughtful manner.

That thoughtful manner is approached in four simple points:

• Modularized solutions for each layer as We want specific tools that resolve specific problems and can be easily replaced
• System and Integration testing layers approached.
• Ease of use and understanding
• Useful

This is the first approach to it , and I think is a good starting point

We will go down the rabbit hole of each of the boxes in future posts, but for now lets center on the high layers

• Dashboard as entry point
• CI / CD tool that allows trigger test executions and orchestrate information flows
• Repositories with frameworks for testing diferent layers, libraries that provide reusability and custom applications for the interaction inside and with the Toolbox
• Execution tools that enriches the execution and provide extra capabilities to the test frameworks and altought are not part of the testing activity per se, enables it
• Reporting toolset which we could divide in:
  • Report to our source of true (Test Management software)
  • Report for stakeholders and non-engineer team people (Allure)
  • Report to our planning system (Project Management software)

In this sense:

• Dev's, QA's and Managers positions will access the dashboard to trigger specific executions and depending on their role will look in different reports where information varies.
• QA's and Dev's will colaborate together in the building of new tools providing not only the tool but also a way on integrating themselves into the toolbox and being able to report in an unified manner.

Next week I will give a glimpse on the dashboard v1.0 and what is our final version in mind.

See you, same hour at same time.