Bridge System Engineer (Japanese N2)

Bắt đầu từ hiểu hiện trạng và rủi ro, rồi cải thiện từng bước thay vì áp nguyên một quy trình nặng.

• Tuần đầu: tìm hiểu sản phẩm, luồng nghiệp vụ chính, lịch sử bug sau release, cách team đang làm việc.
• Nền tảng: thống nhất quy trình bug (template, severity, vòng đời ticket), Definition of Done có bước test, môi trường test tách khỏi production.
• Shift-left: tham gia refinement để làm rõ acceptance criteria trước khi code.
• Phủ test: bộ smoke cho luồng quan trọng, sau đó automation dần (ưu tiên API), đưa vào CI.
• Đo lường: số bug lọt ra production, thời gian xử lý bug, độ phủ regression, để chứng minh hiệu quả.

Người phỏng vấn muốn nghe: bạn biết ưu tiên, làm việc với dev chứ không đứng ngoài "bắt lỗi", và đo được kết quả.

QA (Quality Assurance) lo quy trình để lỗi ít xảy ra ngay từ đầu; QC (Quality Control) kiểm tra sản phẩm để tìm lỗi đã xảy ra. Testing là một hoạt động chính của QC.

• QA: review requirement, đặt chuẩn Definition of Done, checklist review code, quy trình release.
• QC: viết và chạy test case, log bug, verify fix, regression.
• Thực tế ở Việt Nam, chức danh "QA" thường làm cả hai, nhưng phần lớn thời gian là QC.

Người phỏng vấn muốn nghe: bạn hiểu khái niệm và kể được việc cụ thể mình làm, ví dụ "Em tham gia review user story từ sprint planning để hỏi rõ acceptance criteria, rồi mới viết test case".

Chia theo nhóm để không sót, rồi áp dụng kỹ thuật thiết kế test.

• Chức năng: đúng email/mật khẩu; sai mật khẩu; email chưa đăng ký; để trống từng trường.
• Phân vùng tương đương & giá trị biên: độ dài mật khẩu ở min-1, min, max, max+1; email sai định dạng.
• Bảo mật: khoá tài khoản sau N lần sai, mật khẩu bị che, thông báo lỗi không tiết lộ email có tồn tại hay không, thử ký tự đặc biệt/SQL injection cơ bản.
• UI/UX: nhấn Enter để submit, tab order, hiện/ẩn mật khẩu, thông báo lỗi rõ ràng.
• Khác: "Ghi nhớ đăng nhập", session hết hạn, nhiều trình duyệt/thiết bị.

Hay sai: chỉ liệt kê case happy path, hoặc liệt kê lan man không có nhóm. Nên nói thêm mỗi test case gồm: tiền điều kiện, các bước, dữ liệu, kết quả mong đợi.

OSI có 7 tầng: Physical, Data Link, Network, Transport, Session, Presentation, Application. Thực tế người ta hay dùng mô hình TCP/IP 4 tầng, nhưng vẫn gọi tên theo OSI.

• Switch (L2): chuyển frame theo địa chỉ MAC; switch L3 có thêm định tuyến.
• Router (L3): định tuyến gói theo địa chỉ IP giữa các mạng.
• Firewall: lọc ở L3/L4 (IP, port); firewall thế hệ mới đọc được tới L7 (ứng dụng, URL).
• TCP/UDP ở L4; HTTP, DNS ở L7.

Người phỏng vấn muốn nghe: dùng OSI để khoanh vùng sự cố, ví dụ "ping được nhưng không mở được web" là vấn đề từ L4 trở lên.

TCP có kết nối (bắt tay 3 bước), đảm bảo thứ tự và gửi lại gói mất; UDP không kết nối, không đảm bảo, nhưng nhẹ và độ trễ thấp.

• TCP: HTTP/HTTPS (trừ HTTP/3), SSH (22), SMTP, RDP, database.
• UDP: DNS (53, chuyển sang TCP khi trả lời lớn), DHCP (67/68), NTP (123), VoIP, game, video call.
• HTTP/3 chạy trên QUIC, mà QUIC dựa trên UDP.

Hay sai: chỉ mở TCP 53 hoặc UDP 53 trên firewall cho DNS server; nên mở cả hai.

Bug report tốt giúp dev tái hiện được ngay mà không cần hỏi lại.

• Tiêu đề ngắn, nói rõ chỗ lỗi và hiện tượng.
• Môi trường: build/version, trình duyệt hoặc thiết bị, tài khoản test.
• Các bước tái hiện, kết quả thực tế, kết quả mong đợi.
• Bằng chứng: ảnh, video, log, request/response.
• Severity, Priority, tần suất (luôn xảy ra hay thỉnh thoảng).

Severity là mức ảnh hưởng kỹ thuật (crash, mất dữ liệu là Critical). Priority là mức gấp cần sửa theo góc nhìn business. Ví dụ: logo sai màu ở trang chủ có severity thấp nhưng priority cao trước buổi demo khách hàng; app crash ở một màn hình gần như không ai dùng có severity cao nhưng priority có thể thấp hơn.

Hay sai: tự đặt Priority thay cho PO/PM mà không trao đổi.

Ba loại này khác nhau ở mục đích và phạm vi.

• Smoke test: chạy nhanh các luồng chính ngay khi có build mới để quyết định build có đủ ổn để test tiếp không. Rộng nhưng nông.
• Sanity test: sau khi sửa một bug hay thay đổi nhỏ, kiểm tra nhanh đúng chỗ đó và vùng liên quan. Hẹp nhưng sâu.
• Regression test: kiểm tra lại các chức năng đã chạy đúng để chắc thay đổi mới không làm hỏng chúng. Phạm vi lớn nhất, hợp để automation.

Ví dụ trả lời: "Ở dự án trước, mỗi build lên môi trường test em chạy bộ smoke khoảng 20 case trong 15 phút. Fix bug thì sanity phần liên quan. Trước release cả team chạy regression, phần lặp lại đã được automation."

Người phỏng vấn muốn nghe: ví dụ thực tế từ dự án của bạn, không chỉ định nghĩa.

Đừng đợi tài liệu hoàn hảo; chủ động làm rõ và ghi lại giả định.

• Đặt câu hỏi cụ thể cho BA/PO ngay từ lúc refinement, ưu tiên những chỗ ảnh hưởng tới acceptance criteria.
• Tham khảo nguồn khác: bản thiết kế UI, hệ thống cũ, sản phẩm tương tự, hỏi dev về logic đã code.
• Viết test scenario ở mức cao trước, ghi rõ giả định, gửi lại cho BA/PO xác nhận.
• Kết hợp exploratory testing theo session có mục tiêu và ghi chú.
• Chỗ chưa rõ thì log thành câu hỏi/ticket thay vì tự quyết là bug hay không.

Người phỏng vấn muốn nghe: bạn chủ động và minh bạch. Ví dụ: "Em gửi danh sách 8 câu hỏi kèm giả định, PO trả lời 6, 2 câu còn lại em đánh dấu là rủi ro trong test report."

DHCP gồm 4 bước DORA: Discover (máy phát broadcast tìm server), Offer (server đề nghị IP), Request (máy xin IP đó), Acknowledge (server xác nhận, kèm gateway, DNS, thời hạn lease).

IP 169.254.x.x (APIPA) nghĩa là máy không liên lạc được DHCP server. Kiểm tra:

• Cáp, cổng switch, Wi-Fi có kết nối không.
• Cổng switch có đúng VLAN không.
• DHCP server còn chạy, scope còn IP trống không.
• Khác VLAN thì router/switch L3 đã cấu hình DHCP relay (ip helper-address) chưa.

Người phỏng vấn muốn nghe: đi từ tầng vật lý lên, không vội cài lại máy.

Cho thấy bạn có cách làm cụ thể, không chỉ nói "em chịu được áp lực".

• Chia nhỏ việc, ưu tiên phần quan trọng nhất cho mục tiêu.
• Báo sớm cho lead/PM nếu thấy không kịp, đề xuất cắt phạm vi hoặc xin hỗ trợ.
• Giữ chất lượng ở phần cốt lõi; ghi lại nợ kỹ thuật để xử lý sau.
• Giữ bình tĩnh, giao tiếp ngắn gọn, rõ ràng với team.

Câu mẫu theo STAR: "Trước buổi demo cho khách, team phát hiện lỗi tích hợp chỉ còn hai ngày. Em liệt kê các phần bị ảnh hưởng, cùng PM chọn luồng nào bắt buộc phải chạy cho demo, phần còn lại hẹn bàn giao tuần sau. Demo diễn ra suôn sẻ và khách đồng ý với lịch mới."

Hay sai: khoe thức trắng nhiều đêm. Người phỏng vấn muốn thấy bạn quản lý được áp lực, không chỉ chịu đựng.