General checkpoints
As mentioned before, there should be some basic checkpoints to determine the quality of each work item. They are based on the internal quality document called MVPQ (Minimum Viable Product Quality), a document that gives team members the quality guidelines expected by the company for each product, hence any team needs to follow the next checkpoints in any DoD:
Features should be implemented in a generic way (considering all variants) and following a standard mechanism
All new features, bugs fixed, and any other change in the code should be added in the most generic way possible to avoid “workarounds” and attack the problem from the root. The code always needs to consider different variants for the current solution or future solutions in order to prevent extra work in later stages. This point accomplishes the 2nd point in the MVPQ document.
Robust error handling
The new code should contemplate different scenarios in case an error occurs. In other words, the solution should be robust at the error-handling to avoid any crash in the project and maintain the quality for any user in general. This accomplishes the first point in the MVPQ document:
1- Robust error handling. Must include error traps for both unexpected and known but uncovered inputs, from parser through code gen. The product cannot crash, it provides error recovery mechanisms for parsing and conversion of unexpected inputs (which include offending code with a description/reference of offending issue).
Source: MVPQ (Minimum Viable Product Quality) internal document.
Fix or refactor errors in working file(s)
This point is related to gradually improve the quality of our products. The idea is to change or refactor little errors in the file(s) being worked in the PBI or bug such as variables without a descriptive name, typo errors, etc. This is not a rule, and it is the duty of the developer to determine if the changes are invasive or not and the adjustment is fast. In case of applying those changes, if they are few, send them in the same Pull Request of the main work (PBI or Bug). On the other hand, send the changes in a different Pull Request with a good description of the changes or refactor made.
Unit tests are created or updated
All new code needs to be tested using unit tests to ensure the good behavior of the code in different scenarios and a good level of code coverage in the project. Furthermore, the minimum code coverage in the newly added code needs to be no less than 90%. This point accomplishes the 4th point in the MVPQ document (see Unit Test):
4 - Unit Tests: Add new unit tests with each PR. Developer adds new Atomic/Elemental/Small-Grained tests covering at least 90% their proposed code changes. This point if verified using SonarQube showing coverage at 90% on new code.
Source: MVPQ (Minimum Viable Product Quality) internal document.
Integration tests are created or updated
In some cases, when new code is added testing that new code with existing code is necessary to check if the new behavior works like it is expected with other modules or functionalities. Thus, if the new change agrees with the previous explanation, it is necessary to add one or more integration tests (see Integration Test).
Note: In the company, the concept of integration test is more like system tests used to determine how the product works with some specific features but without using the user interface (UI).
Functional tests are created or updated
Some changes could affect how a converted project works. Hence, adding one or more functional tests is necessary to determine if the new change works as expected. This black box testing helps us to check in our pipelines if the change added could have a regression in the future. For this reason, adding this test when necessary is important (see Functional Test).
Note: This point applies when the team has already this level of test or exists some demo(s) to test.
Document the work made
All new code added must have comments in code when necessary, so any user can understand the behavior of the new changes. These comments need to be clear to avoid misunderstanding. Furthermore, it is necessary to update the user documentation and technical documentation of the product changed (if applicable). This point accomplishes the 3rd point in the MVPQ document (see Code Standards):
3 - Documentation: use inline comments to clearly document the API and internal features so future developers can understand, support, and maintain. Additionally, update of any already existing documentation that is affected by current pull request changes must be included. This point if verified at code review time by product lead or peer developer confirming the code is easily understandable from comments without verbal explanation.
Source: MVPQ (Minimum Viable Product Quality) internal document.
Changelog file updated after new implementations
The changelog file in each project must be updated when changing the code. . In this case, the concept of important could be different depending on the person. However, the idea is to update that file when adding some functionality. If the code is updated without changing the functionality or a refactor is made, it is not necessary to update the changelog. In case of doubts, please talk with the Quality Assurance department. This point is related to the 3rd point in the MVPQ document mentioned above.
New code does not have code smells
All new code added should comply with basic code standards and avoid regular errors like duplicate code, duplicate functionality, big methods, big classes, big functions, a lot of parameters in one function, and other common errors. To avoid that, one can check these problems in the build process before completing a Pull Request in TFS or see the alpha build (this point depends on the infrastructure of each team).
Pull Request (PR) approval
This point is related to the Peer reviews. The idea is to check different important aspects in each Pull Request before accepting it. Those aspects could be checked if the PR is small and independent. Check for robustness, maintainability, readability, and consistency, also if the new code added or refactored complies with the code standards and satisfy the basic principles of code quality. Finally, it is essential to accomplish the first checkpoints in this process and provide a general solution as well as for the changes (if the code is new) having unit tests or the existing ones being updated.
Local branch build is successful in TFS
The idea is to check if the corresponding building of the change is successful or green. This means that the change is correct and the integration with the product does not have any problem. It is important to mention that some builds trigger others builds, so it is necessary to verify that all of the different builds corresponding with the change are successful and not only the first one. If something fails, it is necessary to check the recent change and fix the errors(see DevOps).
Demos must compile and the respective tests must be successful
Any change made in any product could change some functionality or affect some control or behavior in the migrated projects. Consequently, the different teams must verify those changes using their own demos or external projects with their respective tests to catch any regression. Because of that, it is important to convert and build those demos and run those tests locally or using the alpha pipeline to run the alpha branch to avoid regressions in the different components or modules of the product (see Run test projects and DevOps Pipelines).
Breaking changes are notified to other teams
Sometimes the change is correct but affects other teams. Notify other teams about the recent changes in order to avoid misunderstanding or communication failures between teams. Only notify the concerning teams.
QA approval
Each Product Backlog Item (PBI) or bug must have the approval of the Quality Assurance responsible to assure that all the checkpoints above are successful, and the tests created or updated have the minimum quality expected (see QA Review).
PO approval
Additionally, for the QA approval, it is important to have the Product Owner (PO) approval to determine if the work made during the PBI complies with the expectations or requirements of the PO and the product, and finally, the acceptance criteria is totally done (see PO Review).
Important Document
Last updated