We help you measure your SDLC’s current state to improve your development quality.
We analyze your entire software development lifecycle, from defining Acceptance Criteria to monitoring your application in production. We interview all of the roles involved in the SDLC to construct a complete picture of all of the potential improvement areasof your development.
Can you improve the efficiency of your quality efforts?
Anticipating errors, shifting left in your development process is as simple as pressing the right buttons.
We register, group and analyze evidence to assess your development lifecycle
Acceptance Criteria are a set of statements that describe the expected behavior once the User Story has been developed. They are the requirements we use to evaluate whether development matches our expectations from the final user’s perspective.
Providing a good acceptance criterion increases confidence in the product reflecting our intentions, reduces the chance for issues and speeds up development, since rejections in feedback and production should become less frequent.
The version control system is usually deeply rooted in a mature work team, but oftentimes it does not take full advantage of it, such as by providing traceability for all the changes contained in a version or having a process to recover a specific release.
The branch strategy will determine the procedure when finalizing and sending a feature crafted by a team to the repository, code reviews, issue resolutions, hotfixes, etc. Effective branch management will allow us to be more agile in solving these tasks.
The goal is to have a completely functional version of our project ready to deploy with maximum security in any environment at any time.
Having a continuous integration process can spare us the nightmare of manually integrating multiple sources, reduces the chance for issues from the integration itself and allows us to have fresh code every day, pushed to every branch. Configuring it correctly will make the process simple and efficient.
QA and pre-production environments must be as similar as possible to production. This allows us to correct deployment issues by detecting them in non-productive environments. It also allows us to quickly ready our product for a demo, an UAT or functional/automated testing. If this area is completely or partially unimplemented, we must identify and prioritize which areas must be built or reinforced.
These tools range from a basic issue manager to a complete toolset that allows us to manage a scrum team, with virtual post-its, burn-down calculator, kanban control, etc. Generally the most efficient solution is neither of the extremes, but rather adapting the tools to the team's process.
The QA role in an agile team isn’t just about crafting functional tests but rather about a much more holistic approach, from contact with the Product Owner to understand their needs and transmit them to the development team and the tests themselves to issue management, leading retrospectives, caring for a continuous improvement, etc. This role in client teams may permanently fall on a specific person or rotate, but in any event they must exert their responsibilities and these must be known by the whole team.
When executing manual or automated functional or performance tests, the system under test must contain certain initial data. This data can be divided into configuration data, needed so the system can function, and business data, which is added to the database during the application’s habitual use.
Managing data correctly will improve quality for non-productive environments, allowing more complete results in our functional or performance tests, UAT, demos, etc.
Automated tests will allow us to not only reduce testing times but to als detect issues that would otherwise be impossible to find outside of a production environment. These tests can be divided into:
During the project’s lifecycle, the client must have clear and quick feedback on the status of their project, ideally without needing to contact the development team. To achieve this, clear and simple indicators must be provided 24/7. This information, alongside daily meetings, must allow rapid detection of any bottlenecks in the process that must be addressed. For example, tickets that are stuck too long in validation or awaiting a code review to be integrated.
The end user must have access to simple and effective channels to report any issues in the product to the client once it reaches production.
Will the main communication avenue be by phone?
Is a ticketing tool available to open issues?
How are these issues managed within the development team and how is the client given feedback?
What is our effectiveness resolving incidents?
All these questions and many more must be answered clearly and an established process must be available to attack them in the same way in every project.
A 100% tailor-made collaboration. Our teams use the testing strategy that best suits your team's development process.
We select the most suitable methodologies, frameworks, languages or tools for each project, without imposing any.
Our management includes:
"Only what is measured can be improved"
In Redsauce it is of paramount importance to have clear and useful reports of execution results. That is why we configure the tests and the continuous integration server to generate them and provide you with real value.
Objective Indicators = Measurable Results = Real Results
We will work in close communication with you, using agile processes. Startups and large companies have already trusted us.Contact now