Quality Assurance & Release Management should be F . R . I . E . N . D . S

Last May was the 15th anniversary of the last chapter of one of my favourite TV series, FRIENDS. One of the biggest secrets of its success lies in the way it captures on screen the situations that many of us go through, and continue going through, as part of our daily lives: friends, work, family, money … and love (of course).

In my case, 15 years after its end, I still see similarities between what the series taught me about the many facets of my life, and one such lesson is one I see daily in the relationship between two disciplines that currently affect my work performance: Quality Assurance & Release Management.

These processes of quality assurance and release management are closely linked within software development. They are two branches that collaborate closely with each other and often end up converging in the same team or person. You could say that QA & RM can’t live without each other, they must always be connected, they can’t afford to take a break…

In this article, I’m going to review the basic principles that every quality tester should follow and understand about the process of software release management, uniting both areas in the common goal of developing quality software.

The importance of the implementation process

The main task of a tester is the execution of tests to guarantee the quality of the software and to check that previous work has no errors.

As Monica Geller used to say: “If I’m harsh with you it’s only because you are doing it wrong.” It’s not that testers or release managers are hard on developers, it’s that we have to make sure that the results are excellent…

The success of the testing phase depends to a large extent on the success of the implementation. If the tester has closely followed the development process and knows that the back/front-end teams encountered certain problems when implementing the code, the QA team will be able to identify many errors that may be related to the implementation process. And therefore, it will also be easier to propose the right solution to the right teams.

If testers are aware of how the implementation process has developed, they will also understand and appreciate the importance of completing their tasks within the planned timeframe. Many failures could be avoided if testers were fully aware of how the software was deployed.

Having control over different test environments

In a software development organisation, several test environments often coexist together. The members of the quality teams and the release managers must always have access to all environments to ensure that the development and testing processes are correct.

It would not make sense for a release manager to have access to certain environments but not to others, because in the end this person is the one who will give the go-ahead to release the software. In an agile environment there is no place to keep “under lock and key” certain parts that are necessary to verify the correct functioning of a piece of software. The contents must be shared, we can’t act, like Joey, as if “we don’t want to share our food.”

Typically, two pre-test environments and one final test environment are built before moving to the production environment. The end customer is also given access to the pre-production environment so they can provide approval before the final release.

Bring Developers, the QA team and Release Managers together to the same place

The role of testers and quality assurance is much more important to a company than its often perceived stereotype of being “error seekers.” Not only should they identify defects after developers have finished their work, but they should also take a proactive role in preventing possible failures at an early stage.

For this, testers should take on an advisory role, recommending tools and best practices to help speed up the process for developers. Similarly, release managers should facilitate this relationship from the early stages of development, serving as a link between all the departments involved.

It’s a recommended practice that the areas of development, quality and release management meet at the beginning of each sprint to ensure that everyone understands what’s going to be built and how it’s going to be tested. In this way everyone feels like different parts of the same team, working together to create an irresistible product.

At this point it’s worth mentioning the importance of the agile working model instead of the classic cascade model in which one phase of the process depends on the completion of the previous phase. Testing and development must take place simultaneously during a sprint. In this way we’re able to prevent “bad things” from happening that could affect the whole structure and on the contrary may only affect a part of the development.

Release deployment calendars: planned and hotfixes

Each organisation has its own schedule of planned deployments. These calendars are agreed between the different areas of development, QA, release management and the final customer. On many occasions, they are released on a monthly basis.

In principle, there is no reason for anything to go wrong with a planned deployment that has been properly tested, but it can happen that a bug is found during the launch process or even when the new version is already in pro. In this case we would move to another type of deployment, what’s known as a hotfix that uniquely corrects the bugs found in the code.

Deployments are made at times when the team doesn’t need to wait until the next day of planned deployment. Once again, coordination between all the areas involved is required so that there are no unexpected failures and, if there are any, everyone has the visibility, and ability, to resolve them quickly and without “knives flying.”

Quality Checklists

A quality checklist is a means for checking the accuracy of test processes. All operations consist of several steps to be checked from a quality assurance area, especially complex and iterative processes.

Normally the design and implementation of this type of list is the responsibility of the quality area but once again, working together with the release manager will ensure that important issues are not overlooked.

QA checklists can be structured according to the process type, testing methodology, or product category. We can create a checklist for each stage of the software testing lifecycle:

• Test planning — prepare the test plan and strategy, select tools, allocate resources and determine team roles.
• Test case development — create test cases, automation scripts and generate test data.
• Test environment setup — this is a great example of areas where a QA checklist can be successfully implemented, it’s applicable for all types of projects and involves several teams.

Conclusion

These two disciplines — Quality Assurance & Release Management — simply cannot live without each other.

It’s not a question of whether quality assurance encompasses release management or the other way around, it’s a question of both walking hand-in-hand, sharing knowledge, information and reaching the same point: the delivery of software of the highest possible quality.

Let’s walk together, let’s hold hands, let’s be F . R . I . E . N . D . S

Pictures & GIFs in this post belong to NBC’s FRIENDS and were retrieved from Giphy.