DEV - Tester: Cuộc tình giang dở
developer
43
Testing
26
NyLaa
4
White

Văn Đức Thái viết ngày 26/06/2018

1. Tản mạn ngoài lề

alt text
Đây là câu truyện muôn thủa từ trước tới nay.

Developers nghĩ: Tôi có thể làm ra ứng dụng bằng cách nào?
Testers nghĩ: Tôi có thể phá hỏng ứng dụng bằng cách nào?

Dường như chính điều này đã làm cho mối quan hệ giữa 2 bên dần nhạt phai, trái tim dù cố gắng đến mấy rồi cũng có lúc tổn thương đến chạm đáy nỗi đau.

Và đã trở thành kẻ thù trong mắt nhau từ lúc nào không hay.

Dev buồn, Tester cũng chẳng vui. Chỉ có BUG là người hoan hỉ nhất thôi.

À, thì ra là nó, chính là nó - Người thứ 3 trong cuộc tình giữa Dev và Tester.

DEV chúng tôi không phải là không thích các bạn. Các bạn cũng chẳng ghét chúng tôi đâu nhỉ?

Chúng ta cùng chung kẻ thù - BUG cơ mà.

Nào! Cùng tìm hiểu chút ít về nó nhé.

2. BUG - Kẻ thù chung

BUG cũng dăm ba bảy loại

a. Loại 1: Bug mà dev trong quá trình code phát hiện ra được.

Cái này thường xuất hiện trong quá trình DEV code chợt lóe ra À, mình còn thiếu test case này. À, trường hợp này thì sao nhỉ, trường hợp kia cũng phải check xem sao, bla bla

Loại này được xếp hạng là Easy Bug. Việc của chúng ta là hạn chế những loại bug này. Cái TestCase được nêu trên là gì?

Thường thì khi tham gia vào một dự án thì DEV thường chia thành 2 loại sau:

Quy trình 1: Đọc specs -> Code -> Unit Test -> Pass
Quy trình 2: Đọc specs -> Unit Test -> Code -> Pass

Bạn thuộc loại nào?

Thực tế, hầu như DEV chúng mình đang thuộc loại 1. Kiểu vào phát ăn luôn. Đòi ăn tươi nuốt sống con nhà người ta ngay đi được.

Cùng nhau thay đổi nhé mọi người, hãy tập cho mình thuộc loại 2. Hiệu quả đến đâu thời gian sẽ trả lời cho bạn.

Lúc này hãy tìm đến tình yêu của mình - Tester-chan

Định nghĩa lại một chút về Tester

Tester là ai?

  • Là người verify tìm ra nhiều bug tránh cho KH
  • Đồng thời cũng là người giúp Dev tránh nhiều bug nhất có thể trước khi code
  • Là bạn chứ không phải kẻ thù

Hãy ngồi lại cùng Tester, dùng yêu thương để

  • Cùng với Tester define ra Testcase cơ bản.
  • Trường hợp không cần viết UnitTest thì phải có checklist kiểm thử.

Khi đủ công cụ rồi hãy bắt đầu Code nhé DEV.

b. Bug mà dev pass, và Tester phát hiện

Thế là thế éo nào?

Testcase đầy đủ. Viết Unitest ngon lành cành đào. Pass ầm ầm mà vẫn tòi ra Bug là sao. Xung đột bắt đầu, tình cảm mặn nồng bắt đầu đi xuống :(.

Bình tĩnh, cũng nhau tìm hiểu qua nguyên nhân một chút - Midium Bug:

  • Góc nhìn tester và góc nhìn Dev khác nhau
  • Dev kém trình độ
  • Có những test case ở local không test được
  • Độ lạc quan của Dev => Thách thức mọi testcase
  • Đồng đội ngu -> Review kém

Cùng nhau tìm ra phương án giải quyết xem thế nào.

  • Góc nhìn tester và góc nhìn Dev khác nhau

Vấn đề này thì đúng là nhiều lúc xảy ra: Tester thường đứng trên phương diện người dùng cuối để phán xuống, nhất là các vấn đề UI/UX (cái nút này phải xịch lên chút, nó phải to một chút, màu đỏ cho dễ nhìn). DEV thì làm sao cho Logic tối ưu nhất là ngon.

-> PM, BrSE phải làm việc chuẩn đoạn này. Define rõ các vấn đề để Tester và DEV đưa về cùng một view

  • Dev kém trình độ:

Không phải DEV nào cũng PRO cả, không phải ai cũng cân bản đồ tốt. Một vấn đề phát sinh thì có thể có rất nhiều cách code để giải quyết. Việc chọn ra phương án tối ưu nhất, tránh miss case cần người có kinh nghiệm, ...

Nâng cao trình độ code là điều đương nhiên lúc này, à không, mọi lúc. Mọi người có thể lên một số trang để luyện code, https://www.hackerrank.com để nâng cao trình code.

  • Có những test case ở local không test được.

Bạn là DEV, bạn biết có Testcase như thế, nhưng ko test được ở Local của mình, đành nhắm mắt push lên để Tester test và hi vọng không dính. Nhưng mà đen!

Cài đặt môi trường giống môi trường thật nhất có thể. Còn có những trường hợp đặc biệt ngoại lệ thì gần như gặp trường hợp này mình phải chấp nhận mà fix sau thôi.

  • Độ lạc quan của Dev => Thách thức mọi testcase

Cái này là vấn đề ở DEV. Nhiều DEV nghĩ rằng Code mình ngon lành cả, thách thức mọi test case. Rồi bị Tester chửi là đúng thôi. Hơi đen

=> Đảm bảo đã Pass qua các TestCase trước khi push. Hên thì không sao, đen là ăn chửi đó :((

  • Đồng đội ngu -> Review kém

Không sợ địch mạnh như hổ, chỉ sợ đồng đội ...

Thường thì chúng ta sẽ làm việc theo team, ít ai một mình cân một dự án cả. Và thường trước khi một PR được merge thì sẽ có đồng đội review. Hãy là người review có tâm

  • Code đúng
  • Code tối ưu

c. Loại 3: Bug mà dev và tester pass. Nguy cơ tiềm ẩn

Đây là Hard Bug. Thường khi sản phẩm đã đưa vào thực tế. Người dùng phản ánh.
hot-fix xuất hiện.

Điều này là không thể tránh khỏi. Mình chỉ hạn chế được nó thôi.

Trở lại câu chuyện chính là vấn đề Trình độ của DEV để tối ưu code, hạn chế tối đa loại bug này. Hãy:

  • Nâng cao trình độ DEV
  • Thực hiện đúng quy trình, tối ưu code

3. Tóm lại

Trong các công ty, thực tế ở các công ty outsource cho Nhật thì thường thì 1 Tester cân 3 DEV. Nhiều lúc hãy thông cảm cho họ nếu có vấn đề gì xảy ra.

Hãy yêu thương Tester! Output cuối cùng của cả Tester và DEV là có một sản phẩn ít bug nhất cho người dùng. Đừng đề kẻ thứ 3 (Bug) làm rạn vỡ tình cảm 2 đứa.

À,

TAY CODE ĐẦU PHẢI NGHĨ

Bài Bái

(。◕‿◕。) NyLaa (。◕‿◕。)

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Văn Đức Thái

16 bài viết.
90 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
23 13
1. Tản mạn ngoài lề Khuya vật vã. Chẳng ngủ được. Mà chẳng biết làm gì giữa cái lúc dở dở ương ương này. Viết blog vậy :(. Bài viết dành cho các...
Văn Đức Thái viết 10 tháng trước
23 13
White
23 16
1. Tản mạn ngoài lề (Ảnh) MySQL với DB thì có cái quần què gì chứ? Đọc thôi để thấy cũng vài cái hay ho và này nọ. 2. MySQL: MyISAM & InnoDB & ...
Văn Đức Thái viết 10 tháng trước
23 16
White
18 3
1. Tản mạn ngoài lề (Ảnh) Khi gặp một vấn đề trong cuộc sống bạn sẽ làm gì? Người yêu đá đít, cuối tháng hết tiền lương, sếp đì trên đi xuống, bl...
Văn Đức Thái viết 10 tháng trước
18 3
Bài viết liên quan
White
5 0
1. Định nghĩa Một kế hoạch kiểm thử dự án phần mềm (test plan) là một tài liệu mô tả các mục tiêu, phạm vi, phương pháp tiếp cận, và tập trung vào...
Thiên Hoàng Minh Vũ viết hơn 1 năm trước
5 0
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
16 bài viết.
90 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!