Theo bạn lập trình viên có phải kiểm thử code của họ không?

September 14, 2021 0 By Nam Vu

Bài viết trước đó mình có đề cập đến quy trình phát triển phần mềm với Agile, bạn đọc có thể xem lại tại đây

Nếu bạn là 1 lập trình viên freelancer có thể bạn sẽ phải cân hết cả vấn đề kiểm thử trong một sản phẩm phần mềm. Tuy nhiên, mọi thứ lại được chuyên môn hóa trong các công ty phần mềm, khi này sẽ sinh ra những đội nhóm chuyên kiểm thử phần mềm như QC hay Tester.

Thế rồi một ngày đẹp trời, anh lập trình viên X dựa hết tất cả công việc kiểm thử đó cho đội nhóm kia, tặc lưỡi nói rằng “Cứ code xong là đẩy cho Tester kiểm tra thôi, có lỗi họ tức khắc quẳng về lại cho mình lúc đó fix tiếp!”

Bạn là một lập trình viên bạn có từng rời vào trường hợp đó chưa?

Bạn là Tester bạn đã từng gặp những anh chàng coder như vậy chưa?

Để bàn luận tính đúng sai thì mình liệt kê lại các bước mà một lập trình viên phải làm trong một dự án nhé.

1. Phân tích yêu cầu được giao là làm cái gì, đầu vào là gì, cần đầu ra như thế nào, các tính năng cụ thể ra sao
2. Đánh giá tại sao cần chức năng đó, tính đúng đắn của chức năng đó, độ phức tạp cũng như thứ tự ưu tiên của ticket đó
3. Đưa ra giải pháp thực thi chức năng đó, những bước hay task cần làm, có cần tích hợp với thành phần hay bộ phận nào để hoàn thành nó không
4. Thực hiện hóa chức năng mình đảm nhận và viết unit test cho từng thành phần nhỏ bên trong
5. Chắc chắn rằng mọi thứ hoạt động giống như mô tả, yêu cầu phân tích trước đó.
6. Bàn giao chức năng đã thực thi

Nếu để ý thì bạn sẽ thấy bước thứ 5 sẽ là bước kiểm tra lại sản phẩm của bạn nó được gọi với cái tên không mấy đẹp đẽ là smoke test

Bước này bạn sẽ phải đảm bảo rằng chức năng của bạn phải pass qua happy case hay một số trường hợp cơ bản cần phải có để chắc chắn rằng chức năng của bạn gọi là ổn trước đã. Thường thì bộ test case smoke test sẽ được tester liệt ke trước cho bạn để bạn chạy trên môi trường của bạn và môi trường deploy bàn giao cho đội ngũ kiểm thử xem có đúng như mong đợi không rồi họ mới nhận bàn giao. Tỉ lệ số test case cần smoke test thì tùy theo dự án hay công ty nhưng mà thường không quá 30% số test case để đảm bảo dev có đủ thời gian chạy sơ bộ nhưng mà cũng không mất quá nhiều thời gian của họ vì dù sao công việc chính của họ là code chứ không phải kiểm thử.

Thế rồi bạn sẽ đọc ở đâu đó có một thuật ngữ là TDD (Test Driven Development), tư duy này thì bạn lại hiểu là thực hiện chức năng theo bộ test case có sẵn thay vì mô tả yêu cầu chức năng. Khi này chỉ cần đúng đầu vào và đầu ra của bộ test case là được. Việc này sẽ chính xác sẽ nằm trong bước 3 bên trên.

Một vấn đề nữa là bạn sẽ hỏi tại sao tôi chỉ đảm nhận thực hiện hóa chức năng mà tại sao tôi phải kiểm thử nữa. Điều này không ít anh em thắc mắc. Tuy nhiên dù bạn có cắt bớt công đoạn kiểm tra phía bạn thì khi bàn giao cho đội ngũ kiểm thử mà họ thấy lỗi thì bạn cũng sẽ là người phải xử lý mà thôi. Vậy bạn nghĩ thời gian chuyển qua chuyển lại như vậy có tốn thời gian của cả 2 bên không? Đằng nào chẳng đến tay mình, cứ nhây nhây chuyền banh như vậy liệu rằng bạn có thực sự chuyên nghiệp, hơn nữa lại gây rất nhiều ức chế cho đội ngũ kiểm thử. Đặt mình vào vị trí của họ xem cảm giác thế nào khi vừa đặt tay chạy thì lỗi ngay từ trường hợp đơn giản nhất. Mà một khi họ đã ghét rồi thì lại chính bạn là người chịu khổ chứ ai, họ là gate cuối để bàn giao cho khách hàng mà, không qua gate của họ thì việc bạn đảm nhận cũng chưa được coi là hoàn thành. Rồi bạn nghĩ sao khi sếp lại hỏi về tiến độ, lại đổ thừa cho nhau ạ 😄