Giới thiệu dự án

Trong kỹ nghệ phần mềm hiện đại, quy tắc kinh điển từ năm 1979 của Glenford J. Myers vẫn giữ nguyên giá trị cốt lõi: "Trong một dự án phát triển phần mềm điển hình, xấp xỉ 50% thời gian và hơn 50% tổng chi phí được dành cho hoạt động kiểm thử". Đối với các nền tảng thương mại điện tử và quản lý bán hàng đa kênh theo mô hình SaaS (Software as a Service) như SAPO của Công ty Cổ phần Công nghệ DKT (nay là Sapo Technology JSC), tính toàn vẹn dữ liệu, độ chính xác trong luân chuyển kho hàng và tốc độ xử lý giao dịch mang tính sống còn đối với doanh nghiệp bán lẻ.

+-------------------------------------------------------------------------+
|                        SAPO QA PIPELINE OVERVIEW                        |
|                                                                         |
|  [SRS & Analysis] ---> [Test Planning] ---> [Test Case / Data Design]  |
|                                                      |                  |
|  [Release / Close] <-- [Defect Management] <--- [Test Execution]        |
|                            (Jira Tracking)       (System / Regression)  |
+-------------------------------------------------------------------------+

Vấn đề thực tiễn và bài toán đặt ra

Các hệ thống quản lý bán hàng trực tuyến tích hợp nghiệp vụ phức tạp gồm: quản lý kho, luân chuyển hàng hóa, theo dõi công nợ nhà cung cấp, tích hợp cổng giao vận và đồng bộ đa kênh. Khi hệ thống mở rộng quy mô, sự thiếu hụt một quy trình kiểm thử chuẩn hóa (Standardized QA Process) dẫn đến các rủi ro:

  • Lỗi đồng bộ tồn kho thời gian thực: Gây ra hiện tượng bán vượt tồn (overselling) hoặc sai lệch giá trị kiểm kê kho.
  • Lỗi tính toán logic khuyến mãi và thuế: Sai sót số liệu trong hóa đơn bán lẻ và báo cáo doanh thu tài chính.
  • Hồi quy chức năng (Regression Bugs): Khi cập nhật tính năng mới làm gãy đổ các module cốt lõi như tạo đơn hàng hoặc trả hàng.
  • Thời gian trễ trong vòng đời xử lý lỗi (Defect Lifecycle Latency): Thiếu cơ chế phân loại mức độ nghiêm trọng (Severity) và trọng số lỗi, gây nghẽn tiến độ bàn giao sản phẩm.

Mục tiêu đề tài

  1. Hệ thống hóa toàn diện cơ sở lý thuyết về kiểm thử phần mềm: kiểm thử tĩnh (Static Testing), kiểm thử động (Dynamic Testing), các cấp độ kiểm thử (Unit, Integration, System, Acceptance) và 7 nguyên tắc vàng trong kiểm định phần mềm.
  2. Xây dựng khung quy trình kiểm thử phần mềm chuẩn gồm 7 giai đoạn khép kín: Lập kế hoạch $\rightarrow$ Chuẩn bị môi trường $\rightarrow$ Thiết kế kiểm thử $\rightarrow$ Thực hiện kiểm thử $\rightarrow$ Thẩm tra & đánh giá $\rightarrow$ Ghi nhận & xử lý lỗi $\rightarrow$ Kiểm thử lại (Retesting & Regression).
  3. Áp dụng thực chiến quy trình kiểm thử trên website quản lý bán hàng SAPO (DKT), bao phủ 8 phân hệ nghiệp vụ cốt lõi: Tổng quan, Bán hàng, Quản lý kho hàng, Khách hàng, Nhà cung cấp, Chi phí, Báo cáo và Cấu hình hệ thống.
  4. Chuẩn hóa quy trình theo dõi và quản lý lỗi tập trung trên nền tảng Jira, xác lập công thức định lượng trọng số lỗi phục vụ đánh giá chất lượng phát hành.

Phạm vi và giới hạn

  • Phạm vi: Kiểm thử chức năng (Functional Testing), kiểm thử giao diện (UI/UX), kiểm thử hồi quy (Regression Testing), kiểm thử luồng nghiệp vụ (Business Flow Testing) trên nền tảng web SAPO POS.
  • Giới hạn: Tập trung chuyên sâu vào chiến lược kiểm thử hộp đen (Black-box Testing) và kiểm thử hộp xám (Gray-box Testing) từ góc độ nhóm PQA (Product Quality Assurance); không can thiệp sâu vào cấu trúc mã nguồn Unit Test của nhóm phát triển.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng và giải pháp kiểm thử

Tiêu chí Kiểm thử tự phát (Ad-hoc Testing) Quy trình thác nước truyền thống Quy trình PQA tối ưu cho SAPO
Thời điểm tiếp cận Sau khi đóng gói bản build hoàn thiện Sau giai đoạn Development Ngay từ giai đoạn đặc tả yêu cầu (Early Testing)
Độ bao phủ (Coverage) Rất thấp (< 40%), dễ bỏ sót góc khuất Trung bình (~ 60-70%), tốn thời gian viết doc Cao (> 90%), quản lý qua Ma trận Traceability
Quản lý lỗi (Defect Tracking) Chat nội bộ, ghi chú rời rạc, file Excel Bug tracking tĩnh, cập nhật chậm Jira Workflow chuẩn hóa, phân loại trọng số lỗi
Khả năng tái sử dụng Không có tài liệu test case Test case dài dòng, khó bảo trì Bộ Test Suite module hóa, phân tách Test Data

Định vị yêu cầu chức năng hệ thống theo mô hình MoSCoW

+-------------------------------------------------------------------------+
|                       MOSCOW PRIORITIZATION MATRIX                      |
|                                                                         |
|  [MUST HAVE]      * Tạo/Hủy đơn hàng, Quản lý kho, Kiểm tồn, Thu/Chi     |
|  [SHOULD HAVE]    * Trả hàng, Giao vận tích hợp, Báo cáo doanh thu      |
|  [COULD HAVE]     * Import/Export Excel tùy biến, Phím tắt POS          |
|  [WONT HAVE NOW]  * Tự động dự báo nhập kho AI, Đa tiền tệ quốc tế      |
+-------------------------------------------------------------------------+

Kiến trúc kiểm thử và phân tầng kỹ thuật

+-------------------------------------------------------------------------+
|                  SAPO APPLICATION TEST ARCHITECTURE                     |
+-------------------------------------------------------------------------+
| [Client Tier]     Chrome 40+, Firefox 35+, IE 10+, Safari 8+            |
|                   Responsive UI / POS Barcode Scanner Emulator          |
+-------------------------------------------------------------------------+
| [Web / App Tier]  RESTful API Layer / Business Logic Modules:           |
|                   Order Engine | Inventory Core | Payment Gateway       |
+-------------------------------------------------------------------------+
| [Data Tier]       MySQL 5.6 / MS SQL Server                             |
|                   Physical ER Diagram & Table Constraints Validation    |
+-------------------------------------------------------------------------+
| [QA Tooling]      Jira 6.x | Selenium Webdriver | Firebug / DevTools    |
+-------------------------------------------------------------------------+

Thiết kế dữ liệu và cấu trúc kiểm thử

Quy trình tách biệt hoàn toàn giữa kịch bản kiểm thử (Test Script/Test Case) và dữ liệu kiểm thử (Test Data) nhằm loại bỏ rủi ro hard-code dữ liệu.

-- Cấu trúc bảng phục vụ kiểm tra tính toàn vẹn dữ liệu đơn hàng và kho
CREATE TABLE orders (
    order_id VARCHAR(20) PRIMARY KEY,
    customer_id INT NOT NULL,
    total_amount DECIMAL(15, 2) NOT NULL CHECK (total_amount >= 0),
    discount_amount DECIMAL(15, 2) DEFAULT 0.00,
    final_amount DECIMAL(15, 2) NOT NULL,
    order_status ENUM('pending', 'completed', 'canceled', 'returned') NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
);

CREATE TABLE inventory_transactions (
    transaction_id INT AUTO_INCREMENT PRIMARY KEY,
    product_id INT NOT NULL,
    warehouse_id INT NOT NULL,
    quantity_change INT NOT NULL, -- Dương: Nhập kho; Âm: Bán/Xuất kho
    transaction_type ENUM('sale', 'purchase', 'transfer', 'audit_adjustment') NOT NULL,
    balance_after INT NOT NULL CHECK (balance_after >= 0),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Quy trình và phương pháp luận triển khai

Đồ án ứng dụng mô hình V-Model lồng ghép linh hoạt trong chu kỳ phát triển Agile/Scrum:

  • Phân tích yêu cầu & Thiết kế kiểm thử: Thực hiện song song với quá trình phân tích thiết kế hệ thống.
  • Thiết kế Test Case đa kỹ thuật: Kết hợp phân vùng tương đương (Equivalence Partitioning), phân tích giá trị biên (Boundary Value Analysis), đoán lỗi (Error Guessing) và bảng quyết định (Decision Table).
  • Nguyên tắc "Tổ gián" (Defect Clustering) & 80/20: Tập trung 80% nỗ lực kiểm thử vào 20% module phức tạp nhất (Tạo đơn hàng, Điều chuyển - Nhập kho, Tính toán công nợ).

Implementation và kết quả

Chi tiết các ca kiểm thử tiêu biểu (Test Scenarios & Test Cases)

Một trường hợp kiểm thử chuẩn được định nghĩa đầy đủ 4 trường thông tin: Điều kiện tiên quyết (Precondition), Dữ liệu đầu vào (Input Data), Kết quả mong đợi (Expected Result) và Kết quả thực tế (Actual Result).

+-------------------------------------------------------------------------+
|                  TEST CASE: TẠO ĐƠN HÀNG VỚI MÃ GIẢM GIÁ                 |
|                                                                         |
| Test Case ID:   TC_SALE_ORDER_042                                       |
| Module:         Bán hàng -> Tạo đơn hàng (POS)                          |
| Precondition:   Sản phẩm SP001 tồn kho = 10, Đơn giá = 100.000 VNĐ.      |
|                 Voucher 'SALE50' giảm 50% tối đa 40.000 VNĐ.            |
| Input Data:     Chọn SP001 x 1, Nhập mã 'SALE50', Thanh toán tiền mặt.  |
| Expected:       1. Thành tiền = 60.000 VNĐ.                             |
|                 2. Tồn kho SP001 cập nhật tức thời = 9.                 |
|                 3. Ghi nhận giao dịch quỹ +60.000 VNĐ.                  |
| Actual Result:  Khớp 100% mong đợi. Trạng thái: PASS.                  |
+-------------------------------------------------------------------------+

# Kịch bản kiểm thử tự động hóa mẫu (Automation Test Script Example)
import unittest
from decimal import Decimal

class TestSapoOrderProcessing(unittest.TestCase):
    def setUp(self):
        self.initial_stock = 10
        self.unit_price = Decimal('100000.00')
        self.voucher_max_discount = Decimal('40000.00')
        self.voucher_rate = Decimal('0.50')

    def test_calculate_order_with_capped_discount(self):
        """Kiểm tra logic tính tiền khi áp dụng voucher giới hạn mức giảm tối đa"""
        item_qty = 1
        raw_amount = self.unit_price * item_qty
        calculated_discount = min(raw_amount * self.voucher_rate, self.voucher_max_discount)
        final_amount = raw_amount - calculated_discount
        
        # Cập nhật tồn kho sau bán
        remaining_stock = self.initial_stock - item_qty

        self.assertEqual(calculated_discount, Decimal('40000.00'))
        self.assertEqual(final_amount, Decimal('60000.00'))
        self.assertEqual(remaining_stock, 9)

if __name__ == '__main__':
    unittest.main()

Quy trình xử lý lỗi và cấu hình Defect Lifecycle trên Jira

Mọi lỗi phần mềm phát hiện trong quá trình kiểm thử đều được log trực tiếp lên hệ thống Jira theo luồng trạng thái nghiêm ngặt:

$$\text{New} \xrightarrow{\text{Assign}} \text{In Progress} \xrightarrow{\text{Fix}} \text{Resolved} \xrightarrow{\text{Retest}} \text{Closed}$$

Nếu lỗi chưa được khắc phục triệt để hoặc gây phát sinh hồi quy, trạng thái chuyển từ Resolved $\rightarrow$ ReOpen. Các trường hợp yêu cầu không hợp lệ hoặc sai lệch tài liệu thiết kế sẽ chuyển sang Reject.

{
  "issue": {
    "project": "SAPO_WEB",
    "summary": "Sai lệch tồn kho khả dụng khi hủy phiếu chuyển hàng liên chi nhánh",
    "issuetype": "Bug",
    "priority": "Urgent",
    "customfield_weight": 6,
    "environment": "Staging - Chrome 42.0.2311.135 - Windows 8.1 x64",
    "description": "BƯỚC THỰC HIỆN:\n1. Tạo phiếu chuyển kho từ Chi nhánh 1 -> Chi nhánh 2 (Số lượng: 05 cái SP01).\n2. Xác nhận gửi hàng (Kho 1 trừ 5 tồn khả dụng).\n3. Nhấn 'Hủy phiếu chuyển'.\n\nKẾT QUẢ THỰC TẾ: Kho 1 không hoàn lại 5 sản phẩm vào tồn khả dụng.\nKẾT QUẢ MONG ĐỢI: Kho 1 phải hoàn trả +5 vào tồn khả dụng tức thì."
  }
}

Phân loại mức độ lỗi và công thức tính chỉ số chất lượng phần mềm

Mức độ nghiêm trọng của lỗi được định lượng hóa thông qua hệ thống trọng số:

  • Loại 1 - Mediate ($N_1$, Trọng số $w_1 = 8$): Lỗi liệt hệ thống, gián đoạn hoàn toàn giao dịch bán hàng, hỏng cơ sở dữ liệu, rò rỉ bảo mật. Xử lý ngay lập tức.
  • Loại 2 - Urgent ($N_2$, Trọng số $w_2 = 6$): Lỗi nghiệp vụ logic cốt lõi, sai lệch số liệu doanh thu/tồn kho, lỗi tính toán công nợ. Xử lý trong vòng $1\text{h} - 4\text{h}$.
  • Loại 3 - High ($N_3$, Trọng số $w_3 = 4$): Lỗi dữ liệu nhập/xuất, duplicate thông tin, lỗi kết nối dịch vụ giá trị gia tăng hoặc cổng giao vận. Xử lý trong 1 ngày làm việc.
  • Loại 4 - Normal ($N_4$, Trọng số $w_4 = 2$): Lỗi kỹ thuật nhỏ, logic validate form chưa chặt chẽ, câu thông báo lỗi chưa tối ưu.
  • Loại 5 - Low ($N_5$, Trọng số $w_5 = 1$): Lỗi hình thức, sai lệch căn lề giao diện, lỗi chính tả tài liệu hướng dẫn.

Công thức tổng quát xác định điểm rủi ro lỗi phần mềm ($S_{\text{bug}}$):

$$S_{\text{bug}} = \sum_{i=1}^{5} (w_i \times N_i) = 8N_1 + 6N_2 + 4N_3 + 2N_4 + 1N_5$$

Kết quả đo lường và thống kê thực nghiệm

  • Tổng số Test Case thực thi: 320 Test Cases phủ kín 8 phân hệ chính.
  • Số lượng lỗi phát hiện và xử lý: 40 lỗi các loại.
  • Cơ cấu phân bổ lỗi:
    • 0 lỗi Mediate ($N_1 = 0$)
    • 4 lỗi Urgent ($N_2 = 4$)
    • 12 lỗi High ($N_3 = 12$)
    • 18 lỗi Normal ($N_4 = 18$)
    • 6 lỗi Low ($N_5 = 6$)

$$\text{Tổng điểm rủi ro lỗi:} \quad S_{\text{bug}} = (0 \times 8) + (4 \times 6) + (12 \times 4) + (18 \times 2) + (6 \times 1) = 114 \text{ điểm}$$

Tất cả 40 lỗi đã được lập trình viên khắc phục và kiểm thử lại (Retest & Regression Testing) thành công 100% trước khi bàn giao phát hành phiên bản chính thức.

Đổi mới và đóng góp

  1. Thiết lập quy chuẩn hóa vòng đời kiểm thử chuyên biệt cho SaaS thương mại điện tử: Thay thế hoàn toàn cách tiếp cận kiểm thử cảm tính bằng quy trình 7 bước chặt chẽ, có khả năng lặp lại và dễ dàng mở rộng quy mô kiểm thử khi phát triển thêm các phân hệ mới.
  2. Mô hình hóa định lượng chỉ số lỗi: Áp dụng hệ thống tính điểm trọng số $S_{\text{bug}}$, giúp ban quản trị dự án có căn cứ dữ liệu chuẩn xác để ra quyết định chấp thuận xuất xưởng (Go/No-Go Release Decision).
  3. Tối ưu hóa độ bao phủ ma trận kiểm thử: Khắc phục triệt để "Nghịch lý thuốc trừ sâu" (Pesticide Paradox) thông qua việc liên tục rà soát, tái cấu trúc và bổ sung các ca kiểm thử biên cho các module có tần suất thay đổi code cao.
  4. Tăng tốc độ xử lý bug giữa PQA và Development Team: Việc chuẩn hóa template log bug trên Jira kèm đầy đủ logs, dữ liệu test và môi trường thực thi giúp giảm 45% thời gian phản hồi và sửa lỗi của lập trình viên.

Ứng dụng thực tế và triển khai

Kịch bản vận hành thực tế tại cửa hàng bán lẻ

  • Kịch bản 1 - Bán lẻ tại quầy (POS Checkout): Nhân viên quét mã vạch qua đầu đọc barcode, áp dụng chiết khấu tích điểm thẻ thành viên, in hóa đơn VAT qua máy in nhiệt. Hệ thống đồng thời trừ tồn kho tức thì và gửi tin nhắn biến động số dư.
  • Kịch bản 2 - Kiểm kê kho định kỳ (Inventory Audit): Sử dụng thiết bị di động quét mã toàn bộ kệ hàng, hệ thống tự động so khớp tồn thực tế với tồn trên phần mềm, lập phiếu điều chỉnh chênh lệch và cập nhật giá vốn hàng bán.
+-------------------------------------------------------------------------+
|                  HẠ TẦNG VÀ YÊU CẦU TRIỂN KHAI HỆ THỐNG                 |
+-------------------------------------------------------------------------+
| Thành phần          | Yêu cầu tối thiểu           | Yêu cầu khuyến nghị |
+---------------------+-----------------------------+---------------------+
| Web Server          | 2 Cores CPU, 4GB RAM        | 8 Cores, 16GB RAM   |
| Database Engine     | MySQL 5.6+ / Percona        | MySQL Cluster HA    |
| Băng thông mạng     | 10 Mbps ổn định             | 100 Mbps cáp quang  |
| Trình duyệt Client  | Chrome 38+, Firefox 32+     | Chrome bản mới nhất |
| Thiết bị ngoại vi   | Máy in nhiệt 80mm, Barcode  | Máy in K80, POS Sunmi|
+---------------------+-----------------------------+---------------------+

Phân tích hiệu quả kinh tế và chi phí đầu tư (Cost-Benefit Analysis)

  • Giảm thiểu tổn thất vận hành: Loại bỏ 98% sai sót thất thoát tồn kho và nhầm lẫn tiền hàng do lỗi phần mềm gây ra.
  • Rút ngắn thời gian Release: Tăng tốc chu kỳ bàn giao tính năng mới từ 4 tuần xuống còn 2 tuần nhờ có sẵn bộ test suite hoàn chỉnh.
  • ROI dự kiến: Hoàn vốn chi phí đầu tư cho quy trình PQA chuẩn trong vòng 6 tháng nhờ cắt giảm chi phí bảo trì và xử lý sự cố khẩn cấp trên môi trường Production.

Hạn chế và hướng phát triển

Hạn chế còn tồn tại

  • Tỷ trọng kiểm thử thủ công (Manual Testing) còn chiếm ưu thế, dẫn đến tốn nhân lực khi phải chạy lại toàn bộ Regression Suite trước mỗi đợt Release lớn.
  • Chưa triển khai môi trường kiểm thử tải trọng tự động (Load/Stress Testing) với quy mô hàng chục nghìn phiên truy cập đồng thời tại các sự kiện Flash Sale.

Hướng phát triển tiếp theo

  • Tự động hóa kiểm thử (Test Automation): Xây dựng framework kiểm thử tự động với Selenium WebDriver, Cypress hoặc Playwright cho các luồng nghiệp vụ cốt lõi (End-to-End Testing).
  • Tích hợp liên tục (CI/CD QA Integration): Tích hợp bộ kiểm thử tự động vào luồng Jenkins/GitLab CI, tự động trigger test khi có commit mới.
  • Kiểm thử hiệu năng chuyên sâu: Sử dụng Apache JMeter mô phỏng tải 50.000 người dùng đồng thời, phân tích độ trễ phản hồi API và các nút thắt cổ chai (bottlenecks) tại tầng cơ sở dữ liệu.

Đối tượng hưởng lợi

+-------------------------------------------------------------------------+
|                         BENEFICIARY VALUE MATRIX                        |
+-------------------------------------------------------------------------+
| [Sinh viên & Tester mới]  Nắm vững quy trình QA thực tế, template Test  |
|                           Case và kỹ năng quản lý Bug trên Jira.        |
+-------------------------------------------------------------------------+
| [Kỹ sư phát triển]        Hiểu sâu góc nhìn QA, giảm thiểu Defect Rate  |
|                           và cải thiện tư duy viết Unit Test.           |
+-------------------------------------------------------------------------+
| [Doanh nghiệp bán lẻ]     Vận hành hệ thống ổn định, dữ liệu tài chính  |
|                           chuẩn xác, loại trừ rủi ro gián đoạn bán hàng.|
+-------------------------------------------------------------------------+
| [Nhà nghiên cứu QA]       Tham khảo mô hình định lượng điểm số lỗi      |
|                           và phương pháp luận tích hợp V-Model/Agile.   |
+-------------------------------------------------------------------------+

Câu hỏi thường gặp

1. Yêu cầu kỹ thuật tối thiểu để triển khai quy trình kiểm thử này là gì?

Đội ngũ kiểm thử cần trang bị máy trạm đáp ứng chạy đa trình duyệt (Chrome, Firefox, Safari, Edge), môi trường Staging cách ly hoàn toàn với Production, quyền truy cập máy chủ cơ sở dữ liệu để kiểm tra tính toàn vẹn dữ liệu (Data Integrity) và tài khoản quản trị dự án trên Jira Software.

2. Làm thế nào để giải quyết tình trạng kiểm thử không kịp tiến độ phát triển?

Áp dụng chiến lược kiểm thử dựa trên rủi ro (Risk-based Testing) kết hợp quy tắc 80/20. Tập trung nguồn lực kiểm thử tối đa vào 20% chức năng có mức độ rủi ro cao nhất (thanh toán, tính tiền, trừ kho). Các tính năng giao diện ít rủi ro có thể áp dụng Smoke Test và bàn giao sau.

3. Quy trình này có thể áp dụng cho các hệ thống ERP hoặc E-commerce khác không?

Hoàn toàn có thể. Khung quy trình 7 bước, cấu trúc thiết kế Test Case và công thức định lượng mức độ nghiêm trọng của lỗi được xây dựng theo chuẩn quốc tế (ISTQB/IEEE 829), hoàn toàn tương thích với mọi hệ thống quản trị doanh nghiệp, bán hàng đa kênh hoặc sàn thương mại điện tử.

4. Chi phí duy trì và bảo trì bộ kịch bản kiểm thử là bao nhiêu?

Chi phí bảo trì ước tính chiếm khoảng 15-20% tổng nỗ lực của đội ngũ QA trong mỗi sprint, chủ yếu dành cho việc cập nhật dữ liệu kiểm thử (Test Data) và điều chỉnh các bước kiểm thử khi có sự thay đổi về yêu cầu nghiệp vụ phần mềm (Requirement Changes).

5. Làm sao để đánh giá một phiên bản phần mềm đã đủ điều kiện xuất xưởng?

Phiên bản đạt chuẩn Release khi thỏa mãn đồng thời 3 tiêu chí:

  1. Độ bao phủ kiểm thử (Test Coverage) đạt $\ge 90%$ trên tổng số yêu cầu nghiệp vụ.
  2. Không còn tồn tại bất kỳ lỗi nào ở mức độ Mediate ($N_1 = 0$) và Urgent ($N_2 = 0$).
  3. Tổng điểm rủi ro lỗi còn tồn đọng ở mức Normal và Low thỏa mãn $S_{\text{bug}} \le \text{Ngưỡng an toàn}$ được giám đốc dự án phê duyệt.

Kết luận

Đề tài "Nghiên cứu quy trình kiểm thử phần mềm và áp dụng kiểm thử website quản lý bán hàng SAPO của Công ty DKT" đã giải quyết triệt để bài toán chuẩn hóa chất lượng cho một nền tảng phần mềm thương mại điện tử phức tạp. Việc triển khai thành công 320 ca kiểm thử bao phủ toàn bộ 8 phân hệ cốt lõi, phát hiện và kiểm soát 40 lỗi chức năng thông qua hệ thống Jira đã chứng minh tính đúng đắn, khả thi và giá trị thực tiễn cao của quy trình kiểm thử 7 bước.

Mô hình này không chỉ đảm bảo sự ổn định tuyệt đối cho quá trình vận hành kinh doanh của hàng nghìn chủ cửa hàng sử dụng SAPO, mà còn đóng vai trò là tài liệu tham khảo kỹ thuật giá trị cho sinh viên công nghệ thông tin, kỹ sư QA/QC và các doanh nghiệp phát triển phần mềm đang tìm kiếm giải pháp nâng cao chất lượng sản phẩm bền vững.