Wikipedia, the source of truth, defines quality assurance as:
A way of preventing mistakes or defects in manufactured products and avoiding problems when delivering solutions or services to customers.
But this is not always easy. Sometimes, we are in a hurry, part of the team is not available due to personal reasons or holidays. Sometimes the deadline is so close to the moment where the product is defined that we sacrifice quality in favor of releasing something. Additionally, as software products usually evolve, we should also think about the quality of the code itself and not just the final application. We often have to maintain that software for so long, that a huge design error would take us months to fix it.
Nevertheless, when we sacrifice quality in favor of a deadline, we always think that we are delivering the expected product. We never think that there is an acceptance criteria failing. When we cut corners, we just think that, perhaps, a rare scenario is not implemented properly but the happy path will always work! Think about it for a moment: if every time we talk about deadlines the first thing we sacrifice in a product is quality, we are not writing the software our clients deserve (Sergio Arroyo dixit).
If we are developing a long-term project, quality should always be present on our minds. That's why we've tried to describe what's the definition of quality for the software we write in Karumi. Today we are really happy to introduce to you our official quality assurance guidelines!
https://github.com/Karumi/project-quality-assurance
We've created a GitHub repository you can find here where we describe what quality assurance means to us in different contexts. These are the guidelines we follow for every single project! And these guidelines are related to:
- Pull requests
- Continous integration
- Architecture
- Performance
- Automated testing
- Release processes
- Issues reporting
- Version control systems management
- Errors reporting
- Project management
- Distribution
As the projects we develop can be different we've created specific sections by platforms. For the moment, we've described our guidelines for Android and iOS, but don't worry, we will publish backend and frontend guidelines soon. We decided to use a GitHub repository because we wanted to share these guidelines with you and keep a history of the changes on these documents.
So, next time you need to cut corners for a deadline, review these guidelines. If you are not following any of these topics, check if the reason is good enough and talk to your team. Based on these guidelines you'll always have a document to point at when discussing if we should or should not do something in favor of the next release. Remember, never give up, quality matters!