Through these practices, we guarantee the delivery of reliable, secure, and high-performing solutions that meet your exact requirements.
| Activities | Purpose | When | Who | Environment |
|---|---|---|---|---|
| 1. Self Code Review | To have a chance for developer to review the coding by themselves and correct it, also to avoid performance degradation |
|
Developer | Local development |
| 2. Unit Testing |
|
|
Developer | Local development |
| 3. Coding Review |
Senior/Principal developer to do the code review to avoid:
|
As needed | Senior/Principal Developer | Local development |
| 4. Test Checklist | To ensure all necessary tests have been conducted | During testing | Developer/Testing Team | Test environment |
| 5. Coding Scanning | To review and correct coding, prevent performance degradation |
|
Developer | Local development |
| 6. Security Scanning | To test code for security vulnerabilities |
|
Developer | Local development |
| 7. Performance Testing | To evaluate code performance and identify issues | As needed | Testing team | Test environment |
| 8. Acceptance Criteria | To define criteria for accepting completed work | As required | Business Analyst team | Team environment |
Upon receiving Sprint Backlogs, the Development Team initiates the implementation process and ensures adherence to all quality gates before release.
Gate 1: Code Scanner
Prior to merging and deploying the code, the system utilizes the SonarQube tool for code scanning, reviewing coding conventions, best practices, identifying bugs, and other issues. The developer is responsible for addressing all SonarQube findings before proceeding to Quality Gate 2.
Gate 2: Code Review
Before merging and deploying the code, it undergoes review and approval by another developer to detect potential problems related to coding logic or any impact on other functionalities.
Gate 3: Basic Check
This involves a checklist of features that must be completed for each function. The Business Analyst creates the checklist based on the Acceptance Criteria, ensuring that no criteria are missed. Prior to code review, the developer must confirm the successful completion of the Basic Check for the respective function.
Gate 4: Testing
Once functions are deployed to the staging environment, the testing team evaluates their quality. They utilize pre-defined test cases, project experience, and specific testing techniques to assess the function’s quality. At the conclusion of the testing process, a final assessment is made to determine whether the function is eligible to proceed to Quality Gate 5.
Gate 5: Sprint Review and Functionality Release Decision
At the end of each Sprint, the Product Owners and Stakeholders review the completed features/functions during the Sprint Review meeting. Based on these discussions, the Product Owner, in consultation with the Stakeholders, decides which functionalities will be released to production and which require further updates.
Note: In exceptional cases, it may be possible to bypass certain Quality Gates and deploy directly to the Production environment. However, this decision must be agreed upon by the Product Owner and communicated to all relevant parties.
Don’t Hesitate, Contact Us Now!
