Self-Testing by Developers? Tại sao không?
Việc developer self test giống như kiểm tra túi của mình trước khi ra khỏi nhà!
Có rất nhiều quan điểm trái ngược khác nhau về software testing. Sau đây là vài lý do phổ biến nhất mà các developer đưa ra để không phải test software.
Nhưng mà, tôi không biết test cái gì bây giờ?!
Testing vừa khó khăn vừa khó hiểu
Testing khiến kéo dài thời gian phát triển 🙁
Code của tôi chạy hoàn hảo. Sao tôi phải test?
1. Developer self-testing khác với Tester
| Developer self-testing | Tester |
|---|---|
| Đảm bảo tính năng mới được tích hợp vào hệ thống thành công. | Từ góc độ của tất cả người dùng và góc độ kinh doanh, xem xét mọi khả năng tích cực và tiêu cực có thể xảy ra. |
| Chắc chắn rằng có đang làm đúng theo yêu cầu chức năng. | Kiển tra tích hợp (các module có chạy chính xác hay không) |
2. Một số khái niệm cần biết
| Happy paths | error paths |
|---|---|
| Happy paths (Positive testing): là quá trình chạy 1 kịch bản kiểm thử chỉ với dữ liệu đúng và hợp lệ. | Error path (Negative testing): kiểm tra xem một ứng dụng có hoạt động như mong đợi với các đầu vào không hợp lệ hay không. |
| Ví dụ: màn hình đăng nhập với 2 trường bắt buộc email và password: | |
 |
- Happy path: người dùng cung cấp thông tin đăng nhập chính xác, họ sẽ được điều hướng đến màn hình tiếp theo để thực hiện các hành động tiếp theo.
- Error paths: người dùng cung cấp thông tin đăng nhập không chính xác (để trống trường bắt buộc, nhập email sai định dạng, nhập Space, nhập chứa dấu cách ở đầu và cuối, nhập dạng ký tự full-width, half-width, nhập số, ký tự đặc biệt...)
3. Một số gợi ý cho Deverloper self-testing
- Test mọi trường hợp phổ biến nhất có thể.
- Test những trường hợp nổi cộm có dính đến những đoạn code phức tạp mà tác giả nghĩ rằng có thể xảy ra lỗi
- Khi tìm thấy một lỗi, hãy viết test case lại trước khi fix nó. (Để sau này dùng automation testing hoặc tester dùng)
Hoặc hãy thử theo các steps dưới đây:
- Chia chức năng thành nhiều phần nhỏ để test
- Với mỗi phần đã chia:
- Dựa trên các thông số, tài liệu viết ra “happy paths”
- Viết các giá trị biên dựa trên tài liệu cung cấp
- Viết ra mọi path “crazy” có thể nghĩ ra.
- Suy nghĩ về sự ảnh hưởng lẫn nhau của các chức năng và đến hệ thống.
4. Ưu điểm và nhược điểm:
| Ưu điểm | Nhược điểm |
|---|---|
| Giảm thiểu được "double work" ➞ tiết kiệm thời gian Giảm bugs Ngăn chặn defect Nâng cao chất lượng code Có một cách nhìn mới về code của chính bản thân, từ đó có những hướng giải quyết tốt hơn Biết được điểm nào bản thân cần cải thiện |
Tốn thời gian hơn |
Hy vọng bài viết đem lại động lực hơn cho các developer trong việc self-test.
Cảm ơn bạn đã đọc bài viết này, hoan nghênh nhận xét của các bạn.