SDLC và STLC cơ bản: Quy trình tester phải nắm để đọc requirement
6 tháng trước · 12 phút đọc
SDLC là gì? Hiểu đúng trước khi làm tester
Mình nhớ tuần đầu làm tester, lead quăng cho một file requirement và bảo: "Em đọc spec theo SDLC nhé". Mình gật đầu nhưng trong bụng không biết SDLC là thứ gì. Đọc xong spec xong không hiểu mình cần test từ lúc nào, giai đoạn nào.
Nếu bạn đang ở chỗ đó, bình thường thôi. Không ai sinh ra đã biết.
SDLC - viết tắt của Software Development Life Cycle, tức vòng đời phát triển phần mềm - là toàn bộ quy trình từ lúc có ý tưởng làm app đến lúc app đó được deploy lên production và bảo trì.
Hình dung thế này: bạn muốn mở một quán cà phê. Bạn không thể sáng nay nghĩ ra, chiều mai khai trương. Bạn phải lên kế hoạch, thiết kế mặt bằng, mua nguyên liệu, training nhân viên, chạy thử, rồi mới mở cửa. Phần mềm cũng vậy - có quy trình rõ ràng từng bước.
SDLC thường có 6 giai đoạn chính:
- Planning (Lên kế hoạch): Xác định phạm vi dự án, nguồn lực, timeline
- Requirement Analysis (Phân tích yêu cầu): Thu thập và phân tích nhu cầu của khách hàng
- System Design (Thiết kế hệ thống): Kiến trúc kỹ thuật, database, UI mockup
- Implementation (Coding): Dev bắt đầu code
- Testing (Kiểm thử): Tester vào cuộc kiểm tra toàn bộ
- Deployment & Maintenance (Triển khai & Bảo trì): Release lên production, theo dõi và fix lỗi phát sinh
6 giai đoạn SDLC - tester tham gia sớm hơn bạn nghĩ
Vấn đề mà nhiều người trái ngành hay nghĩ sai: tester chỉ vào giai đoạn Testing. Thực tế không phải vậy. Tester tham gia từ giai đoạn Requirement Analysis - đọc spec, phân tích yêu cầu, phát hiện mâu thuẫn trong tài liệu trước khi dev code một dòng nào.
Tại sao phải vào sớm? Vì bug tìm thấy ở giai đoạn requirement thì sửa tốn 1 giờ thảo luận. Bug tìm thấy sau khi release thì sửa có thể tốn cả tuần - kéo theo dev, tester, QA lead, khách hàng cùng vào cuộc.
STLC là gì và khác SDLC chỗ nào?
Sau khi hiểu SDLC, câu hỏi tiếp theo là: STLC khác gì?
STLC - Software Testing Life Cycle - là quy trình riêng của đội testing, nằm bên trong SDLC. Nếu SDLC là toàn bộ vòng đời dự án, thì STLC là "vòng đời" riêng của team tester trong dự án đó.
Hai cái này không phải đối lập, mà STLC là một phần chạy song song và hỗ trợ SDLC.
STLC nằm trong SDLC - không phải hai quy trình tách rời
STLC gồm 6 giai đoạn:
| Giai đoạn STLC | Tester làm gì? |
|---|---|
| Requirement Analysis | Đọc spec, đặt câu hỏi, tìm điểm mơ hồ |
| Test Planning | Lên kế hoạch test: scope, resource, timeline |
| Test Case Development | Viết test case, chuẩn bị test data |
| Test Environment Setup | Chuẩn bị môi trường chạy test |
| Test Execution | Thực thi test case, ghi nhận kết quả |
| Test Cycle Closure | Tổng kết, báo cáo, rút kinh nghiệm |
Bước đầu tiên - Requirement Analysis - là bước nhiều tester mới hay bỏ qua vì nghĩ "chờ dev code xong mình mới cần làm gì đó". Sai hoàn toàn.
Mình từng làm project thương mại điện tử. Tester vào spec và phát hiện: requirement ghi "user có thể filter sản phẩm theo màu sắc" nhưng không có field màu sắc trong database design. Nếu chờ đến lúc dev code xong rồi mới phát hiện, cả team mất ít nhất 3 ngày sửa database + API + UI. Phát hiện lúc review spec thì chỉ mất 30 phút họp clarify.
Đó là lý do STLC bắt đầu sớm - không phải chờ code.
Vai trò tester trong từng giai đoạn SDLC
Bạn đang đọc requirement mà không biết mình cần làm gì ở từng giai đoạn? Phần này dành cho bạn.
Giai đoạn 1 - Planning
Tester chưa làm nhiều. Chủ yếu: nghe brief, hiểu phạm vi dự án, biết đây là app gì, user là ai. Đây là lúc hỏi "Dự án này team tester có mấy người? Deadline là khi nào?".
Giai đoạn 2 - Requirement Analysis
Giai đoạn quan trọng nhất với tester mới. Bạn phải đọc spec (tài liệu yêu cầu) và tìm:
- Yêu cầu mâu thuẫn nhau (ví dụ: trang 3 ghi "mật khẩu tối thiểu 8 ký tự", trang 12 ghi "tối thiểu 6 ký tự")
- Yêu cầu không rõ ràng (ví dụ: "giao diện phải thân thiện" - thân thiện là thế nào?)
- Yêu cầu thiếu (ví dụ: spec nói về màn hình đăng nhập nhưng không nói phải làm gì khi user nhập sai quá 5 lần)
Không cần biết code để làm bước này. Chỉ cần đọc kỹ và đặt câu hỏi.
Giai đoạn đọc requirement - tester phải đặt ít nhất 3-5 câu hỏi làm rõ
Giai đoạn 3 - System Design
Tester đọc tài liệu thiết kế (wireframe, mockup, database schema) để bắt đầu tư duy test case - chưa viết chính thức, nhưng trong đầu đã ghi chú "flow này cần test kỹ", "edge case ở đây là gì".
Giai đoạn 4 - Implementation (Dev đang code)
Tester viết test case chính thức, chuẩn bị test data, setup môi trường test. Đừng ngồi chờ dev bàn giao xong mới bắt đầu viết test case - đó là lãng phí thời gian.
Giai đoạn 5 - Testing
Thực thi test case. Ghi nhận kết quả. Báo cáo bug theo quy trình (thường dùng Jira hoặc Google Sheet). Làm kiểm thử hồi quy (regression testing) sau khi dev fix bug.
Giai đoạn 6 - Deployment & Maintenance
Tester hỗ trợ kiểm thử chấp nhận người dùng (UAT - User Acceptance Testing), theo dõi bug phát sinh sau release, phối hợp fix.
Tóm lại: tester không phải "người bấm nút xem có lỗi không". Tester là người đảm bảo chất lượng từ lúc dự án còn trên giấy.
Ví dụ thực tế: Dự án app đặt đồ ăn
Lý thuyết xong, mình lấy ví dụ cụ thể để bạn dễ hình dung. Giả sử team đang làm app đặt đồ ăn (kiểu như GrabFood).
SDLC của dự án này:
Planning: PM họp với khách hàng, xác định: app dành cho iOS và Android, có tính năng đặt hàng, thanh toán online, theo dõi đơn hàng. Deadline 4 tháng.
Requirement Analysis: BA (Business Analyst) viết spec. Tester đọc và phát hiện: spec ghi "user có thể hủy đơn" nhưng không nói rõ hủy được đến bước nào (trước khi nhà hàng nhận? Sau khi shipper lấy hàng rồi?). Đây là yêu cầu thiếu - tester phải raise ngay.
Design: Designer làm wireframe. Tester nhìn thấy luồng thanh toán và note: "Cần test case cho trường hợp mất kết nối giữa chừng khi đang thanh toán".
Ví dụ app đặt đồ ăn - luồng thanh toán luôn cần test edge case kỹ
Implementation: Dev code. Tester viết test case cho:
- Đặt hàng thành công (happy path)
- Chọn món nhưng nhà hàng đã hết (edge case)
- Thanh toán thất bại (invalid case)
- Mất kết nối khi đang xử lý đơn
Testing: Tester thực thi, phát hiện bug: khi mất kết nối giữa chừng lúc thanh toán, tiền bị trừ nhưng đơn hàng không được tạo. Bug nghiêm trọng - report ngay.
Deployment: Release. Tester phối hợp UAT với đội khách hàng. Theo dõi bug report từ user thật.
STLC diễn ra song song trong dự án này:
Trong khi dev đang code (tháng 2-3), tester không ngồi chờ. Tester đang ở giai đoạn Test Case Development và Test Environment Setup - chuẩn bị đầy đủ để khi dev bàn giao là test được ngay.
Nhiều bạn trái ngành hỏi mình: "Tester có cần học code không?" Qua ví dụ trên, bạn thấy: phần đọc requirement, phân tích yêu cầu, viết test case - không cần code. Cần logic, tỉ mỉ, và biết đặt câu hỏi đúng chỗ.
SDLC và STLC: So sánh để không nhầm lẫn
Sau khi đọc 3 phần trên, bạn có thể vẫn nhầm hai cái này. Mình tổng hợp một bảng so sánh nhanh:
| Tiêu chí | SDLC | STLC |
|---|---|---|
| Là gì? | Toàn bộ quy trình phát triển phần mềm | Quy trình kiểm thử riêng của team test |
| Ai tham gia? | PM, BA, Dev, Designer, Tester, DevOps | Tester, QA Lead, QC |
| Bắt đầu khi nào? | Từ lúc có ý tưởng/yêu cầu | Từ lúc có tài liệu requirement |
| Kết thúc khi nào? | Khi phần mềm ngừng hoạt động | Sau mỗi cycle release |
| Mục tiêu | Xây dựng phần mềm hoàn chỉnh | Đảm bảo chất lượng phần mềm |
Câu hỏi hay gặp:
"STLC nằm trong SDLC hay độc lập?" STLC nằm trong SDLC. STLC là phần testing của SDLC được chi tiết hóa thành quy trình riêng.
"Tester chỉ cần biết STLC, không cần biết SDLC?" Sai. Nếu không hiểu SDLC, tester không biết mình đang ở đâu trong dự án, không biết khi nào cần làm gì, và dễ bị động theo team dev thay vì chủ động chuẩn bị.
Hiểu cả hai giúp tester chủ động - không bị động chờ dev bàn giao
"Mô hình Agile thì SDLC và STLC có khác không?" Có khác về cách thực hiện. Agile chia thành sprint 2 tuần, SDLC và STLC chạy trong từng sprint thay vì tuần tự một lần duy nhất. Nhưng bản chất các giai đoạn vẫn tương tự - chỉ lặp lại nhanh hơn.
Thấy khó ở chỗ nào bạn cứ hỏi. Mình cũng mất khoảng 2-3 tuần đầu mới hình dung được mình cần làm gì ở từng giai đoạn. Không cần nhớ hết lý thuyết - quan trọng là biết: tester tham gia sớm, đọc kỹ requirement, đặt câu hỏi trước khi code chạy.
Bắt đầu từ đâu nếu bạn đang trái ngành?
Hiểu SDLC và STLC là bước đầu. Nhưng hiểu lý thuyết mà không thực hành thì 1 tuần sau quên sạch.
Mình gợi ý 3 bước làm ngay:
1. Tìm một requirement thật để đọc thử
Gõ Google "software requirements specification example" hoặc tải về template spec bên dưới. Đọc và thử tìm: có chỗ nào mơ hồ không? Có yêu cầu nào mâu thuẫn không? Làm quen với cảm giác đọc spec trước khi đi làm thật.
Tải template spec tham khảo: Tải template phân tích requirement cho tester
2. Map vào SDLC
Mỗi khi bạn dùng app (mua hàng online, đặt xe, chuyển khoản), thử tư duy: "App này đang ở giai đoạn nào của SDLC? Nếu mình là tester, mình sẽ test gì?"
Thói quen này giúp bạn tư duy như tester nhanh hơn học thuộc lòng định nghĩa.
3. Viết test case đầu tiên
Chọn một tính năng đơn giản - đăng nhập Facebook chẳng hạn. Viết ra 5-10 test case: đúng pass, sai pass, để trống email, email không tồn tại, nhập quá nhiều ký tự...
Bắt đầu từ thứ quen thuộc - đăng nhập Facebook có nhiều test case hơn bạn nghĩ
Bạn không cần tool đặc biệt - Google Sheet là đủ để viết test case đầu tiên.
Nếu muốn hệ thống hóa kiến thức IT nền tảng trước khi đi sâu vào testing, khóa Kiến Thức Nhập Môn IT trên F8 là điểm bắt đầu tốt - miễn phí, giải thích các khái niệm cơ bản dễ hiểu cho người mới.
Testing không khó. Khó là giữ được thói quen tỉ mỉ trong từng test case, từng bug report, từng lần review spec. Mỗi lần bạn tìm ra yêu cầu mâu thuẫn trước khi dev code, bạn vừa giúp team tiết kiệm được hàng giờ.
Test kỹ một lần hơn fix lỗi nhiều lần. Comment bên dưới nếu bạn đang thắc mắc chỗ nào nhé!