Thông qua các quy trình và tiêu chuẩn này, chúng tôi đảm bảo cung cấp những giải pháp tin cậy, bảo mật và hiệu năng cao, đáp ứng chính xác các yêu cầu của khách hàng.
| Hoạt động | Mục đích | Thời điểm | Người thực hiện | Môi trường |
|---|---|---|---|---|
| 1. Tự kiểm tra Code | Tạo cơ hội để Developer tự rà soát và chỉnh sửa Code, đồng thời tránh làm suy giảm hiệu suất. |
|
Developer | Môi trường Development Local |
| 2. Unit Testing |
|
|
Developer | Môi trường Development Local |
| 3. Coding Review |
Senior/Principal Developer thực hiện Code Review nhằm tránh:
|
Khi cần | Senior/Principal Developer | Môi trường Development Local |
| 4. Test Checklist | Đảm bảo tất cả các Test cần thiết đều đã được thực hiện. | Trong quá trình Testing | Developer/Testing Team | Môi trường Test |
| 5. Quét Code | Rà soát và sửa lỗi Code, đồng thời phòng tránh suy giảm hiệu suất. |
|
Developer | Môi trường Development Local |
| 6. Quét bảo mật | Kiểm tra Code để phát hiện các lỗ hổng bảo mật. |
|
Developer | Môi trường Development Local |
| 7. Kiểm thử hiệu năng | Đánh giá hiệu suất của Code và xác định các vấn đề phát sinh. | Khi cần | Testing team | Môi trường Test |
| 8. Tiêu chí nghiệm thu | Xác định các tiêu chí để nghiệm thu phần công việc đã hoàn thành. | Khi cần | Business Analyst team | Môi trường Team |
Sau khi tiếp nhận Sprint Backlog, đội ngũ phát triển bắt đầu triển khai và đảm bảo tuân thủ đầy đủ các cổng kiểm soát chất lượng trước khi phát hành.
Cổng 1: Quét Mã Nguồn
Trước khi merge và triển khai mã nguồn, hệ thống sử dụng SonarQube để quét mã, kiểm tra quy chuẩn lập trình và các best practices, đồng thời phát hiện lỗi và các vấn đề tiềm ẩn. Developer có trách nhiệm xử lý toàn bộ các vấn đề được SonarQube phát hiện trước khi chuyển sang Cổng kiểm soát chất lượng 2.
Cổng 2: Kiểm duyệt Mã nguồn
Trước khi merge và triển khai, mã nguồn sẽ được một Developer khác kiểm tra và phê duyệt nhằm phát hiện các vấn đề tiềm ẩn liên quan đến logic lập trình hoặc những ảnh hưởng có thể xảy ra đối với các chức năng khác
Cổng 3: Kiểm tra Cơ bản
Quy trình này bao gồm checklist các hạng mục cần hoàn thành cho từng chức năng. Business Analyst xây dựng checklist dựa trên Acceptance Criteria (Tiêu chí nghiệm thu), đảm bảo không bỏ sót bất kỳ yêu cầu nào. Trước khi tiến hành Code Review, Developer phải xác nhận chức năng đã hoàn thành đầy đủ Kiểm tra Cơ bản.
Cổng 4: Kiểm thử
Sau khi các chức năng được triển khai lên môi trường Staging, đội ngũ kiểm thử tiến hành đánh giá chất lượng. Tester sử dụng các test case được xây dựng trước, kết hợp kinh nghiệm thực tế của dự án và các kỹ thuật kiểm thử phù hợp để đánh giá chất lượng chức năng. Sau khi hoàn tất kiểm thử, đội ngũ thực hiện đánh giá cuối cùng để xác định chức năng có đủ điều kiện chuyển sang Cổng kiểm soát chất lượng 5 hay không.
Cổng 5: Đánh Giá Sprint & Quyết Định Phát Hành Chức Năng
Vào cuối mỗi Sprint, Product Owner và các bên liên quan (Stakeholders) sẽ đánh giá các tính năng/chức năng đã hoàn thành trong buổi Sprint Review. Dựa trên kết quả trao đổi, Product Owner phối hợp cùng các Stakeholders quyết định chức năng nào được phát hành lên môi trường Production và chức năng nào cần tiếp tục cập nhật, hoàn thiện.
Lưu ý: Trong một số trường hợp đặc biệt, một số Cổng kiểm soát chất lượng có thể được bỏ qua và chức năng được triển khai trực tiếp lên môi trường Production. Tuy nhiên, quyết định này phải được Product Owner thống nhất và thông báo đến tất cả các bên liên quan.
Đừng ngần ngại, hãy liên hệ với chúng tôi ngay!
