More often that not, an effective collaboration between QA engineers and DevOps/Infra team is a deciding factor in continuously delivering software changes, and also in shifting the delivery timeline left.
In this context, the basic understanding on CI/CD tools gives a head start for QA engineers on setting up CI/CD pipeline, that orchestrates triggering of automated tests after build and deployment tasks. In this post, I will quickly summarise as to what QA engineers could offer when such synergies happen.
— Get to know the source code repository being used by developers and its associated branching strategies, considering a multiple environments (qa, staging, production) will come in handy.
— Knowing the high level architecture of a product helps a lot as many a times, there are more than one component required to be deployed for an application to up and run, such as front end, back end etc. This is surely helpful, so we know as to which deployment specifically requires the automated testing to be triggered.
— Basic knowledge on CI/CD tools helps to setup a pipeline organically without depending on additional extensions/plugins. Of course, every tool on the market uses its own terminologies, but they all essentially share the common goal of orchestrating tasks such as checking out the source code to build server, building the project and generate package/artifacts, deploying packages/artifacts to targeted servers and testing the deployed packages.
— It’s needless to say that understanding on tech stacks, along with capabilities of automated framework being used. Most of all, if one could able to run tests from command line interface rather relying on IDE’s, the integration of automation projects in CI/CD platforms will become straightforward by using command line tools offered on all CI/CD platforms.
— Be mindful of the fact that tests do not simply run on a CI/CD server, but on remote agents or docker containers that are connected to the server. Thus, it’s a duty of qa engineers to facilitate and install prerequisite softwares, tools or any dependency on agent machines.
— Build a separate pipeline that triggers automated tests, but at the same time make it ‘dependent’ on deployment specific pipelines so it runs post every deployment ; this one is typically looked after by QA engineers and can also be configured in a way to have a multiple triggering strategies: 1. automatically trigger after the deployment, 2. run on scheduled time and 3. manually trigger when required.
— Lastly, every CI/CD platform has a basic option to parse and publish JUnit test results and also, to mark the associated build status as success or failure, based on the test results.
On a final note, companies are often restrictive in providing necessary accesses for the resources related to development or deployment to qa engineers, nevertheless it doesn’t have to affect the solution in anyway. Fight for your privileges!
Thank you!
Veera.
