5 lỗi chính trong cách làm việc của lập trình viên và kiểm thử viên

5 lỗi chính trong cách làm việc của lập trình viên và kiểm thử viên

1. Ích kỷ

Lỗi đầu tiên là bởi các nhà phát triển và nó liên quan tới những thứ nhỏ nhặt như mượn thiết bị để tái hiện lỗi / vấn đề.

Bạn biết rằng cảm giác khi một ticket JIRA được assign cho một nhà phát triển-bạn phải kiểm tra version nơi vấn đề tồn tại và làm thế nào để tái hiện được vấn đề, vv Bạn đã có tất cả những thông tin trong ticket JIRA và bây giờ bạn đang làm công việc hàng ngày của bạn như kiểm thử sanity, kiểm thử monkey và kiểm thử hiệu năng Tất cả đột ngột xuất hiện với người lập kế hoạch - người phát triển - và yêu cầu bạn đưa cho anh ta MUT (mobile test) bởi vì anh ta bây giờ cần để khắc phục vấn đề. Nó sẽ không phải là một việc lớn nếu bạn không được assign ít nhất hàng tá các hot issue cần được tái hiện trên một thiết bị đó. Nhưng bạn là một người tốt, vì vậy bạn cho anh ta công cụ làm việc của bạn với hy vọng rằng "chỉ có 20 phút để khắc phục vấn đề".

Tất nhiên, điều đó không bao giờ làm được.

Bên cạnh đó , anh ta không bao giờ trở lại với bạn vì vậy BẠN phải có trách nhiệm lấy lại tài sản của bạn. Ngoài ra, vì một số lý do kỳ lạ, các nhà phát triển không có ý nghĩ sạc điện thoại. Tôi ghét nó khi tôi lấy lại MUT của tôi và phát hiện ra rằng chỉ có 10% pin còn lại và bây giờ tôi là một trong những người bị block với công việc của tôi.

Giải pháp của tôi là đơn giản - Dear Developers, xin vui lòng, cắm điện thoại với máy PC và đừng quên rằng bạn không phải là những người duy nhất làm việc trên dự án.

1. Phiền nhiễu

Lỗi thứ hai là cam kết của chính những người kiểm thử và cụ thể hơn là một người kiểm thử làm việc ở nước ngoài với bạn. Trong sự nghiệp của tôi, tôi đã được may mắn khi làm việc với những người thuộc nhiều quốc tịch - Trung Quốc, Ấn Độ, Ailen, Anh - nhưng bất cứ ai tôi làm việc cùng, tôi luôn luôn bị mắc kẹt với ít nhất một người là người mà luôn có một số vấn đề " made up".

Nó sẽ không là vấn đề nếu nó không dành cho kiểu người reopen ticket về các thiết bị và hệ thống lỗi thời (Android 4.4 cho một số nhà sản xuất điện thoại bên thứ ba?). Anh ta có một đặc điểm kì lạ là viết "vấn đề này được tái hiện lại 10/10 lần" ngay cả khi không có ai khác có vấn đề như vậy trong một thời gian dài (nếu có).

Có một giải pháp đơn giản cho điều đó. Chỉ cần yêu cầu anh ta ghi lại video của vấn đề. Bạn sẽ ngạc nhiên về cách giải quyết "Bây giờ tôi không thể tái hiện lại, xin vui lòng đóng ticket"

1. Không có sự liền mạch

Lỗi thứ ba là bởi những người chịu trách nhiệm tạo ra các trang web và phần mềm để cải thiện việc kiểm thử và phát triển. Bạn có thể tự hỏi. Sau khi tất cả, họ dành vô số giờ để tạo ra một cái gì đó hữu ích và tôi vẫn còn phàn nàn?

Vâng, không phải về quy trình và ý định tốt, nhưng sự chậm trễ và lười biếng khi nói đến tối ưu hóa và viết các hướng dẫn về "cách sử dụng phần mềm". Ôi chúa ơi, tôi ghét điều này rất nhiều khi tôi cần phải tải về một chương trình nhưng sau đó tôi cũng phải có những cập nhật mới nhất một số package tuy nhiên phần mềm có thể không tương tích với phiên bản mới nhất (python 3 và 2) Và làm thế nào mà 2 người làm việc trên 2 môi trường giống nhau nhưng phần mềm chạy trên môi trường này thì được còn môi trường khác thì ko chạy được. ? bạn phải tìm trong stack overflow để tìm ra chủ đề mà một người đã gặp vấn đề tương tự cách đây 5 năm nhưng anh thể đã có thể fix nó bằng cách lục lọi registry. Sau đó khi bạn đưa ra một ý tưởng thông minh để gỡ bỏ mọi thứ và cố gắng bắt đầu lại từ đầu, bạn ngạc nhiên vì một số package bị mất và một số khác lại được ẩn đi không rõ trong thu mục nào v.v. Cách hướng dẫn đôi khi rất vụng về và khó đọc. Ý tôi là , chúng ta là một người kiểm thử, thông tin cần phải được đơn giản để hiểu, thông tin cần phải logic để tái hiện thậm chí ngay cả bởi một người không cần kỹ năng advance cũng có thể thực hiện được các step một cách chính xác. Vậy tại sao có những hướng dẫn lại không theo cách này? Nó quá khó hay do thiếu sự đồng cảm từ những người chuẩn bị hướng dẫn này? Vì vậy tôi muốn nói sản phẩm của bản không nên review bởi những người developer bởi vì những người không phải deverloper sẽ nhìn thấy nhiều vấn đề hơn. 4) Vụng về

Tội thứ tư là một lần nữa bởi các nhà phát triển và nó là tất cả về việc sửa chữa vụng về.

"Đừng lo lắng tôi có thể làm điều đó trong một vài phút và bạn có thể đưa tôi +1 Gerrit" Chúng tôi nghe thấy điều này bất cứ lúc nào. Vấn đề là đ các bản sửa lỗi không chính thức tương đương với việc tạo ra 10 lỗi hơn nó không tồn tại trước đó

Tất nhiên, nó thường kết thúc với các vấn đề báo cáo nhưng sau đó chúng tôi nghe thấy rằng các tài liệu có sai sót, không có đủ thông tin, nơi làm việc vv Nhưng thành thật, các nhà phát triển thân mến, nếu bạn có label của việc xây dựng, AHA (host Android ứng dụng), FW (firmware), hệ thống, tên của điện thoại, các bước tái hiện, log, video thậm chí attach file vào ticket đó bạn cần gì hơn?

Tôi nhận được rằng một số bạn ghét phải fix nhàm chán (tạo là tốt hơn, phải không?) Và bạn không muốn nghe rằng vấn đề là không xác định (các vấn đề NFC và Bluetooth) nhưng lại mát mẻ với những gì bạn làm và hợp tác với chúng tôi.

1. Ồn ào Lỗi thứ 5 là của tôi và những người như tôi đang làm việc trong không gian mở Rất khó chịu khi người bên cạnh bạn đang cười hoặc nói chuyện với một đồng nghiệp khác hoặc thậm chí nhai kẹo cao su. Hoặc sau khi nghe cuộc điện thoại của một ai đó. Âm thanh này có thể làm gián đoạn và thiếu tập trung Tôi không đổ lỗi cho mọi người nhưng chúng ta cố gắng để có không gian yên tĩnh, điều này giúp cho năng suất làm việc cao hơn và cuối cùng nó đủ để cho mọi người hạnh phúc hơn. Link refer: http://www.softwaretestinghelp.com/five-sins-of-working-with-testers-and-developer/