Dù là 1 developer, bạn cũng nên "đóng vai" 1 tester

English version: https://dev.to/doantrongnam/as-a-developer-sometimes-you-should-play-the-role-of-a-tester-247h
Tại sao tôi lại nói developer nên đóng vai tester?

"Đóng vai một tester" ở đây không có nghĩa là chỉ test. Vì đương nhiên đã code là phải test lại rồi. Mà "đóng vai" ở đây nghĩa là bạn phải tiếp cận bài toán với lối tư duy của 1 tester. Gần đây ở team dự án tôi đang tham gia đã thêm 1 bước vào luồng làm việc của developer. Chúng tôi phải viết file test case (trước đó đã cần rồi), quay video hoặc chụp ảnh màn hình để chứng minh mình đã test, và chị tester sẽ review file test case đó trước khi chúng tôi đưa pull request cho leader review. Có lẽ có người sẽ thấy như vậy là thừa thãi, mất thời gian, vì "code thôi đã mệt lắm rồi". Nhưng tôi lại cho đó là một việc cần thiết.

Thứ nhất là đối với dự án, nó giúp chất lượng đầu ra được đảm bảo hơn.
Thứ hai là đối với cá nhân developer, tôi thấy mình được trang bị thêm nhiều kỹ năng, tư duy để phát triển bản thân.

Đó cũng là lúc tôi thấy tầm quan trọng của việc đóng vai tester. Vậy làm sao để 1 developer - người luôn tìm cách xây dựng lại có thể mang tư duy của 1 tester - người luôn tìm cách phá?

1. Bỏ ngay cái suy nghĩ: "Người dùng không thao tác nhảm nhí thế đâu"

Đa phần developer luôn mang tư duy là "happy case first". Nghĩa là chúng ta luôn xây dựng từ case thành công của tính năng trước, sau đó mới tính đến những ngoại lệ như validation, bên thứ 3 trả lỗi, ... Còn tester, họ luôn nghĩ từ case lỗi trước. Nào là nhập số âm vào input tiền, nhập ngày 31/2 vào trường date, rồi cả ti tỉ thứ mà chúng ta cho là ngu si. Đa phần tester ở Việt Nam là phụ nữ. Và tôi hay đùa rằng bởi vì phụ nữ thì cái quái gì cũng có thể nghĩ ra nên họ mới đi làm tester =))) Sự tương phản giữa developer và tester Chính vì sự trái ngược này, mà đôi khi chúng ta bỏ qua những case oái oăm một chút. Thử nghĩ xem nếu bạn tiếp cận bài toán như một tester, bạn đã có thể cover nhiều edge case hơn và chặn chúng từ trong trứng nước. Hơn nữa cũng tránh được những tranh luận không đáng có giữa 2 phía mà sứt mẻ tình cảm :v

2. Hãy test cả những phần liên quan, dù bạn biết 100% mình không đụng vào phần code trước đó

Yeah, đôi khi những gì bạn biết là chắc chắn, thì lại là không chắc chắn. Đã có yếu tố con người thì lại càng khó đạt được 100% tuyệt đối. Ai mà biết được bạn không sửa nhầm vào util, hoặc 1 hàm nào được export ra để sử dụng ở nơi khác. Ai mà biết được bạn đã kiểm tra xem cái API bạn sửa được gọi ở những màn hình nào. War Đôi khi bạn còn chẳng tin tưởng chính mình, nên đừng hỏi tại sao tester không tin bạn =)) Lúc còn thực tập tôi cũng từng tranh luận nửa tiếng đồng hồ với 2 bạn tester chỉ vì bị 2 bạn ấy yêu cầu test cả những phần liên quan. Tôi thì khẳng định mình không sửa gì vào phần đó, nếu có lỗi thì cũng là do người khác. Sau này khi nghĩ lại thì nếu tôi dành thời gian tranh luận đó để test thì cũng xong mịa rồi :v. Mà kể cả nếu phát hiện ra lỗi không phải do mình thì cũng có sao đâu??? Như vậy cũng giúp dự án tốt lên mà.

3. Nếu được, hãy viết test case

Nếu có thời gian, hãy viết test case vào google sheet hay excel như tester thường làm. Self-test là 1 quy trình không thể bỏ của việc phát triển phần mềm. Tưởng tượng mỗi lần fix xong 1 bug mà đội kiểm thử báo cáo, bạn lại cần tự manual test lại 1 luồng đầy đủ nghiệp vụ ứng với phạm vi task của bạn. Nếu bạn đã viết cần thận test case trước đó, thì việc self-test sau mỗi lần sẽ được thực hiện nhanh hơn và đảm bảo hơn. Một file test case tốt thì cần bao gồm:

ID hoặc số thứ tự
Mô tả
Điều kiện tiên quyết
Các bước tái hiện
Kết quả mong muốn
Lịch sử test

4. Hãy tìm hiểu 1 chút về bảo mật

Là 1 developer, bạn không cần phải có đầy đủ kỹ năng như 1 chuyên gia an ninh. Tuy nhiên bạn cần nắm 1 vài kỹ thuật cơ bản để tự bảo vệ trang web của mình.

Kết luận

Peace Đôi khi tester chỉ đang làm nhiệm vụ của họ. Cũng giống như chúng ta, họ cũng giúp sản phẩm cuối cùng trở nên hoàn hảo nhất có thể. Nhưng đôi khi chúng ta lại nghĩ họ đang bắt lỗi mình. No no, ở đây không có ai công kích cá nhân ai cả. Mâu thuẫn giữa developer và tester là chủ đề muôn thuở. Nếu mỗi bên biết đặt mình vào vị trí đối phương, cũng như hạ cái tôi xuống, thì sẽ tránh được những xung đột không đáng có. Peace I'm out.