- vừa được xem lúc

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

0 0 12

Người đăng: Nam Đoàn

Theo Viblo Asia

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.

Bài viết tham khảo:

Bình luận

Bài viết tương tự

- vừa được xem lúc

Kỹ thuật Estimate kiểm thử phần mềm: Hướng dẫn chi tiết

Thế nào là Estimate kiểm thử phần mềm. Tại sao cần Estimation. . Estimate cái gì.

0 0 396

- vừa được xem lúc

[Chất lượng phần mềm] Các phép đo trong dự án phần mềm (Software Metrics)

Các phép đo trong dự án phần mềm là công cụ dể biểu diễn khối lượng, số lượng, hoặc thuộc tính chất lượng của một sản phẩm, hoặc một quy trình tạo ra sản phẩm phần mềm. Nguyên lý của các phép đo trong

0 0 9

- vừa được xem lúc

Mình tự học lập trình từ con số 0 như thế nào?

Hành trình tự học lập trình. -----Xin chào các bạn mình tên là Vinh, hiện tại đang là một lập trình viên, thật ra thì chủ đề này khá củ rồi nhưng với mình thì hành trình học tập cũng mõi người là một

0 0 43

- vừa được xem lúc

Chóng covid cùng Neo4j??‍? ❌ ?

Lời nói đầu. -----Xin chào các bạn mình tên là Vinh, hiện tại đang là một lập trình viên Nodejs.

0 0 65

- vừa được xem lúc

IT nói "KHÔNG" trong công việc liệu có tốt không ?

Trong vòng gần 2 năm qua mình đã đi làm ở một công ty IT mảng về product. Nói không khiến ta cảm thấy mình có lỗi với người đối diện, người giao việc, khiến mình cảm thấy mình vô dụng.

0 0 45

- vừa được xem lúc

Phân biệt giữa Front End, Back End và Full Stack

Giới thiệu:. Bạn có bao giờ tự hỏi mình rằng: Sau này mình sẽ làm gì? Làm web? Làm Front hay Back ? Và đã chọn rồi thì con đường nào để đạt được mục tiêu đó dễ dàng nhanh chóng và hiệu quả nhất? Nếu b

0 0 51