Trở thành một cô nàng Tester cẩn thận 😍

Bạn đã trở thành một người như thế nào khi quyết định theo con đường Tester?

Hôm nay em sẽ chia sẻ kiến thức những kinh nghiệm đã học được khi chập chững vào nghề Tester này, và những kinh nghiệm học hỏi được để trả lời cho câu hỏi mà chắc hẳn ai bước vào nghề Tester này cũng đã từng tự vấn. Đó chính là:

❓Làm thế nào để không bị Reject lỗi khi Log Bug?

Suy nghĩ của Tester khi log lỗi chắc hẳn sẽ như thế này 😀
Tôi không thích việc bị trả lại bug mình log từ phía dev. Hmm, Và đều mong muốn rằng mọi lỗi mình log đều được sửa.

Lý do tại sao tiêu đề bài Blog lại là “ Trở thành một cô nàng Tester cẩn thận” . Đúng vậy, trước khi bạn log bất kỳ lỗi nào, hãy chắc chắn rằng đấy là bug chứ không phải sai lầm của mình khi test.

Chia sẻ câu chuyện từ cá nhân của bản thân: Không biết mọi người khi chập chững bước vào nghề có tâm lý như mình không, nhưng mình khi bước vào dự án đầu tiên thì đã thực hiện như này:

1. Sục sôi tìm bug, tìm không ra bug cảm thấy rất lo lắng

2. Aaaa, Bug đây rồi ( sau khi thao tác thay đổi dữ liệu và ấn lưu ) ⇒ phát hiện dữ liệu không thay đổi

3. Báo người review với tâm lý rất hồ hởi: Em thao tác như này, như này,… ra kết quả thế này…. là Bug đúng không ạ? (Tâm lý như lập chiến công)

4. Và người review của bạn: Ctrl + F5 lại thử chưa em 😀

5. Và kết quả thì là bạn biết rồi đó 😩

Bàn đến ảnh hưởng của việc không cẩn thận:

⇒ Bạn sẽ để lại cho người Review của bạn, hay thậm chí là đội dev nếu đã log bug thời gian lãng phí cho team và khi quá nhiều lần như thế thì chắc chắn việc bạn sẽ bị đánh giá thấp năng lực là rất cao.

Vậy lý do của việc không cẩn thận này là gì? Nguyên tắc trước khi tái hiện Bug bạn phải tự trả lời được 4 câu hỏi theo nguyên tắc 3W-1H như sau:

WHAT: Cái gì đang không hoạt động?
WHY: Tại sao nó ko hoạt động?
HOW: Làm thế nào để nó hoạt động?
WHERE: Đâu là lý do gây ra hiện tượng này?

Đấy bạn thấy không, suy từ tình huống của cá nhân mình ra thì việc chưa trả lời đến câu thứ 4 đã vội đi “khoe” Bug sẽ là thế đó.

Nhiều Tester nghĩ rằng, trả lời được “ À, tại sao nó không hoạt động” đã là đủ để có thể log lại các bước tái hiện trên hệ thống quản lý lỗi. Vậy tại sao chúng ta lại cần phải trả lời 3 câu hỏi còn lại? = > Hãy suy nghĩ vượt ra ngoài khuôn khổ trách nhiệm của bạn. Hãy hành động như một người thông minh thay vì một kẻ khờ khạo luôn chỉ bám theo những bước tái hiện đơn thuần mà không nghĩ được gì hơn thế. Bạn nên nghĩ đến tất cả những phương án giải quyết có thể để sửa lỗi và tính hiệu quả cũng như mặt hạn chế của từng phương án. Điều đó giúp tăng sự tôn trọng của các thành viên trong dự án với bạn và giảm thiểu việc bug bị trả lại, không phải vì tôn trọng mà vì kỹ năng tái hiện bug của bạn.

📍Vậy nên trước khi Log Bug, bạn hãy kiểm tra xem mình đã trả lời được các câu hỏi đó chưa?

📍 Bạn có thể bỏ qua một bước quan trọng hoặc chưa thực hiện đúng các bước trong testcase?

📍Tái hiện lý do cho lỗi trên ứng dụng. Hãy log bug khi thực hiện đúng các bước tái hiện.

👉Dưới đây là một danh sách các vấn đề thường gặp trong quá trình test khiến chúng ta nhầm tưởng nó là bug ở dưới đây.

Chụp lại ảnh ngay khi gặp Bug hoặc hiện tượng lạ: để tránh trường hợp Bug khó tái hiện thì ta nên chụp ngay lại ảnh màn hình lưu lại để báo cáo sau khi xác nhận Bug.
Xác nhận lại Bug: để không bị log Bug “nhầm” thì trước khi báo cáo nên kiểm tra xem đó có chính xác là Bug hay không bằng cách xóa bộ nhớ cache (Ctrl +F5), kiểm tra log server, kiểm tra console log, kiểm tra database, kiểm tra trên module tương tự khác …và tự tái hiện Bug 3 lần trước khi báo cáo.
Báo cáo ngay lập tức: có nghĩa là sau khi gặp và đã xác định đó là Bug thì nên báo cáo luôn, không chờ viết Bug report xong hoặc test xong phần đó rồi mới báo cáo. Điều này đảm bảo không bị thiếu Bug và có thể tái hiện được.
Viết tóm tắt lỗi rõ ràng: Đây là phần quan trọng chỉ sau phần tiêu đề. Nên mô tả lỗi ngắn gọn. Các bước nên đánh thứ tự 1-2-3…, mỗi step chỉ mô tả một hành động, không viết dài quá. Mục tiêu là khi đưa Bug report cho một người không biết gì thực hiện theo các mô tả có thể tái hiện được Bug đó.
Không sử dụng ngôn ngữ gây tổn thương người đọc: nếu không phải là Bug thì nên gọi là vấn đề của chức năng nào đó, không đánh đồng gọi là Bug gây ảnh hưởng tới tâm lý người làm task.
Bug khó tái hiện: trường hợp không thể tái hiện lỗi giống nhau trên máy Dev và Tester thì nên dùng máy thứ 3 để tái hiện, như vậy sẽ đánh giá được chính xác lỗi hơn.

Tóm lại, thế nào là một bug report hiệu quả?

Dễ dàng tái hiện bởi Dev hoặc người đọc
Report ngắn gọn, rõ ràng
Đầy đủ thông tin, hình ảnh
Dễ dàng theo dõi, truy vấn bug khi cần
Khả năng được fix cao

⇒ Trên đây là một số sai lầm nhỏ thường gặp nhưng có thể tác động đến mối quan hệ cũng như sự tin tưởng trong team của bạn. Khi bạn tìm ra bug và nó bị trả lại bởi một trong số lý do như mình đã đề cập ở trên thì đó sẽ là một sai lầm ngớ ngẩn và khiến bạn xấu hổ (ít nhất là với mình). Vì vậy, hãy cố gắng đừng mắc phải những sai lầm đó!

Và để trả lời cho câu hỏi đầu tiên Bạn đã trở thành một người như thế nào khi quyết định theo con đường Tester? Thì câu trả lời mong muốn rằng

❤️ HÃY LÀ MỘT CÔ NÀNG TESTER CẨN THẬN VÀ TỈ MỈ NHEN ❤️