Kiểm thử phần mềm

1. 6 CÂU HỎI PHỎNG VẤN TESTER THÔNG DỤNG NĂM 2021
Câu hỏi phỏng vấn Testermở đầu
#1. Câu hỏi: Bạn hãy giới thiệu về bản thân
Ở câu hỏi này, bạn nên trả lời thật ngắn gọn về những thông cơ bản của mình.
Những thông tin này bao gồm: Họ và tên, trường Đại học và chuyên ngành đào tạo.
#2. Câu hỏi: Theo bạn, để trở thành một Testercầncó những tố chất gì? Bạn
có thể tự đánh giá bản thân đã đáp ứng được bao nhiêu phần trăm những
phẩm chất đó?
Ở câu hỏi này, bạn có thể trả lời theo những gợi ý sau: Tố chất cần có của một
Tester – nhân viên kiểm thử đó là phải chăm chỉ, cẩn thận và có trách nhiệm với
công việc được giao. Đồng thời phải trau dồi kỹ năng phân tích và xử lý những vấn
đề lập trình thành thạo nhất. Ngoài ra, Tester cần phải có tinh thần học hỏi, tiếp thu
cái mới và sẵn lòng làm thêm giờ khi được yêu cầu.
Phỏng vấn về kiếnthức chuyên môn
#3. Câu hỏi : Kiểm thử phần mềm là gì? Quy trình thực hiện các bước kiểm
thử phần mềm bao gồm những bước nào?
Ở câu hỏi này, bạn nên trả lời thật rõ ràng và chính xác những kiến thức đã học. Do
đó bạn có thể trả lời theo những gợi ý sau đây:
Kiểm thử phần mềm là quá trình kiểm tra và phát hiện lỗi của phần mềm. Kiểm thử
phần mềm giúp đảm bảo đáp ứng đầy đủ các tiêu chí, yêu cầu của khách hàng.
Đồng thời đánh giá và kiểm soát được những rủi ro có thể xảy ra trong quá trình
thực thi.
Nhân viên kiểm thử cần thực hiện công việc theo quy trình: chạy dự án theo yêu
cầu – thực hiện công việc chuẩn bị kiểm thử – tiến hành làm bài kiểm tra thử
nghiệm bằng các công cụ hỗ trợ – thực hiện công việc hậu kiểm thử để đảm bảo
chất lượng và tiêu chuẩn của sản phẩm – làm báo cáo kết quả.
#4. Câu hỏi: Có bao nhiêu giai đoạn để kiểm thử phần mềm? Những giai đoạn
đó là gì?
Ở câu hỏi này, bạn nên trả lời một cách rõ ràng và chính xác. Đây là câu hỏi liên
quan đến thức chuyên ngành nên bạn có thể trả lời như sau:

2. Có 4 giai đoạn kiểm thử phần mềm đó là: Unit Testing, Integration Testing,
System Testing và AcceptanceTesting.
#5. Câu hỏi: Có bao nhiêu phương pháp kiểm thử phần mềm?
Ở câu hỏi này bạn có thể trả lời có 2 phương pháp kiểm thử phần mềm bao gồm:
o Kiểm thử hộp trắng tiến hành kiểm tra mã code, thuật toán, cấu trúc chương trình.
o Kiểm thử hộp đen sẽ xây dựng các trường hợp Test theo yêu cầu khách hàng, đồng
thời đưa ra chức năng của hệ thống.
Câu hỏi phát sinh từ nhà tuyển dụng
#6. Câu hỏi: Nếu đã Testcẩn thận nhưng kháchhàng vẫn phàn nàn về chất
lượng thì xử lý thế nào?
Ở câu hỏi này bạn nên trả lời rằng: Công việc của Tester trước trường hợp khách
hàng không hài lòng về chất lượng đó là hỏi khách hàng có điều gì không hài lòng
và có nhu cầu thay đổiđiểm gì ở sản phẩm hay không.
7 CÂU HỎI PHỎNG VẤN CHO THỰC TẬP TESTER
Q1: Testcase là gì? Gồm những mục nào?
Trường hợp kiểm thử (test case) là bản trình bày những thông tin về việc kiểm thử
một hạng mục. Với test case, tester sẽ biết những bước tiến hành, thông số kiểm
thử của hạng mục được kiểm thử. Nhờ vậy, tester có thể đảm bảo chất lượng của
những hạng mục nhỏ và sản phẩm cuốicùng. Test case còngiúp các tester khác,
người quản lý biết hạng mục, trường hợp nào đã được kiểm thử.
Test case luôn có những mục chính như sau:
o Mã seri hoặc ID
o Mô tả
o Điều kiện tiên quyết
o Cách thực hiện
o Dữ liệu đầu vào
o Kết quả dự kiển
o Kết quả thực tế
o Đánh giá (Đạt/Không đạt)
o Ghi chú

3. Ngoài ra, test case còncó những mục như mức độ ưu tiên, từ khóa, đặc tả yêu
cầu,…
Q2: Testplan là gì? Làm sao để lập test plan?
Kế hoạch kiểm thử (test plan) là bản tổng quan chi tiết về quá trình kiểm thử. Test
plan mô tả mục tiêu, phạm vi, hướng tiếp cận, phân công nguồn lực và lịch trình
kiểm thử. Nó còn gồm những phần khác như hạng mục cần – không cần kiểm thử,
công cụ, kết quả,… Test plan là cơ sở để người quản lý đưa ra những quyết định về
việc kiểm thử. Ngoài ra, test plan còn giúp tester xác định tiêu chí cần thiết để xác
nhận chất lượng sản phẩm.
Theo tiêu chuẩn IEEE 829, cần phải thực hiện 7 bước sau để lập test plan:
o Phân tích sản phẩm
o Lập chiến lược kiểm thử (test strategy)
o Xác định mục tiêu kiểm thử (test objective)
o Xác định tiêu chí kiểm thử (test criteria)
o Hoạch định nguồn lực (nhân lực, phần cứng, tài liệu,…)
o Xác định môi trường kiểm thử (test environment)
o Lập lịch trình kiểm thử và Dự toán ngân sách
o Xác định kết quả kiểm thử (test deliverable)
Q3: Phân biệt White-box và Black-boxtest
Kiểm thử hộp trắng (White-box test):
o Là kiểm thử code, thuật toán (algorithm) và kiến trúc sản phẩm
o Test case được xây dựng dựa vào cấu trúc code, cáchthức vận hành code
o Tester phải am hiểu lập trình vì phải xem mã nguồn (sourcecode)khi kiểm thử
Kiểm thử hộp đen (Black-box test):
o Là kiểm thử thông số kỹ thuật, hành vi bên ngoài của sản phẩm
o Test case được xây dựng dựa theo bản đặc tả yêu cầu SRS (software requirements
specification)
o Tester không cần biết lập trình vì không phải kiểm thử codehay algorithm
Q4: Khi nào không nên dùng TestAutomation?
Ta không nên dùng kiểm thử tự động (test automation) như những trường hợp sau:
o Ngân sách hạn hẹp

4. o Khi tester kiểm thử giao diện (UI), trải nghiệm người dùng (UX) hoặc tính hữu
dụng (usability)
o Nếu sản phẩm chưa ổn định, thay đổiliên tục thì test automation sẽ gây lãng phí tài
nguyên
o Với các test case quá phức tạp thì việc kiểm thử tự động sẽ gây lãng phí nguồn lực
o Khi tester phải kiểm thử thủ công (manual test) để hiểu sâu hơn về hệ thống
Q5: Phân biệt Verification và Validation
Kiểm định (verification):
o Thực hiện ở từng, giữa mỗi giai đoạncủa quá trình phát triển
o Đánh giá những hạng mục nhỏ nhằm đảm bảo sản phẩm đáp ứng yêu cầu của từng
giai đoạn
o Đảm bảo sản phẩm cuối đáp ứng yêu cầu về đặc điểm kỹ thuật
o Trả lời câu hỏi “Chúng ta có đang phát triển sản phẩm đúng cách không?”
o Là hoạt động cấp thấp, không cần chạy test
o Gồm những kỹ thuật tĩnh (static) như đánh giá (review), kiểm tra (inspection), tổng
duyệt (walkthrough),…
Thẩm định (validation):
o Được thực hiện ở giai đoạn cuối của quá trình phát triển sản phẩm, sau khi hoàn
thành verification
o Đảm bảo sản phẩm cuối đáp ứng yêu cầu nghiệp vụ, nhu cầu khách hàng
o Trả lời câu hỏi “Chúng ta có đang phát triển sản phẩm thích hợp không?”
o Là hoạt động cấp cao, cần chạy sản phẩm khi đánh giá
o Gồm những kỹ thuật động (dynamic) như kiểm thử hồi quy (regression test), kiểm
thử chức năng (functional test),…
Q6: Như thế nào là Bug Life Cycle?
Vòng đời bug (bug life cycle) là tập hợp những trạng thái mà lỗi (bug) trải qua
trong vòng đời. Nhờ có quy trình cho một vòng đời bug mà tester dễ dàng quản lý
bug hơn. Quy trình này thường diễn ra theo 4 bước sau:
1. Testerphát hiện bug
o Tạo nhật ký bug, gán trạng thái “STATUS = NEW (MỚI)”
o Báo cáo, chuyển bug cho Quản lý dự án
2. Quản lý dự án phân tích bug
- Bug có hợp lệ không?

5. o Không: gán trạng thái “STATUS = REJECTED (TỪ CHỐI)”
o Có: tiếp tục
- Bug có thuộc phạm vi kiểm thử không?
o Không: gán trạng thái “STATUS = DEFERRED (TẠM HOÃN)”
o Có: tiếp tục
- Bug có trùng lặp không?
o Có: gán trạng thái “STATUS = DUPLICATE (TRÙNG LẶP)”
o Không: phân công Dev để sửa bug
3. Dev sửa bug
o Gán trạng thái “STATUS = IN-PROGRESS (ĐANG SỬA)”
o Khi hoàn thành thì báo cho Tester
o Gán trạng thái “STATUS = FIXED (ĐÃ SỬA)”
4. Testerkiểm duyệt bug
- Bug cònxuất hiện:
o Báo cáo cho Dev (quy trình quay lại bước 3)
o Gán trạng thái “STATUS = RE-OPENED (CHƯA ĐÓNG)”
- Bug không xuất hiện:
o Báo cáo cho Dev và Quản lý dự án
o Gán trạng thái “STATUS = CLOSED (ĐÓNG)”
Q7: Khi nào nên dừng kiểm thử?
Tester dựa vào điều kiện dừng (exit criteria) của dự án để quyết định thời điểm
dừng kiểm thử. Mỗi dự án có các điều kiện dừng riêng nhưng thường sẽ gồm
những điều sau:
o Quá thời hạn
o Cạn kiệt ngân sách
o Đạt yêu cầu test case, tỷ lệ bug
o Đã sửa những lỗi (defect) phát hiện
o Sản phẩm hoạt động tốt, ổn định, ít bug
o Sửa mọi bug nghiêm trọng
o Hoàn thiện, cập nhật các tài liệu về sản phẩm
o Quản lý dự án quyết định dừng

6. Technical Skills
1. Systems Development Life Cycle
Systems Development Life Cycle (SDLC — Vòng đời phát triển hệ
thống) là một chuỗi các pha (phases) trong chu trình phát triển một
dự án phần mềm. Về cơ bản, một SDLC thường bao gồm 6 pha:
o Pha 1: Planning (Pha kế hoạch)
o Pha 2: Analysis (Pha phân tích)
o Pha 3: Design (Pha thiết kế)
o Pha 4: Development (Pha lập trình)
o Pha 5: Testing (Pha kiểm thử)
o Pha 6: Maintenance (Pha triển khai & bảo trì)
Là một tester, việc nắm rõ SDLC không chỉ cho phép bạn hiểu sâu về
quá trình phát triển sản phẩm, mà còn giúp bạn xây dựng kế hoạch
kiểm thử dễ dàng hơn, dự đoán sớm những vấn đề phức tạp để có
phương án đo lường, dự phòng từ trước.
Waterfall, Scrum, Lean và Kanban là những phương pháp phổ biến
được các công ty áp dụng để xây dựng SDLC. Hãy đảm bảo rằng bạn
đã có khái niệm cơ bản về các phương pháp trên và đào sâu hơn vào
phương pháp phù hợp nhất với yêu cầu công việc nhé.
2. Testing Process
Có 2 cách để thực hiện Testing Process (Quy trình kiểm thử), bao gồm:
Manual Testing (kiểm thử thủ công) và Automation Testing (kiểm thử
tự động).
Manual Testing:Giống như cái tên “Kiểm thử thủ công”, tester sẽ kiểm
tra ứng dụng bằng cách đóng vai một người dùng cuối (end-user) để
tìm ra bugs. Việc của bạn là thực hiện tất cả các test cases một cách
thủ công mà không sử dụng công cụ kiểm thử tự động nào.

7. Automation Testing: “Kiểm thử tự động” sử dụng các công cụ để tự
động hoá quy trình kiểm thử. Ví dụ thay vì phải nhập từng email và
password bằng tay khi test chức năng login, bạn sẽ chạy code để máy
tự động nhập các dữ liệu này. Test Automation Engineer tại Got It đã
ví đây như một “cuộc cách mạng công nghiệp” khi tester có thể tối đa
hiệu suất bằng các công cụ hiện đại, giúp giảm đáng kể thời gian và
công sức bỏ ra.
Automation Testing không thể thay thế hoàn toàn Manual Testing.
Tuy nhiên, nếu bạn muốn mở rộng lộ trình nghề nghiệp thì đây là một
phương án rất đáng cân nhắc đấy nhé.
3. Testing Tools and Technologies
Hiểu biết về các công cụ và công nghệ kiểm thử là những kỹ năng
sống còn đối với mọi tester. Nó giống như việc bạn sẽ không thể đi
cày mà không có trâu hay máy cày vậy!
Got It đã tổng hợp những công cụ kiểm thử phổ biến nhất trong thời
gian qua. Tuy nhiên, bạn không cần phải “master” tất cả những thứ
được nêu tên, mà hãy chọn những gì phù hợp với nhu cầu của mình
đã nhé.
o Test Management Tools (Công cụ quản lí kiểm thử): Thường được
dùng để quản lí các dự án, tài nguyên kiểm thử, lưu trữ kết quả kiểm
thử, tạo báo cáo (reports), v.v.. Các công cụ quản lí kiểm thử thông
dụng bao gồm TestRail, TestLink, Asana, Zephyr, và QMetry.
o Agile Testing Tools (Công cụ kiểm thử Agile): Nếu bạn đang/muốn
làm trong một công ty áp dụng Agile/Scrum, bạn nên có hiểu biết
hoặc kinh nghiệm làm việc với JIRA hay SoapUI.
o Load Testing Tools (Công cụ kiểm thử chịu
tải): Apache JMeter và Tsung là hai công cụ thường được các tester
sử dụng khi thực hiện load tests và stress tests.

8. o Defect Tracking Tools (Công cụ quản lí lỗi): Để mọi thành viên (tester,
developer, PM, v.v.) đều nắm được các lỗi và trạng thái của chúng
trong một dự án phần mềm, ta thường sử dụng các công cụ
như QC, Bugzilla hay JIRA.
o Automation Testing Tools (Công cụ kiểm thử tự động): Những công
cụ này cho phép bạn kiểm tra các chức năng của phần mềm một cách
tự động, từ đó chạy được nhiều tests hơn trong thời gian ngắn một
cách hiệu quả. Những công cụ kiểm thử tự động thông dụng bao
gồm Selenium, Watir và Ranorex. Tuy nhiên, chỉ biết lý thuyết về
chúng là chưa đủ. Bạn cần có kinh nghiệm thực tế (qua dự án tại công
ty, bài tập nhóm, hackathon, dự án cá nhân, v.v.) thì mới có thể thực sự
biết cách sử dụng các công cụ này.
4. Kiến thức cơ bản về Database/SQL
Mỗi hệ thống phần mềm đều có một lượng lớn dữ liệu. Chúng có thể
được lưu trữ trong nhiều kho dữ liệu khác nhau như Oracle,
MySQL/NoSQL (Redis, MongoDB)/SQL Server (Query DB), v.v. ở phần
backend. Bởi vậy, tester cần có kiến thức cơ bản về các kho dữ liệu,
cũng như cách sử dụng những câu truy vấn cần thiết để có thể truy
cập vào database, tạo dữ liệu test mà không cần phải nhờ đến sự giúp
đỡ từ các developers.
5. Kiến thức cơ bản về lập trình (không bắt buộc)
Bạn không bắt buộc phải biết code để ứng tuyển vào vị trí tester. Tuy
nhiên, có kiến thức cơ bản về lập trình sẽ giúp bạn hiểu được cách các
lập trình viên tạo ra sản phẩm, hiểu được các chức năng cũng như các
lỗi thường gặp. Từ đó, việc tạo ra các test cases phù hợp cũng sẽ dễ
dàng hơn rất nhiều.
Non-Technical Skills

9. 6. Analytical skills (Kỹ năng phân tích)
Một tester giỏi cần có kỹ năng phân tích sắc bén. Bạn cần có khả năng
bẻ nhỏ các vấn đề phức tạp của hệ thống phần mềm thành những
phần nhỏ hơn để tạo test cases cho chúng. Bạn chưa chắc về kỹ năng
phân tích của mình? Hãy thử bài test này — nếu có thể giải được ít
nhất 1 câu thì kỹ năng phân tích của bạn đã rất đỉnh rồi đấy!
7. Communication skills (Kỹ năng giao tiếp)
Nhiều bạn nghĩ rằng tester là một vị trí thiên về kỹ thuật nên không
cần quá nhiều khả năng giao tiếp. Tuy nhiên, thực tế đã chứng minh
ngược lại.
Tester thường làm việc với rất nhiều bên trong một dự án, ví dụ như
cập nhật tình hình cho khách hàng, trao đổi các vấn đề (issues) với
developers, biến các tài liệu về requirements thành test cases và báo
cáo kết quả cho quản lý, v.v.. Trong bất cứ trường hợp nào, bất kể
người đang nói chuyện với bạn là ai, mọi thông tin đều phải được
truyền đạt một cách vô cùng chính xác và súc tích, đặc biệt là với
những vấn đề phức tạp và có liên quan đến nhiều bên.
Những kỹ năng cụ thể bao gồm:
o Kỹ năng đặt câu hỏi. Với bất cứ điều gì chưa rõ, hãy luôn đặt câu hỏi.
Đây là một trong những kỹ năng quan trọng nhất bạn cần có khi trở
thành một tester. Học cách hỏi đúng câu, đúng lúc là điều mà bạn sẽ
luôn phải trau dồi trong suốt quá trình làm việc của mình.
o Kỹ năng lắng nghe. Hãy lắng nghe một cách chủ động và có trách
nhiệm. Điều này không chỉ giúp bạn hiểu rõ tình hình công việc hiện
tại, mà còn giúp bạn nảy ra những ý tưởng để cải thiện nó.
o Kỹ năng thuyết trình. Chỉ lắng nghe thôi là chưa đủ. Bạn cần biết
cách trình bày ý kiến của mình một cách rõ ràng, mạch lạc với các bên
liên quan. Hãy luôn đảm bảo mọi người đã biết đến các lỗi mà bạn tìm
ra để sửa chúng kịp thời nhé.

10. 8. Time Management & Organization Skills (Kỹ năng
quản lí thời gian)
Tester lúc nào cũng rất bận rộn, đặc biệt là những khi sắp release. Bởi
vậy, nếu không quản lí được thời gian của mình, rất có thể bạn sẽ
“ngập lụt” trong công việc và rơi vào cái vòng OT luẩn quẩn không hồi
kết. Hãy học cách đặt ra thứ tự ưu tiên cho các đầu việc, thậm chí tạm
thời nói “không” với những việc không quan trọng.
9. Be Proactive At Work (Làm việc chủ động)
Công nghệ phần mềm thay đổi từng giờ, từng phút. Là một tester, bạn
rất dễ tụt hậu nếu không liên tục những kiến thức và công nghệ mới.
Bởi vậy, trước tiên hãy chủ động tìm kiếm và học hỏi những kiến
thức liên quan đến kiểm thử và phát triển phần mềm, như các
hướng tiếp cận mới, cách tăng hiệu suất công việc.
Thứ hai, hãy chủ động trong việc áp dụng kiến thức vào thực tế.
Như đã nói ở trên, bạn không thể nói mình thành thạo Test
Automation nếu chưa thực sự dùng nó trong một dự án cụ thể. Việc
chủ động áp dụng kỹ thuật, công nghệ mới sẽ giúp bạn dày dặn kinh
nghiệm và có chỗ đứng tốt hơn trong công việc.
Cuối cùng, hãy chủ động trong toàn bộ quá trình làm việc. Bạn sẽ
không thể trở thành Senior hay Manager nếu lúc nào cũng phải chờ
người khác giao việc hay chỉ dẫn. Hãy chủ động học hỏi và đề xuất ý
tưởng để cải thiện chất lượng sản phẩm. Và đừng quên hỏi nếu còn
bất cứ điều gì chưa rõ nhé.
Các mức độ kiểm thử phần mềm (Testing Levels)
Thông qua cácmức độ kiểm thử phần mềm sẽ giúp bạn có thể đánh giá chức năng
của ứng dụng phần mềmcó đáp ứng được những yêu cầu đã chỉ định hay không.
Đồng thời thông qua cácmức độ kiểm thử phần mềm cũng giúp bạn tìm và tiến
hành sửa lỗi nhằmđảm bảo sản phẩmtạo ra có chất lượng tốt nhất.

11. Vậy kiểm thử phần mềm bao gồmnhững mức độ nào, cùng Anh Tester tìm hiểu
nhé.
o Mức độ 1: Unit Testing – Kiểm thử mức đơn vị
o Mức độ 2: Integration Testing – Kiểm thử tích hợp
o Mức độ 3: System Testing – Kiểm thử mức hệ thống
o Mức độ 4: Acceptance Testing – Kiểm thử chấp nhận
Mức độ 1: Unit Testing – Kiểm thử mức đơn vị
Unit Testing là giai đoạn đầu tiên trong kiểm thử phần mềm. Unit Testing được thực
hiện nhằm kiểm tra và xác định các module riêng lẻ thuộc mã nguồn có hoạt động
đúng hay không. Mục đích của kiểm thử mức đơn vị như sau:
o Xác định mỗi đơn vị phần mềm có đang thực hiện theo đúng thiết kế ban đầu hay
không.
o Thông qua thử nghiệm sẽ giúp khắc phục những phát sinh do việc thay đổi hay bảo
trì code.
o Unit Testing giúp tiết kiệm chi phí, thời gian và thể diện khi phát hiện ra lỗi.
Mức độ 2: Integration Testing – Kiểm thử tích hợp
Mỗi dự án phần mềm được hoàn thành bởi rất nhiều module do nhiều người code
khác nhau. Integration Testing là cấp độ kiểm thử phần mềm tích hợp của các đơn vị
riêng lẻ được kết hợp và thử nghiệm thành một nhóm thông qua việc tập trung vào
kiểm tra truyền dữ liệu giữa các module.
Mục đích của giai đoạn kiểm thử Integration Testing đó là tìm và phát hiện lỗi khi tích
hợp các module lại với nhau. Để tiến hành Integration Testing có 4 phương pháp tiếp
cận bao gồm: big bang, top down, bottom up và sandwich/hybrid.
Mức độ 3: System Testing – Kiểm thử hệ thống
System Testing là giai đoạn thứ 3 của kiểm thử phần mềm cho phép phần mềm hoàn
chỉnh và tích hợp được kiểm tra. System Testing tập trung nhiều hơn vào các chức
năng của toàn bộ hệ thống. Kiểm thử hệ thống bao gồm kiểm thử chức thăng và kiểm
thử phi chức thăng.
Mục đích của System Testing đó là kiểm tra thiết kế và toàn bộ hệ thống sau khi tích
hợp có tuân thủ những yêu cầu đã được định sẵn trước đó hay không. Do đó System
Testing rất chú trọng các hành vi và lỗi xuất hiện trên hệ thống. Người thực hiện giai
đoạn System Testing thường là kiểm thử viên hoàn toàn độc lập so với nhóm phát
triển dự án.

12. Mức độ 4: Acceptance Testing – Kiểm thử chấp nhận
Acceptance Testing được thực hiện bởi khách hàng hoặc ủy quyền cho nhóm thứ ba
nhằm kiểm tra hệ thống vừa xây dựng đã phù hợp với yêu cầu của khách hàng trước
đó hay chưa. Mục đích của Acceptance Testing đó là xác nhận lại sự tin tưởng vào hệ
thống, các đặc tính thuộc về chức năng hoặc phi chức năng của hệ thống.
Có 2 loại kiểm thử chấp nhận đó là Alpha Testing và Beta Testing.
Mức độ nghiêm trọng và độ ưu tiên trong kiểm thử phần
mềm
Kiểm tra chương trình phần mềm không phảilà việc phát hiện ra càng nhiều lỗi
càng tốt. Một chiến lược như vậy có thể là một sự lãng phí về tiền mặt và năng
lượng. Tại sao?Bạn đã bao giờ nghe nóivề các nguyên tắcMurphyLegaltrong lập
trình chưa? Nếu chỉ có một dòng mã tạo nên toàn bộ tiện ích thì sẽ có không ít hơn
một lỗi trong đó.
Lỗi luôn luôn là một thành phần không thể thiếu của chương trình phần mềm. Đơn
giản là một vài trong số họ là vô tội trong khi những ngườikháccó thể gâyra hỗn
loạn và trục trặc. Một số điểm của chương trình phần mềm cực kỳ quan trọng hơn
những điểm khác. Đó chính là lý do tại sao những ngườikiểm tra QA có kỹ năng lại
thích phácthảo mức độ nghiêmtrọng của lỗi.
1. Khái niệm
Bugseverity - Mứcđộ nghiêmtrọng củabug
Mức độ nghiêm trọng của bug là mức độ ảnh hưởng của lỗi đó trên phần mềm mà
chúng ta test. Ảnh hưởng của lỗi càng cao sẽ dẫn đến mức độ nghiêm trọng cao hơn.
QA nên thường xuyên xác định mức độ nghiêm trọng của lỗi.
Priority- Mứcđộ ưutiên
Mức độ ưu tiên là thứ tự của 1 lỗi nên được fix khi nào. Độ ưu tiên càng cao thì càng
nên giải quyết sớm. Các lỗi khiến phần mềm không sử dụng được được ưu tiên cao
hơn một chức năng nhỏ bị lỗi.
2. Phân loại
Trong kiểm thử phần mềm, mức độ nghiêm trọng của lỗi được chia thành 4
loại:

13. o Critical: lỗi này cho biết quá trình hoạt động của hệ thống đã bị ngừng, cần được xử
lý ngay lập tức.
o Major: đây là một lỗi có thể làm ngừng hoạt động 1 phần hệ thống, tuy nhiên một số
chức năng khác vẫn hoạt động bình thường.
o Medium: gây ra những hành vi không mong muốn nhưng hệ thống vẫn hoạt động
được.
o Low: một lỗi nhỏ, không gây ảnh hưởng đến bất kì chức năng nào của hệ thống.
Độ ưutiên của lỗi thườngđượcchialàm 3 loại:
o High: Lỗi phải được khắc phục càng sớm càng tốt vì nó ảnh hưởng nghiêm trọng đến
hệ thống và không thể sử dụng cho đến khi fix xong.
o Medium: Lỗi cần được giải quyết. Chúng ta có thể test các phần khác cho đến khi bản
mới của lỗi được built.
o Low: Nó gây khó chịu, có thể fix khi 1 lỗi khác nghiêm trọng hơn được fix.
3. Các mẹo để xác định độ nghiêm trọng của bug
o Tần suất xuất hiện: trong một số trường hợp, nếu một lỗi nhỏ xảy ra thường xuyên
thì nó có thể nghiêm trọng hơn. Vì vậy, ở dưới góc độ của người nhìn, nó trở nên
nghiêm trọng hơn mặc dù chỉ là một lỗi nhỏ.Cô lập lỗi: Cô lập lỗi có thể giúp chúng ta
tìm ra độ ảnh hưởng => độ nghiêm trọng của lỗi

14. 4. Sự khác nhau giữa Priority và Severity
Độ ưu tiên Mức độ nghiêm trọng
Xác định thứ tự mà dev cần giải quyết Xác địnhmức độ ảnhhưởngcủa lỗi đối với phần mềm
Liên quan đến việc lập kế hoạch Liên quan đến tiêu chuẩn và các chức năng khác
Độ ưu tiên cho biết lỗi nên được sửa sớm ở mức nào Mức độ nghiêm trọng cho thấy độ nghiêm trọng của
lỗi trên chức năng sản phẩm
Độ ưu tiên được quyết định với sự tham vấn của quản
lý / khách hàng
QA xác định mức độ nghiêm trọng của bug
Độ ưu tiên được xác định bởi nghiệp vụ Mức độ nghiêm trọng được xác định bởi chức năng
Có thể thay đổi trong một khoảng thời gian tùy thuộc
vào tình hình dự án
Ít có khả năng thay đổi
Khi UAT, team phát triển sẽ fix các lỗi dựa vào mức độ
ưu tiên
Trong quá trình SIT, team phát triển fix lỗi dựa trên
mức độ nghiêm trọng nhiều hơn và sau đó là mức độ
ưu tiên
5. Ví dụ về độ nghiêm trọng và độ ưu tiên của lỗi
Ví dụ dưới đây về mức độ nghiêm trọng thấp, mức độ ưu tiên cao và ngược lại:
o Mức độ nghiêm trọng thấp, mức độ ưu tiên cao: Logo của 1 website bị sai, có thể độ
nghiêm trọng thấp vì nó không ảnh hưởng đến các chức năng khác nhưng có thể có
độ ưu tiên cao vì logo sai ảnh hưởng đến uy tín của công ty.
o Mức độ nghiêm trọng cao, mức độ ưu tiên thấp: Ví dụ lỗi ở 1 game có nhiều level.
Hiện tại level 5 đang bị crash, không chơi được. Đây là một lỗi rất nghiêm trọng
nhưng lại có độ ưu tiên thấp hơn. Vì muốn đến được level 5 thì ta phải qua được
level 1,2,3,4 nên những lỗi ở level 1,2,3,4 có độ ưu tiên cao hơn.
6. Defect triage (thử nghiệm lỗi)
Kiểm thử sai sót là một quá trình để cố gắng cân bằng lại quy trình trong đó nhóm
kiểm thử phải đối mặt với việc hạn chế nguồn nhân lực. Số lượng lỗi lớn, nhân lực

15. hạn chế thì việc phân loại lỗi sẽ giúp chúng ta giải quyết nhanh hơn. Quá trình xử lý
bao gồm những bước sau:
o Xem xét tất cả các bug bao gồm cả các bug bị reject
o Đánh giá ban đầu về lỗi dựa trên nội dung của nó và set mức độ ưu tiên và mức độ
nghiêm trọng tương ứng
o Ưu tiên các lỗi dựa trên các đầu vào
o Chỉ định lỗi cần sửa để release chính xác bởi người quản lý sản phẩm
o Assign lại lỗi cho chủ sở hữu / nhóm để thực hiện
7. Gợi ý tester nên xem xét trước khi chọn mức độ nghiêm
trọng
Mức độ nghiêm trọng được đánh giá bởi người kiểm thử trong khi độ ưu tiên được
đánh giá bởi người quản lý sản phẩm hoặc nhóm phân loại. Để phân loại độ ưu tiên,
bắt buộc người kiểm thử phải chọn đúng mức độ nghiêm trọng.
o Hiểu rõ khái niệm độ ưu tiên và mức độ nghiêm trọng
o Luôn luôn gán mức độ nghiêm trọng dựa trên loại bug vì điều này sẽ ảnh hưởng đến
mức độ ưu tiên của nó
o Hiểu kịch bản (scenario) cụ thể hoặc testcases sẽ ảnh hưởng đến người dùng cuối
o Cần xem xét cần bao nhiêu thời gian để sửa lỗi dựa trên độ phức tạp và thời gian để
xác minh lỗi.
Kết luận
Trong kĩ thuật phần mềm, việc xác định mức độ nghiêm trọng sai có thể làm chậm
quá trình phát triển phần mềm và làm giảm hiệu suất chung của nhóm. Vì vậy, người
có trách nhiệm cần phải xác định chính xác mức độ nghiêm trọng và độ ưu tiên của lỗi.