The version control system is usually solidly set up by a mature working team, but often it does not take full advantage of it, such as having traceability of what changes have been made in each version or a process to recover a particular release.
The branch strategy will determine the procedure when finalizing and sending the repository and a functionality which has been carried out between a computer, individually, code revision, resolution of a defect, a hotfix, etc. Effective branch management will allow you to be more agile in resolving these tasks.
The goal is to have a version of our project ready to be installed in any environment with the maximum security that will be fully functional.
Having a process of continuous integration avoids the nightmare of having to make large integrations of various sources manually, reduces the probability of appearance of defects by the integration of itself and allows to have new codes every day, propagated in all branches. Having a good configuration will allow the process to be simple and efficient.
Quality and pre-production environments must be as similar as possible to production. This allows us to correct deployment errors when detected in non-productive environments, minimizing the probability of failure in productive environments. It also allows us to have the product quickly ready for a demo, a UAT or functional or automatic testing tests. If this point is not achieved or is in part, we must identify and prioritize which parts should be implemented or strengthened.
These tools can be from a basic defect manager to a complete tool that allows you to manage a scrum team, with virtual post-it, calculation of burn-downs, control of kanban, etc. Generally the most effective is neither, but get to adapt the tool to the team process.
The QA profile in an agile team is not only focused on doing functional testing but has a much broader spectrum, starting contact with the Product Owner to understand their needs well and transmit them to the development team and the tests themselves, Managing incidents, leading retrospectives, ensuring continuous improvement, etc. This profile in the client's teams can be permanent in a person or a rotating one, but in any case it has to exercise its responsibilities and these have to be known by the whole department.
For both manual and automatic functional or performance tests, the system under test must contain some initial data. This data can be divided into configuration data, necessary for the system to work and business data, which are those that are added to the database during the natural use of the application.
Managing them correctly will reinforce the quality of our non-productive environments, allowing more complete results of functional tests (manual and automatic), performance, UAT, demos, etc.
Automatic testing will help us not only reduce test time, but also detect problems that would otherwise be impossible to find before reaching the productive environment. These automatic tests can be divided into:
During the life of the project, the final client should be able to have quick and clear feedback on the state of their project, ideally without contacting the development team. To do this you should be offered clear, simple and available indicators 24 hours. This information, together with the daily meetings, should allow for the rapid detection of bottlenecks in the process to be solved. For example, tickets which are too long and waiting to be validated or code waiting for technical review to be integrated.
The end user must have simple and effective channels to inform the customer of incidences with their product once it is in production.
All these questions and many others must be clear and an established procedure must be available to address them equally in all projects.