NHỮNG KHÁI NIỆM DỄ NHẦM LẪN VỚI NHAU TRONG KIỂM THỬ PHẦN MỀM

January 2025
M	T	W	T	F	S	S
	1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

I. PHÂN BIỆT QUALITY ASSURANCE – QUALITY CONTROL – TESTER

Không khó để bắt gặp những bài viết như bên dưới trên các trang mạng xã hội. Nhưng khi nhìn vào các bài viết này thì chúng ta sẽ tự đặt ra câu hỏi là:

Liệu nhà tuyển dụng có đang hiểu sai về 3 vị trí trên hay không?

Hay liệu với cương vị là 1 Tester liệu chúng ta có thể apply vào vị trí QA/QC hay không?

Thì phần tiếp theo của e sẽ có thể giúp mọi người hình dung rõ hơn được công việc, nhiệm vụ, vai trò của 3 vị trí QA, QC và Tester

Trước hết, chúng ta sẽ cùng nhau đi qua các khái niệm cơ bản của 3 vị trí này nhé:

Thông thường, nhiệm vụ của Đảm bảo chất lượng sẽ bao gồm các công việc như:

Một số nhiệm vụ chủ yếu của bộ phận QC là

Trong thực tế thì việc QC có kiểm tra tốt tới đâu hay quy trình QA chặt chẽ như thế nào thì lỗi vẫn còn đâu đó trong sản phẩm.

Nhìn chung, có thể hình dung Tester là tập con của QC, và QC lại là tập con của QA.

Mục tiêu chính của QA là Prevention (Ngăn ngừa lỗi), trong khi đó mục tiêu chính của QC và Tester là Detection (Phát hiện lỗi).

Cả 3 bộ phận này đều là những thành phần vô cùng quan trọng trong quá trình sản xuất phần mềm nói chung và công đoạn kiểm thử phần mềm nói riêng.

Sẽ càng thấy rõ được sự khác nhau của mỗi vị trí khi trong cùng 1 công ty tồn tại cả 3 vị trí này. Khi đó mỗi vị trí sẽ được định nghĩa, liệt kê các vai trò và trách nhiệm một cách cụ thể và rõ ràng

II. PHÂN BIỆT ERROR – FAULT – FAILURE

Trong quá trình phát triển phần mềm chúng ta không thể tránh khỏi thứ được gọi là “LỖI PHẦN MỀM”. Nhắc đến đây mọi người có thể hình dung ra được lỗi phần mềm là các lỗi liên quan đến logic, chức năng của phần mềm hay đơn giản là lỗi giao diện. Cùng được gọi là lỗi nhưng sẽ có lỗi this, lỗi that. Vì vậy hôm nay mình sẽ giúp các bạn phân loại rõ hơn các “Lỗi” này nhé.

Đầu tiên chúng ta sẽ tìm hiểu về “Error”, hoặc có cách gọi khác là “Mistake”

Theo glossary ISTQB. “Error” được định nghĩa là

Error: A human action that produces an incorrect result.

Chúng ta có thể hiểu đơn giản đó là các hành động của con người dẫn đến kết quả bị sai.

Để dễ hiểu hơn chúng ta có thể đi vào một số ví dụ sau:

Trong quá trình làm việc, lập trình viên chủ quan đọc requirement không kỹ dẫn đến làm thiếu yêu cầu của đề bài
Developer quá áp lực về thời gian nên làm sai
BA chỉnh sửa tài liệu đặc tả yêu cầu mà quên thông báo với đội phát triển
Dev/ BA/ Tester không được đào tạo về quy trình làm việc của team nên xảy ra lỗi khi làm việc
Lập trình viên thiếu kinh nghiệm trong lĩnh vực đang phát triển

Tiếp theo, mình sẽ giúp các bạn hiểu rõ hơn về “Defect”. “Defect” hay còn có cách gọi khác là “Bug”/ “Fault”

Theo tài liệu tra cứu từ Glossary ISTQB,

Defect: An imperfection or deficiency in a work product where it does not meet its requirements or specifications or impairs its intended use.

Chúng ta có thể hiểu là Fault/ Defect/ Bug là một khiếm khuyết trong một thành phần hoặc hệ thống mà nó có thể làm cho thành phần hoặc hệ thống này không thực hiện đúng chức năng yêu cầu của nó

Ví dụ:

Trong quá trình làm việc, lập trình viên cần phải lấy data từ bảng A để hiển thị lên màn hình. Nhưng do hiểu sai tính logic của tài liệu, nên Lập trình viên đã lấy dữ liệu từ bảng B để hiển thị ra ngoài. Điều này đã dẫn đến lỗi hiển thị sai dữ liệu
Chức năng Đăng nhập, nhập password cũ nhưng vẫn cho phép login thành công
Chức năng Chỉnh sửa form, Hệ thống trả về thông báo thành công nhưng không insert dữ liệu mới thay thế dữ liệu cũ

Cuối cùng, chúng ta cùng nhau tìm hiểu về “Failure”.

Theo định nghĩa tra cứu từ ISTQB,

Failure: An event in which a component or system does not meet its requirements within specified limits

Hiểu đơn giản failure là lỗi khi có kết quả sai lệch so với yêu cầu đặc tả, là sự khác biệt giữa kết quả thực tế hiển thị trên màn hình và kết quả mong đợi của một thành phần, hệ thống hoặc dịch vụ nào đó.

Để hiểu rõ hơn về Failure chúng ta cùng đi nhanh qua ví dụ bên dưới

Hệ thống SSP mong muốn cho phép team vận hành có thể xem báo cáo tối đa 90 ngày. Nhưng khi filter khoảng 60 ngày hệ thống load mãi ko ngừng và trả ra thông báo lỗi

Hay một ví dụ khác, khách hàng yêu cầu server hoạt động tốt, trôi chảy khi đồng thời có 1000 người dùng truy cập cùng lúc. Nhưng thực tế , khi khoảng 600 người dùng cùng sử dụng phần mềm tại một thời điểm. Hệ thống bị quá tải và không cho người dùng sử dụng các chức năng của phần mềm

Nhưng không phải tất cả các “Failure” đều do bug/ defect/ fault tạo ra. Bên cạnh đó, do một số lý do như người dùng thực hiện sai hướng dẫn, kiểm thử sai môi trường/ cấu hình cũng là nguyên nhân tạo ra “Failure”

Tóm lại con người hành động sẽ tạo ra các error/ mistake. Dẫn đến sẽ xuất hiện defect/ bug/ fault trong code/ tài liệu. Khi chạy chương trình thì chúng ta sẽ bắt gặp Failure

III. PHÂN BIỆT TESTING VÀ DEBUGGING

Testing và Debugging là 2 công đoạn cần thiết để đảm bảo chất lượng phần mềm. Bảng dưới đây là một số điểm khác biệt cốt lõi của Testing và Debugging.

IV. PHÂN BIỆT TEST PLAN VÀ TEST STRATEGY

Ví dụ:

Module A sẽ được thực hiện kiểm thử bởi C HuongNTT2. Nhưng lý do bất khả kháng nào đó, ví dụ như Hường bận đi du lịch, ốm đột xuất thì task đó sẽ giao lại cho 1 thành viên trong team, QuỳnhNTN → Test Plan phải được cập nhật.
Ngược lại, một Test Strategy sẽ có các chi tiết như : Các module riêng lẻ sẽ được kiểm thử bởi các thành viên trong nhóm tester. Trong trường hợp này, không quan trọng ai đang thử nghiệm nó. Vì vậy, nó chung chung và sự thay đổi trong thành viên nhóm không nhất thiết phải cập nhật.

V. PHÂN BIỆT TEST SCENARIO VÀ TEST CONDITION

Ví dụ: Chức năng Quản lý phiên live

Các Test Scenario:

Brand có thể thêm phiên live mới
Phiên live có thể bị hủy lịch bởi Brand/ Agency
Phiên live có thể được chỉnh sửa thông tin bởi Brand/ Agency

Test Condition cụ thể hơn. Nó có thể được định nghĩa đại khái là mục tiêu / mục tiêu của một bài kiểm tra nhất định.

Ví dụ Test Condition:

Trong ví dụ trên, nếu chúng ta kiểm tra kịch bản 1, chúng ta có thể kiểm tra các điều kiện sau:

Chỉ nhập các trường required với giá trị hợp lệ và kiểm tra bổ sung phiên live sau khi Thêm mới thành công
Nhập tất cả các trường với giá trị hợp lệ và kiểm tra bổ sung phiên live sau khi Thêm mới thành công
Nhập các giá trị không hợp lệ và kiểm tra thông báo lỗi tương ứng

VI. PHÂN BIỆT TEST PROCEDURE VÀ TEST SUITE

Là Admin, tôi muốn gửi thông báo nhắc nhở tới các Creator trên hệ thống SSP. Thứ tự các trường hợp kiểm thử được kết hợp để tạo thành một quy trình kiểm thử sẽ là: