SDLC và STLC cho người mới: Tester cần hiểu gì trước khi xin việc
4 tháng trước · 10 phút đọc
SDLC là gì và tester liên quan thế nào?
SDLC - Software Development Life Cycle, hay chu kỳ phát triển phần mềm - là quy trình mà một phần mềm đi qua từ lúc có ý tưởng cho đến khi phát hành và bảo trì. Nghe có vẻ vĩ mô, nhưng thật ra đây là thứ bạn sẽ nghe nhắc đến mỗi ngày khi đi làm.
SDLC thường gồm 6 giai đoạn chính:
- Planning (Lập kế hoạch): Xác định phạm vi, chi phí, thời gian dự án
- Requirement Analysis (Phân tích yêu cầu): Thu thập và làm rõ yêu cầu từ khách hàng
- Design (Thiết kế): Kiến trúc hệ thống, database, UI/UX
- Development (Phát triển): Dev viết code
- Testing (Kiểm thử): Tester tìm bug trước khi release
- Deployment & Maintenance (Triển khai & Bảo trì): Đưa lên production, xử lý vấn đề sau release
Tester xuất hiện chính ở giai đoạn Testing, nhưng thật ra tham gia sớm hơn nhiều
Nhiều bạn mới nghĩ tester chỉ làm ở giai đoạn Testing. Sai. Tester tốt tham gia từ giai đoạn Requirement Analysis - đọc requirement, đặt câu hỏi làm rõ, phát hiện mâu thuẫn logic trước khi dev viết một dòng code nào. Phát hiện lỗi requirement sớm rẻ hơn phát hiện bug production gấp 100 lần chênh lệch chi phí (fix ở requirements/design vs production/field: khoảng $100 so với $10,000, theo nguồn trích dẫn IBM SSI) (IBM Systems Sciences Institute (as cited by CloudQA / ContextQA)) lần.
Ở giai đoạn Design, tester cũng bắt đầu lên kế hoạch test (test plan) dựa trên tài liệu thiết kế. Đến giai đoạn Development thì viết test case chi tiết. Đây là lý do khi phỏng vấn hỏi 'bạn tham gia SDLC ở đâu?', câu trả lời không phải chỉ là 'giai đoạn testing'.
STLC là gì và khác SDLC ở điểm nào?
STLC - Software Testing Life Cycle, hay chu kỳ kiểm thử phần mềm - là quy trình riêng bên trong giai đoạn Testing của SDLC. Nếu SDLC là bức tranh toàn cảnh của cả dự án, thì STLC là bức tranh chi tiết của riêng phần testing.
Một câu hỏi phỏng vấn rất phổ biến: "SDLC và STLC khác nhau thế nào?" Bạn trả lời được câu này là đã ghi điểm rồi.
STLC nằm bên trong SDLC - đây là phần tester làm chủ hoàn toàn
STLC gồm 6 giai đoạn:
1. Requirement Analysis (Phân tích yêu cầu) Tester đọc tài liệu requirement, đánh dấu các điểm chưa rõ, lên danh sách câu hỏi cần làm rõ. Đầu ra: Requirement Traceability Matrix (RTM) - bảng mapping từng yêu cầu với test case tương ứng.
2. Test Planning (Lập kế hoạch kiểm thử) Xác định phạm vi test, phân bổ nguồn lực, chọn công cụ, ước tính thời gian. Đầu ra: Test Plan document.
3. Test Case Development (Viết test case) Viết chi tiết từng test case và test data. Đầu ra: Test Cases, Test Scripts.
4. Test Environment Setup (Cài đặt môi trường) Chuẩn bị server, database, tài khoản test... Đầu ra: Môi trường test sẵn sàng.
5. Test Execution (Thực thi kiểm thử) Chạy test case, ghi nhận kết quả, báo cáo bug. Đầu ra: Bug reports, Test execution reports.
6. Test Cycle Closure (Kết thúc kiểm thử) Tổng kết kết quả, đánh giá chất lượng, lưu lại lessons learned. Đầu ra: Test closure report.
Như vậy, mỗi giai đoạn đều có đầu vào (input) rõ ràng và đầu ra (output) cụ thể. Mình nhấn mạnh điều này vì khi đi làm, sếp hỏi 'bạn đang ở bước nào, output là gì?' - nếu biết STLC thì trả lời ngay được mà không cần nghĩ lâu.
So sánh nhanh SDLC và STLC
Bảng này là thứ bạn nên nhớ kỹ trước khi đi phỏng vấn:
| Tiêu chí | SDLC | STLC |
|---|---|---|
| Phạm vi | Toàn bộ dự án phần mềm | Chỉ riêng phần kiểm thử |
| Ai tham gia | PM, BA, Dev, Tester, Designer | Chủ yếu Tester và QA |
| Mục tiêu | Tạo ra phần mềm hoàn chỉnh | Đảm bảo phần mềm không có lỗi |
| Kết thúc khi | Phần mềm được deploy | Test cycle hoàn thành |
| STLC nằm ở đâu | Giai đoạn Testing trong SDLC | Là chi tiết hóa của giai đoạn đó |
SDLC bao phủ toàn dự án, STLC là quy trình riêng của tester bên trong
Một điểm hay bị nhầm: STLC không chỉ bắt đầu khi dev xong code. Requirement Analysis trong STLC bắt đầu song song với Requirement Analysis trong SDLC - tức là tester đọc requirement cùng lúc với BA và dev, không phải ngồi chờ.
Tại sao quan trọng? Vì nếu tester đọc requirement sớm, phát hiện được những chỗ mâu thuẫn như 'requirement nói user có thể upload ảnh tối đa 5MB, nhưng phần khác lại nói 10MB' - fix ngay lúc này mất 5 phút. Để đến lúc dev code xong mới phát hiện thì mất vài ngày.
Tester tham gia SDLC ở đâu - chi tiết hơn
Câu hỏi phỏng vấn thực tế mình từng gặp: "Bạn mô tả vai trò tester trong từng giai đoạn SDLC?" Không ít bạn trả lời chỉ có giai đoạn Testing - và rớt. Dưới đây là câu trả lời đúng:
Planning: Tester đọc project scope, ước tính effort cho testing, đề xuất ngân sách và timeline cho test activities.
Requirement Analysis: Đây là giai đoạn cực kỳ quan trọng. Tester đọc kỹ requirement, tìm điểm mơ hồ, đặt câu hỏi với BA hoặc Product Owner. Ví dụ: requirement nói 'hệ thống phải nhanh' - nhanh là bao nhiêu giây? Tester phải hỏi và ghi rõ, vì đây sẽ là tiêu chuẩn để test performance sau này.
Design: Tester review tài liệu thiết kế, bắt đầu viết test plan và high-level test cases dựa trên flow đã được thiết kế.
Development: Viết test case chi tiết, chuẩn bị test data, cài đặt môi trường test.
Testing: Thực thi test, report bug, retest khi dev fix, chạy kiểm thử hồi quy (regression testing) đảm bảo fix mới không làm hỏng tính năng cũ.
Deployment: Tham gia UAT (User Acceptance Testing) - kiểm thử chấp nhận người dùng - và smoke testing sau khi deploy lên production.
Tester giỏi là người đặt câu hỏi từ sớm, không phải chỉ click test cuối sprint
Thấy không? Tester tham gia gần như toàn bộ SDLC. Không phải 'người ngồi chờ dev code xong rồi click'. Khi hiểu điều này, bạn sẽ tự tin hơn rất nhiều khi trình bày về vai trò của mình.
Đầu vào và đầu ra của mỗi giai đoạn STLC
Hiểu input/output của từng giai đoạn STLC giúp bạn biết mình cần tài liệu gì để bắt đầu và phải tạo ra gì khi xong. Thực tế rất nhiều tester mới không biết điều này, làm việc theo phản xạ mà không hiểu tại sao.
| Giai đoạn | Đầu vào (Input) | Đầu ra (Output) |
|---|---|---|
| Requirement Analysis | Requirement docs, use cases | RTM (Requirement Traceability Matrix), danh sách câu hỏi |
| Test Planning | RTM, requirement, lịch dự án | Test Plan document |
| Test Case Development | Test Plan, requirement, design docs | Test cases, test data, test scripts |
| Test Environment Setup | Test Plan, architecture docs | Môi trường test sẵn sàng, test data cài đặt xong |
| Test Execution | Test cases, test environment, build mới nhất | Bug reports, test execution report |
| Test Cycle Closure | Tất cả báo cáo trước đó | Test closure report, metrics, lessons learned |
Mỗi giai đoạn có output cụ thể - đây là cách chứng minh bạn đã làm đủ
Mình nhớ lần đầu được giao 'chuẩn bị test environment', mình không biết output là gì nên chỉ cài xong là báo sếp 'xong rồi'. Sếp hỏi: 'Test data đã import chưa? Tài khoản test đã tạo chưa? Checklist environment đâu?' - mình đứng hình.
Tải checklist này để không bị hỏng: Tải checklist chuẩn bị test environment
Bài học: mỗi giai đoạn phải có output rõ ràng, không phải chỉ 'làm xong'. Khi bạn biết output cần có, bạn sẽ chủ động hơn và không bị sếp nhắc nhở.
Đọc requirement tốt hơn nhờ hiểu SDLC và STLC
Đây là ứng dụng thực tế nhất mà ít ai giải thích cho người mới.
Khi bạn hiểu SDLC, bạn biết requirement là đầu vào của cả dự án - nếu requirement sai thì cả dây chuyền sau sai theo. Tester đọc requirement không chỉ để viết test case, mà còn để giữ chất lượng từ đầu.
Khi đọc một trang requirement, hãy đặt những câu hỏi này:
- Có trường hợp nào chưa được đề cập không? Ví dụ: requirement nói luồng đăng ký thành công, nhưng không nói user nhập email đã tồn tại thì hiển thị thông báo gì?
- Điều kiện biên là gì? Ô nhập số lượng cho phép nhập tối đa bao nhiêu? Có cho phép số âm không?
- Hành vi khi lỗi mạng? Nếu user đang thanh toán mà mạng đứt, hệ thống xử lý thế nào?
- Có mâu thuẫn giữa các phần không? Một chỗ nói 'admin có thể xóa user', chỗ khác nói 'chỉ super admin mới xóa được' - cái nào đúng?
Đọc requirement như tester - tìm lỗ hổng trước khi dev code
Nhiều bạn mới trái ngành lo lắng 'mình không biết kỹ thuật thì đọc requirement có hiểu không?' Bình thường thôi, không cần biết code mới đọc được requirement. Requirement viết bằng ngôn ngữ nghiệp vụ, không phải ngôn ngữ lập trình. Thứ bạn cần là tư duy logic và sự tỉ mỉ - hai thứ này rèn được.
Mình từng có học viên 32 tuổi từ ngành kế toán chuyển sang, đọc requirement rất tốt vì quen xử lý số liệu chi tiết. Kỹ năng từ nghề cũ không bỏ đi, chỉ cần áp dụng đúng chỗ.