Nếu bạn từng nghe đồng nghiệp trong nhóm phát triển tranh luận về QA và QC mà không hiểu rõ khác nhau ra sao, bài viết này chính là để giải thích thuật ngữ công nghệ, lập trình, DevOps, phần mềm theo cách dễ hình dung nhất. Chúng tôi làm việc với khá nhiều đội ngũ phát triển phần mềm và nhận thấy đây là một trong những câu hỏi được hỏi đi hỏi lại nhiều nhất, kể cả với người đã đi làm vài năm trong ngành.
Nói cho dễ hiểu, QA và QC không phải hai cái tên khác nhau của cùng một công việc, dù nhiều người vẫn hay nhầm lẫn như vậy. Chúng tôi sẽ đi từng phần một, từ định nghĩa cơ bản đến cách áp dụng thực tế trong một dự án phần mềm, để bạn có thể tự tin trao đổi với đội kỹ thuật của mình sau khi đọc xong.
QA là gì trong một dự án phần mềm
QA là viết tắt của Quality Assurance, tạm dịch là đảm bảo chất lượng. Đây là tập hợp các hoạt động diễn ra xuyên suốt quá trình phát triển phần mềm. QA không chỉ xuất hiện ở giai đoạn cuối trước khi ra mắt sản phẩm, mà có mặt ngay từ lúc lên kế hoạch.
Vai trò chính của người làm QA là xây dựng quy trình. Họ đặt ra tiêu chuẩn viết code, quy định cách review, cách kiểm thử, cách bàn giao giữa các nhóm với nhau. QA quan tâm đến việc làm đúng cách ngay từ đầu. Mục tiêu là hạn chế lỗi phát sinh, thay vì chỉ đi tìm lỗi sau khi sản phẩm đã hoàn thành.
Chúng tôi từng hỗ trợ một dự án website thương mại điện tử có tình trạng khá điển hình. Nhóm lập trình viết code rất nhanh nhưng không ai kiểm soát quy trình chung. Mỗi bản cập nhật lại phát sinh lỗi mới ở phần thanh toán, khiến khách hàng phàn nàn liên tục. Sau khi bên mình đề xuất thêm một vị trí QA để chuẩn hoá quy trình review code và test trước khi merge, số lỗi phát sinh giảm rõ rệt chỉ sau vài tháng.
QC khác QA ở điểm nào
QC là viết tắt của Quality Control, nghĩa là kiểm soát chất lượng. Nếu QA lo về quy trình thì QC lo về sản phẩm cụ thể. Người làm QC trực tiếp kiểm thử phần mềm, tìm lỗi, báo cáo lỗi và xác nhận lỗi đã được sửa đúng hay chưa trước khi phát hành.
Có thể hình dung đơn giản thế này. QA giống như người xây dựng quy trình nấu ăn trong một nhà hàng. QC là người trực tiếp nếm từng món trước khi mang ra cho khách. Cả hai đều hướng đến một sản phẩm chất lượng, nhưng cách tiếp cận và thời điểm can thiệp hoàn toàn khác nhau.
Trong thực tế, một dự án phần mềm nhỏ đôi khi không tách bạch rõ hai vai trò này. Một người có thể vừa xây quy trình, vừa trực tiếp test sản phẩm. Nhưng khi đội ngũ phát triển lớn dần, việc phân tách QA và QC sẽ giúp công việc rõ ràng hơn. Tránh được tình trạng chồng chéo trách nhiệm giữa các thành viên.
Vì sao doanh nghiệp nhỏ cũng nên quan tâm đến QA, QC
Nhiều chủ doanh nghiệp nhỏ nghĩ rằng QA, QC chỉ dành cho các công ty phần mềm lớn. Chúng tôi cho rằng suy nghĩ này chưa đầy đủ. Ngay cả một website bán hàng đơn giản hay một ứng dụng nội bộ nhỏ cũng cần được kiểm tra kỹ trước khi đưa vào sử dụng. Lỗi phần mềm có thể ảnh hưởng trực tiếp đến doanh thu và uy tín của cả doanh nghiệp.
Nếu bạn đang tìm hiểu cách xây dựng một website chuẩn để vận hành lâu dài, có thể tham khảo thêm bài website chuẩn SEO cần đáp ứng những tiêu chí gì mà chúng tôi từng chia sẻ. Trong đó phần kiểm thử chất lượng trước khi ra mắt cũng được nhắc đến khá kỹ, khá liên quan đến chủ đề QA, QC hôm nay.
Với các đội ngũ đang triển khai DevOps, ranh giới giữa QA và QC càng cần được làm rõ hơn. Trong mô hình DevOps, việc kiểm thử được tích hợp liên tục vào từng bước phát triển thay vì để dồn đến cuối cùng. Nếu bạn chưa quen với khái niệm này, bên mình từng giải thích chi tiết trong bài DevOps là gì và vận hành ra sao trong đội ngũ phát triển. Đọc thêm để hiểu rõ QA, QC nằm ở đâu trong quy trình đó.
Case thực tế: khi thiếu QC, hậu quả lớn hơn bạn nghĩ
Chúng tôi từng hỗ trợ một khách hàng vận hành ứng dụng đặt lịch cho chuỗi spa. Vì muốn ra mắt gấp trước một chương trình khuyến mãi lớn, đội lập trình đã bỏ qua bước kiểm thử kỹ ở phần đặt lịch trùng giờ. Kết quả là nhiều khách hàng đặt trùng một khung giờ mà hệ thống không hề báo lỗi. Nhân viên tại chi nhánh phải xử lý thủ công suốt cả tuần liền, khá vất vả.
Sau sự cố đó, doanh nghiệp này quyết định thuê thêm nhân sự QC bán thời gian. Người này chỉ tập trung kiểm thử các luồng nghiệp vụ quan trọng trước mỗi lần cập nhật hệ thống. Chi phí bỏ ra không lớn, nhưng hiệu quả mang lại khá rõ rệt. Số lỗi nghiêm trọng giảm gần như hoàn toàn trong các đợt phát hành sau đó.
Câu chuyện này cho thấy QA và QC không phải là khoản chi phí phát sinh vô ích. Đây là khoản đầu tư giúp doanh nghiệp tránh những thiệt hại lớn hơn nhiều về sau, cả về tiền bạc lẫn uy tín với khách hàng của mình.
Kiểm thử thủ công và tự động: nên chọn cách nào
Đây cũng là một khái niệm hay bị gộp chung với QA, QC nên chúng tôi muốn nói rõ thêm. Kiểm thử thủ công là khi con người trực tiếp thao tác trên phần mềm để tìm lỗi, giống như cách QC vẫn thường làm ở các dự án nhỏ. Cách này linh hoạt, dễ phát hiện các lỗi liên quan đến trải nghiệm người dùng, nhưng lại tốn khá nhiều thời gian.
Kiểm thử tự động thì khác. Đội lập trình sẽ viết sẵn các đoạn script để hệ thống tự chạy kiểm tra mỗi khi có thay đổi code, không cần con người thao tác thủ công. Cách này phù hợp với các dự án phần mềm lớn, cập nhật liên tục, đặc biệt trong môi trường DevOps nơi tốc độ phát hành rất nhanh.
Với đội ngũ nhỏ, chúng tôi thường khuyên không cần vội đầu tư kiểm thử tự động ngay từ đầu. Hãy làm tốt kiểm thử thủ công có checklist rõ ràng trước, khi sản phẩm phức tạp dần lên thì mới tính đến việc tự động hoá để tiết kiệm thời gian và nhân lực.
Cách áp dụng QA, QC cho đội ngũ ít người
Không phải doanh nghiệp nào cũng đủ ngân sách để tuyển riêng một vị trí QA và một vị trí QC. Với các đội ngũ nhỏ, chúng tôi thường gợi ý cách làm gọn nhẹ hơn nhưng vẫn đảm bảo chất lượng cơ bản cho sản phẩm.
- Xây một checklist kiểm thử tối thiểu cho mỗi tính năng trước khi phát hành, để không phụ thuộc hoàn toàn vào trí nhớ của lập trình viên.
- Phân công luân phiên việc test chéo, người viết code A sẽ test tính năng của người viết code B, tránh tình trạng tự viết tự duyệt.
- Ưu tiên kiểm thử kỹ các luồng liên quan trực tiếp đến tiền bạc và dữ liệu khách hàng, vì đây là nơi lỗi gây thiệt hại nặng nhất nếu xảy ra.
Khi đội ngũ phát triển lớn dần, việc tách riêng vai trò QA và QC sẽ trở nên cần thiết hơn nhiều. Lúc đó, doanh nghiệp có thể cân nhắc hợp tác với các đơn vị phát triển phần mềm chuyên nghiệp để chuẩn hoá quy trình ngay từ đầu. Nếu bạn đang tìm đối tác phù hợp, có thể tham khảo thêm bài danh sách công ty thiết kế ứng dụng đáng cân nhắc mà bên mình đã tổng hợp trước đó.
Một vài thuật ngữ công nghệ liên quan bạn nên biết thêm
Ngoài QA và QC, có một số thuật ngữ khác trong lĩnh vực lập trình và phần mềm mà chúng tôi hay được hỏi thêm. Chẳng hạn, bug là lỗi phát sinh trong quá trình vận hành phần mềm. Test case là một kịch bản kiểm thử cụ thể được viết ra để kiểm tra một chức năng nhất định của hệ thống.
Regression testing là việc kiểm tra lại toàn bộ hệ thống sau khi có thay đổi, để đảm bảo tính năng cũ không bị ảnh hưởng bởi tính năng mới vừa thêm vào. Đây là công việc mà cả QA lẫn QC đều tham gia, nhưng ở mức độ và vai trò khác nhau trong quy trình chung.
Chúng tôi hiểu rằng với người mới tiếp xúc công nghệ, những thuật ngữ này đôi khi gây rối hơn là giúp ích. Vì vậy trên trang chủ designinterviews.com, chúng tôi vẫn thường xuyên cập nhật thêm các bài giải thích thuật ngữ công nghệ, lập trình, DevOps, phần mềm theo cách gần gũi nhất. Mục tiêu là để bạn không cần có nền tảng kỹ thuật vẫn hiểu được câu chuyện phía sau mỗi dự án.
Nhìn lại, QA và QC đều hướng đến một mục tiêu chung là chất lượng sản phẩm, chỉ khác nhau ở cách tiếp cận và thời điểm can thiệp vào dự án. QA xây quy trình để hạn chế lỗi ngay từ đầu, còn QC trực tiếp kiểm tra sản phẩm để phát hiện lỗi trước khi đến tay người dùng. Với đội ngũ nhỏ, bạn không nhất thiết phải tách bạch hai vai trò này ngay lập tức, nhưng nên có ý thức áp dụng cả hai tư duy trong suốt quá trình phát triển phần mềm.
Chúng tôi tin rằng hiểu đúng bản chất của QA, QC cũng như các thuật ngữ công nghệ liên quan sẽ giúp bạn trao đổi hiệu quả hơn với đội ngũ kỹ thuật của mình. Dù bạn là chủ doanh nghiệp, người làm marketing hay chỉ đơn giản đang tìm hiểu để chuyển hướng sự nghiệp sang lĩnh vực phần mềm, những kiến thức nền tảng này đều sẽ có ích về lâu dài.
