101 câu hỏi phỏng vấn tester thường gặp và gợi ý trả lời

Một trong những tố chất quan trọng của một Tester chính là sự chăm chỉ, cẩn thận. Ngoài ra, bạn cũng có thể thêm một số tố chất như có trách nhiệm với công việc, có khả năng phân tích vấn đề, xử lý được các lỗi hoặc vấn đề lập trình cơ bản.

Khái niệm kiểm thử phần mềm: Là quá trình kiểm tra, phát hiện các lỗi nếu có của phần mềm đã được lập trình. Ngoài ra sẽ bao gồm đánh giá phần mềm có đáp ứng được các nhu cầu, tiêu chí của khách hàng hay không.

Quy trình kiểm thử tham khảo: Chạy thử dự án -> thực hiện chuẩn bị kiểm thử -> tiến hành các bài/hạng mục kiểm tra -> thực hiện hậu kiểm thử -> làm báo cáo về kết quả sau kiểm thử.

Có 2 phương pháp kiểm thử phần mềm

• Kiểm thử hộp đen: Dùng khi test theo yêu cầu, tiêu chí của khách hàng, đưa ra các chức năng hệ thống.
• Kiểm tra hộp trắng: Kiểm tra về các thuật toán, mã code, cấu trúc của chương trình.

Để phát triển phần mềm sẽ cần qua 4 giai đoạn chính. Bao gồm:

• Unit testing: Kiểm thử đơn vị.
• Integration testing: Kiểm thử tích hợp.
• System testing: Kiểm thử hệ thống.
• Acceptance testing: Công nhận kiểm thử.

• Bug là lỗi trong phần mềm được phát hiện trong thời gian thử nghiệm. Đây là những lỗi nghiêm trọng có thể chặn một chức năng, dẫn đến sự cố hoặc gây tắc nghẽn hiệu suất
• Defect là sự sai sót giữa kết quả mong đợi và kết quả thực tế, phát hiện sau khi sản phẩm đi vào sản xuất.
• Error là lỗi gây ra do sự hiểu nhầm, hiểu sai thông tin, ký hiệu giữa các bên tham gia thiết kế phần mềm (gồm kỹ sư phần mềm, lập trình viên, nhà phân tích và tester) , những người này đều là nhân sự của công ty phần mềm.

Là quá trình đo tải khả năng của hệ thống, cách chúng xử lý dữ liệu như thế nào, từ đó đưa ra được ngưỡng tối đa của hệ thống.

Thử nghiệm hệ thống đòi hỏi phải thử nghiệm toàn bộ hệ thống để xác định xem nó có đáp ứng các tiêu chuẩn được thiết lập ngay từ đầu hay không. Loại thử nghiệm này thường đề cập đến thử nghiệm hộp đen gồm hai loại: chức năng (functional) và phi chức năng (non-functional) bởi những người thử nghiệm dự án (project).

Kiểm thử sớm sẽ giúp cho các mục tiêu của quá trình phát triển phần mềm được tập trung tối đa. Nếu phát hiện lỗi sẽ kịp thời fix lỗi, từ đó có được sản phẩm chất lượng, tạo được niềm tin với khách hàng, giúp giảm thiểu tối đa chi phí bảo trì. 

Ngược lại, kiểm thử muộn có thể sẽ rất khó khăn để phát hiện và sửa lỗi. Theo đó, sản phẩm giao cho khách hàng sẽ không đảm bảo chất lượng, có thể không đúng thời hạn, gây lãng phí chi phí, mất niềm tin với khách hàng và giảm uy tín của công ty.  

• Phân loại , giải thích quy trình Manual testing (Kiểm tra thủ công)
• Phân biệt giữa kiểm tra alpha và kiểm tra beta.
• Kiểm thử API là gì?
• Kiểm tra hồi quy (regression testing) là gì? Khi nào thì áp dụng nó?
• Sự khác biệt giữa Kiểm tra chủ động và kiểm tra bị động ( là gì?)

Đối với dạng câu hỏi này ứng viên cần trình bày những thông tin cơ bản về dự án vai trò của bản thân khi thực hiện dự án, chủ đề dự án, mục đích ý nghĩa và kết quả mà dự án đã thực hiện được. 

Thường thì các ứng viên có kinh nghiệm sẽ tham gia rất nhiều dự án khác nhau, tuy nhiên hãy cân nhắc và đưa ra một dự án mà mình thấy tâm đắc nhất. Đối với dự án đó, bạn cần nêu rõ các chuyên môn kỹ thuật về kiểm thử của mình.

Để có thể chia sẻ chi tiết những trải nghiệm của bạn đối với công cụ X mà bạn đã sử dụng để thực hiện kiểm thử, cách duy nhất và hiệu quả nhất là dựa vào mô hình STAR, cụ thể:

• Situation: Nêu mô tả ngắn gọn công cụ mà bạn đang sử dụng để làm việc và quá trình phát triển dự án dựa trên công cụ đó.
• Tasks: Nêu rõ những công việc mà bạn đã làm đối với công cụ X. 
• Actions: Chỉ ra chi tiết cách bạn làm khi sử dụng công cụ X.
• Results: Kết quả của dự án và thời gian mà bạn đã thực hiện dự án khi sử dụng công cụ X như thế nào.

Để trở thành một tester thực thụ thì cần phải có những kỹ năng cơ bản, cụ thể như:

• Cẩn thận, chăm chỉ, tỉ mỉ và có trách nhiệm đối với đầu việc được giao 
• Có khả năng phân tích dự án, biết xử lý và giải quyết vấn đề phát sinh trong quá trình làm việc. 
• Luôn biết lắng nghe, học hỏi và tiếp thu các kiến thức cần thiết trong quá trình làm việc. 
• Phải là người có tinh thần cầu tiến trong công việc, sẵn sàng làm thêm ngoài giờ khi được cấp trên yêu cầu.

Dựa vào điều kiện dừng của dự án để biết chính xác lúc nào tester nên dừng kiểm thử. Tùy vào từng dự án mà điều kiện dừng sẽ có sự khác nhau, tuy nhiên thường sẽ bao gồm các điều như:

• Quá thời gian kiểm thử
• Hết ngân sách chi trả
• Đã đạt được yêu cầu về test case và tỷ lệ bug 
• Các lỗi phát hiện khi kiểm thử đã được fix
• Sản phẩm ít bug, hoạt động ổn định, tốt
• Kiểm thử đã hoàn thiện, tài liệu đã được cập nhật đầy đủ
• Quản lý dự án quyết định dừng kiểm thử

Các test case không giống nhau hoàn toàn. Một số thành phần cố định luôn có của test case là tester, tên test case, ID, function, tên điều kiện, ngày test, các bước triển khai, kết quả mong muốn, kết quả thực tế, ghi chú,… 

Kiểm thử hệ thống (System Testing) là kiểm tra lại toàn bộ hệ thống sau khi tích hợp. Loại kiểm thử này giúp xác định hệ thống đã đủ các tiêu chuẩn đặt ra như ban đầu hay chưa. Kiểm thử hệ thống thường đề cập đến kiểm thử hộp đen (kiểm thử chức năng và phi chức năng). 

Thông thường sẽ có tên của Tester, tên dự án, số lượng test case đã viết/số lượng đã test, số lượng test case Fail/Pass, số lượng defect trên module, tiến độ fix lỗi,…

Với một dự án phần mềm bất kỳ thì lỗi sẽ xuất hiện khi bộ phận lập trình viên hoàn thành code của dự án đó. Khi dự án được chuyển sang bộ phận tester thì hoạt động tìm kiếm và gỡ lỗi được diễn ra cùng nhau. 

Và giai đoạn này chính là giai đoạn lỗi thường xuyên xảy ra nhất.

Đó là khi mã đã hoạt động ổn định, không phát sinh lỗi, chạy lệnh tốt. Mỗi công ty phần mềm có những tiêu chuẩn đánh giá mã tốt (good code) khác nhau, buộc nhân viên tuân theo. Khi tất cả các trường hợp kiểm tra kết thúc thành công, cho thấy mã đáp ứng yêu cầu.

Kiểm tra tự động thể hiện tính ưu việt hơn trong những tình huống sau:

• Kiểm tra yêu cầu thực hiện định kỳ
• Quá trình kiểm tra gồm nhiều bước lặp đi lặp lại giống nhau
• Thời gian chạy kiểm tra khắt khe theo tiêu chuẩn nhất định.
• Phần mềm có nhiều mã code cần kiểm tra nhiều lần
• Tester không có nhiều thời gian để thực hiện kiểm tra thủ công
• Mỗi lần kiểm tra là một lần báo cáo…

• Dự án thời gian ngắn: nếu áp dụng kiểm tra tự động sẽ tốn nhiều thời gian thiết kế và duy trì các công cụ, lệnh, phần mềm hỗ trợ.
• Kiểm tra mang tính chất đặc biệt: những trường hợp này không có định hướng kiểm tra cụ thể nên phải dựa hoàn toàn vào kinh nghiệm và năng lực của người phụ trách.
• Kiểm tra khám phá: đòi hỏi cao về kỹ năng phân tích, khả năng tư duy, sáng tạo và trực giác của tester.
• Kiểm tra khả năng sử dụng: hệ thống tự động không giúp đo lường đượcsự thân thiện, tính hiệu quả và mức độ thuận lợi mà khách hàng sẽ cảm nhận.

Kiểm tra hệ thống đòi hỏi tính đồng bộ ở tất cả các thành phần trong phần mềm. Do vậy, phải đợi tất cả các mã lệnh được cài đặt, phần mềm đã có thể vận hành bình thường thì việc kiểm tra mới có thể tiến hành.

• Làm thế nào bạn kiểm tra một sản phẩm nếu các yêu cầu vẫn chưa đóng băng?
• Quản lý cấu hình là gì?
• Tại sao phân tích giá trị ranh giới (boundary value analysis) lại cung cấp các trường hợp kiểm tra tốt?
• Vì sao không thể đảm bảo phần mềm 100% không có lỗi?
• Kiểm tra tự động hóa (automation testing) liệu có thay thế được kiểm tra thủ công (manual testing) không?

1. Dựa vào SRS: Software Requirement specification Document(tài liệu đặc tả)
2. Q&A file
3. Ticket của khách hàng trên tool quản lý dựa án vd redmine
4. Dựa vào thay đổi yêu cầu của khách hàng sau mỗi lần họp

Bug là gì?

"Bug là những error, flaw, failure, hay fault tạo ra một kết quả sai. Kết quả k đúng như yêu cầu đặc tả. Hay nó là chức năng mà bản đặc tả không đề cập đến Error - Fault - Failure (Defect/Bug):

• Error:Lỗi xảy ra khi có tác động lên sản phẩm gây ra một kết quả sai lệch.
• Fault:Lỗi xảy ra khi làm sai các step, process, hoặc chuẩn bị dữ liệu.
• Failure:Lỗi khi có kết quả sai lệch so với yêu cầu đặc tả. Errors → Faults → Failures (Defect/Bug)

Answer: Trước hết em sẽ đọc và tìm hiểu lại tài liệu xem có đúng như những gì mình test và log bug. Sau đó em sẽ review lại lỗi cho dev thấy và trao đổi vs dev.

• Nếu nó k phải là bug thì em sẽ để là feature(Tính năng).
• Nếu là bug mà dev vẫn k công nhận thì em sẽ hỏi ý kiến leader or PM

VD: các trường bắt buộc phải đc gán nhãn * dev bảo k phải là bug vì k có trong tài liệu đặc tả thì p xem lại đặc tả, nếu đúng thì sẽ gán nó là lỗi chức năng chứ k phải bug.

Sau khi nhập hết thông tin mã capcha nhập sai thì các thông tin p trên vẫn đc giữ nguyên chỉ có mã capcha đc reload lại. Hoặc khi nhập thông tin xong mà k muốn đk tài khoản nhấn button Đóng thì hệ thống sẽ p có một thông báo”Bạn có chắc chắn muốn đóng cửa sổ không ”

Usability testing: Kiểm thử khả năng sử dụng là một loại kiểm thử được thực hiện từ góc độ người dùng cuối để xác định xem hệ thống có dễ sử dụng hay không. Kiểm tra khả năng sử dụng thường được thực hiện trong suốt các mức của kiểm thử hệ thống và kiểm thử chấp nhận Security testing: Kiểm thử bảo mật là một loại kiểm thử phần mềm có ý định phát hiện ra các lỗ hổng của hệ thống và xác đinh rằng dữ liệu và tài nguyên của nó được bảo vệ khỏi những kẻ xâm nhập có thể. -Có bốn lĩnh vực trọng tâm chính được xem xét trong kiểm thử bảo mật(đặc biệt đối với các trang web/ứng dụng): +Bảo mật mạng +Bảo mật phần mềm hệ thống

• Bảo mật ứng dụng phía máy khách
• Bảo mật ứng dụng phía máy chủ => kiểm thử bảo mật không phải là biện pháp duy nhất(hoặc tốt nhất) về mức độ an toàn của một ứng dụng. Nhưng khuyến khích rằng kiểm thử bảo mật được đưa vào như một phần của quy trình phát triển phần mềm tiêu chuẩn Ví dụ: 1.Check for SQL injection attacks. Check lỗi SQL injection Ví dụ: Texbox tìm kiếm: truyền vào giá trị tìm kiếm là một đoạn mã javascript Sử dụng câu lệnh SQL để truy cập dữ liệu: var username = request.username; … error messages Không được tiết lội bất kỳ thông tin nhạy cảm nào. Ví dụ: Khi user thực hiện đăng nhập không thành công do thông tin không đúng thì không nên hiển thị các error message kiểu như sau:

2.Tên đăng nhập không tồn tại Mật khẩu không đúng Việc hiển thị error message như trên sẽ giúp hacker có thể đưa ra những phán đoán nhằm xâm nhập vào hệ thống. Trong trường hợp này nên hiển thị error message một cách chung chung như: Tên đăng nhập hoặc mật khẩu không đúng. 3. Chức năng xác mình mã CAPCHA

Compatibility test: test trên nhiều version tính tương thích

Test nghiệp vụ business (hợp lệ, k hợp lệ, phân quyền: admin truy cập đc chức năng nào, user truy cập đc chức năng nào.) Test data ví dụ checkbox: số, chữ, xml, html, sql jquery... Vì sao cần nhập sql jquery: Nếu dev code k cẩn thận thì hệ thống sẽ thực hiện câu lệnh một số hacker có thể lợi dụng để hack tkhoan(Check for SQL injection attacks. Check lỗi SQL injection Ví dụ: Texbox tìm kiếm: truyền vào giá trị tìm kiếm là một đoạn mã javascript Sử dụng câu lệnh SQL để truy cập dữ liệu: var username = request.username; … error messages Không được tiết lội bất kỳ thông tin nhạy cảm nào.)

Trước tiên khi vào 1 dự án cần tìm hiểu vai trò của các member (ai là project leader, ai là PO, ai là QA, Dev... để khi có câu hỏi thì hỏi đúng người) Cần có cái nhìn khái quát về dự án như khách hàng là ai? sản phẩm phần mềm làm về lĩnh vực gì? ngữ cảnh? nghiệp vụ chung. Check description của box hoặc hỏi nx người phụ trách dự án để xác định thông tin:

• quy trình dự án
• quy trình test
• quy trình quản lý & câp nhật spec
• Các rule hoạt động của dự án
• folder dự án
• folder spec
• folder test Xác định được cách thức để thực hiện các công việc dự án (dùng tool hay file? quy trình thực hiện)
• Q&A
  • log ticket
• daily meeting
• report
• cách thức communicate của dự án

1. Đọc tài liệu đặc tả yêu cầu hoặc test checklist nếu có Em lên redmine đọc các task dev đã implement Sau đó vừa đọc vừa thử thao tác trên hệ thống, test thử để hiểu hệ thống theo các role --> Dành ra 2 buổi để đọc và chạy như trên nhé, mục tiêu để hiểu hệ thống trước Nếu có câu hỏi thì tạo file Q&A trên thư mục chung của dự án
2. Thực hiện liệt kê ra các trường hợp cần test (vận dụng test design technique đã học)
3. Viết test check list hoặc test case (tùy thuộc vào thời gian và resource của dự án)
4. Chú ý báo cáo hàng ngày ( template như nào em xem trên description của box chat)
5. Log bug trên redmine

Summary:

Pre-condition:

Step to-reproduce:

Actual result:

Excepted result: References: Q&A document #70 7. Khi re test, verify bug trên redmine nhớ có comment Ví dụ: Verified bug --> pass ---> Close bug report Hoặc Verified bug ---> fail Comement lý do fail ---> Reopen bug report

Comment template to verify ticket:

*PASS: This bug was fixed on [Staging] env Context

• Env: Staging
• OS: Window 10
• Browser: Chrome Version 71.0.3578.98 (Official Build) (64-bit)
• Date 03/ /2019

*FAIL: This bug still happens on [Staging/Dev] env Actual result: Expected result: Context

• Env: Staging
• OS: Window 10
• Browser: Chrome Version 71.0.3578.98 (Official Build) (64-bit)
• Date 03/ /2019

*FEEDBACK: Hi Dev/BrSE/... Content... Thanks.

Trong trường hợp sau khi log bug xong (những bug về logic chức năng, giao diện...) mà phát hiện luôn là không tái hiên được bug nữa, thì comment vào bug là "cannot reproduce" sau đó close bug lại. Không xóa bug đó đi nhé, chỉ close lại thôi nha. Nhưng phải nhớ comment vào bug trc khi close.

Trong trường hợp dev nhận ticket sau đó dev không tái hiện dc bug đó thì bạn dev đó cần comment vào bug là "cannot reproduce this issue" sau đó assign lại cho QA. QA vào check lại lần nữa, nếu đúng là k tái hiện dc thì QA comment vào và close bug. (ng close là QA chứ k phải Dev )

Trong trường hợp nếu do dev fix bug nào đó liên quan khiến cho bug mình log lên không tái hiện dc nữa (trường hợp này là do có một số bug log lên khác nhau nhưng lại cùng 1 root cause gây ra vấn đề, nên fix bug này thì bug khác cũng tự khỏi ) trường hợp này có thể dev comment vào đã fix, chung root cause với bug nào đó, assign lại QA. QA verify lại lần nữa xem còn bị bug hay không. Nếu pass thì close lại.

1. Đó là trong màn hình tạo plan, sau khi nhập đầy đủ thông tin vào các trường em click liên tục vào button Create thì có nhiều bản ghi giống nhau được tạo ra. Bình thg bug này cta không thể đoán trước được mà nó dựa vào kinh nghiệm của
2. Tester or là không may mình test thì thấy :v. VS bình thường em thường bảo mấy dev là em lấy việc log bug làm niềm vui nên thấy bug là em vui lắm :v. Mn toàn bảo em tạo nghiệp.
3. Phóng to, Khi thu nhỏ màn hình thì title của bảng kết quả bị chồng chéo lên nhau 3. Trường select show ra sau đó scroll chuột, thì bị overlow

Em update Guideline, update TCs, đọc lại các tài liệu xem mình có bỏ sót gì không hoặc test lại một số chức năng chính của hệ thống vì đôi khi em thấy dev fix bug hoặc deploy code mới một số chức năng hay bị lỗi,. Đọc các ticket trên redmine. đôi khi có một số bug dev fix trong quá trình fix bug khác mà k đổi status cũng như assign cho em thì em sẽ vào cmt và close bug

Tạo sẵn test case và chuyển đến deverloper trước khi coding. Đừng giữ test case cùng với việc đợi đến khi có ứng dụng cuối cùng rồi mới đưa ra test, vì nghĩ rằng bạn có thể đưa ra nhiều lỗi hơn. Hãy để deverloper phân tích kỹ lưỡng các test case để xây dựng lên một ứng dụng chất lượng. Điều này cũng sẽ tiết kiệm được nhiều thời gian làm việc.

Trong trường hợp này, bạn không nên phản bác ngay, mà thay vào đó hãy hỏi xem khách hàng không hài lòng ở điểm nào, muốn thay đổi như thế nào,… Từ đó, phân tích về nhu cầu của khách. Nếu việc thay đổi không mất quá nhiều thời gian, bạn vẫn có thể hỗ trợ để khuyến khích họ quay lại lần sau.

Lý do đặt câu hỏi: Đây là câu hỏi thể hiện sự quan tâm của bạn đối với vị trí mà đang ứng tuyển. Ngoài ra, câu hỏi này cũng giúp bạn hiểu rõ hơn về vai trò, những công việc mà mình sẽ làm khi trở thành nhân viên chính thức; phù hợp với khả năng và bạn có thể đáp ứng được hay không.  

Lý do đặt câu hỏi: Câu hỏi này sẽ giúp bạn hiểu rõ hơn về công ty, nhất là những khó khăn, thử thách, từ đó bạn sẽ định hướng được những việc cần làm để khắc phục những khó khăn đó; xem xét, cân nhắc mình đủ chuyên môn, kỹ năng, kinh nghiệm để vượt qua khó khăn hay không. 

Lý do đặt câu hỏi: Câu hỏi này sẽ giúp bạn biết được tầm quan trọng cũng như lộ trình thăng tiến của vị trí tester tại công ty như thế nào. Từ đây, bạn sẽ biết được mình cần nỗ lực ra sao, trau dồi kiến thức, kỹ năng gì để có thể đến được vị trí đó. 

• Anh/chị hãy cho em biết sau khi trúng tuyển thì công việc chính mà em đảm nhiệm trong công ty, doanh nghiệp của mình là gì?
• Công ty mình có định hướng riêng nào cho nhân viên tester mới vào công ty không ạ?
• Trong quá trình làm việc thì những khó khăn mà bộ phận tester của công ty mình thường gặp phải là gì?
• Theo em được biết thì thời gian này công ty đang tuyển mới rất nhiều tester, không biết đây là tuyển thêm cho dự án mới hay tuyển nhân viên để bù đắp vị trí còn trống trong công ty ?
• Công ty có kế hoạch đào tạo kiến thức cho nhân viên mới không và lộ trình đào tạo cụ thể như thế nào? 

• Giới thiệu tên, tuổi hay thông tin về nơi ứng viên theo học 
• Điểm mạnh, điểm yếu của bạn là gì? 
• Bạn có những điểm nào phù hợp với vị trí này? 

Với câu hỏi này, bạn nên giới thiệu ngắn gọn về Tên, tuổi. Ngoài ra, tóm tắt ngắn gọn về kinh nghiệm có liên quan đến vị trí Tester mà bạn đã làm. Bạn chỉ nên trả lời câu hỏi này trong 2 – 3 phút. Không nên trả lời quá dài bởi đây sẽ không phải là thông tin quá quan trọng mà nhà tuyển dụng quan tâm.

Bạn có thể nói cụ thể hơn về chuyên ngành mà bạn đã theo học không? Nó liên quan như thế nào đến công việc này? Tại sao bạn chọn công việc tester?

Bạn biết gì về công ty chúng tôi? Nếu công ty đầu tư tiền đào tạo bạn, bạn sẽ chọn những khóa học nào? Tại sao? 

Mục tiêu trong 5 tháng tới của bạn là gì? Bạn có mong muốn gì đối với công việc này? Bạn đã từng ra quyết định quan trọng nào trong quá khứ?