BẠN SẼ LÀM GÌ KHI DEVELOPER NÓI LÀ KHÔNG THỂ TÁI TẠO ĐƯỢC LỖI CỦA BẠN?

Đây là problem thông dụng nhất mà bất kể Tester nào thì cũng phải đối đầu ít duy nhất 1 lần vào nghề. Nó rất có thể xảy ra ở bất cứ dự án nào. Đây cũng là thắc mắc mà chúng ta thường gặp mặt khi tham gia một cuộc vấn đáp apply cho vị trí Tester

*

Ai cũng gọi Dev team và thử nghiệm team phần nhiều là một phần của dự án và cùng góp sức xong nó với chất lượng tốt nhất, mặc dù Dev ko khi nào muốn công nhận bug của bản thân mình Thế nên sự việc này là hiển nhiên xẩy ra và ko gồm gì làm ngạc nhiên cả khi Tester không tìm được sự hợp tác của Dev => Tester luôn luôn luôn sẵn sàng tâm lý, trạng thái mang lại trường thích hợp này nhé, tránh việc tỏ ra hể hả khi tìm được bug

Vậy làm gì khi cả hai bên đều đang ước ao thuyết phục đối phương đồng ý theo cách của mình? với tay nghề kinh nghiệm mấy năm vào nghề, bản thân xin được share kinh nghiệm phiên bản thân cách xử trí vần đề này như sau:

A. Một trong những Cách cách xử trí khi Dev không thừa nhận Bug

1.Đầu tiên Tester phải làm cẩn thận quá trình sau diễn tả về bug:

•Ghi step cụ thể rõ rạng về bug

•Môi trường xảy ra bug

•Số lần mở ra bug/ Total số lần thực hiện

•Ver soft dùng để test (nếu trong trường hợp chạy thử mobile, app..)

•Check ở Các môi trường xung quanh khác có mở ra bug không? chu kỳ xuất hiện/ tổng số lần thực hiện.

Bạn đang xem: Bạn sẽ làm gì khi developer nói là không thể tái tạo được lỗi của bạn?

•Data dùng để test

•Lấy log or chụp evidence , quay video clip lại làm bằng chứng

2.Thứ hai, "nói tất cả sách mách gồm chứng".

Tester mong muốn vạch ra lỗi của Dev trong quá trình xây dựng ứng dụng thì phải có chứng cứ rõ ràng. Ai cũng biết tư tưởng bug là lỗi mà phần mềm hoạt động không như ý muốn đợi của khách hàng hàng.

Thế đề xuất nếu Dev không thừa nhận bug thì các bạn cứ chuyển ra các tài liệu tương quan để xác nhận được cái mình nói bao gồm cơ sở. Cụ thể là Requirement document, Detail Design, chạy thử spect, test case,...

3.Đặc biệt cho trường đúng theo Dev bóng đá sang chân khác, tức là đổ lỗi đến framework, OS, computer,... Thì chúng ta buộc bắt buộc nhờ mang đến nhân vật lắp thêm 3.Partner trung gian này có thể là 1 tester khác (có OS, computer... Tương tự để diễn đạt lại bug).

Hoặc cũng có thể là chạy thử Leader xuất xắc PM để phân giải xem đây bao gồm thực sự là bug xuất xắc ko, với nên giải quyết và xử lý thế làm sao với nó (Dev cần fix hay sẽ clarify/on hold / limitation...)

4.Trong trường hợp Dev luôn có status không được giỏi trong quy trình làm việc. Tester rất có thể giải thích và nhắc nhở Dev kia rằng Tester ko nên là người tạo nên bug, Tester chỉ là người tìm ra bug để improve sản phẩm trước lúc giao đến khách hàng

5.Đôi lúc Bug bị dev reject vì lý do requirement không mô tả. Đây chính là trường hợp requirement bị thiếu. Trường hợp bug của công ty có liên quan tới tác dụng business nó có thể được đồng ý hoặc reject bởi 1 BA. Thì bạn nên đồng tình với nó.

Xem thêm: Hướng Dẫn Hack Nick Facebook 2017, Code Hack Pass Facebook, Bật Mí Cách Hack Tài Khoản Facebook, Gmail,

*

6.Trường thích hợp tester đứng theo cách nhìn người dùng làm bắt bug, thường xuyên thì spec không mô tả cụ thể đến hầu hết trường hòa hợp đó. Vậy tester không tồn tại cơ sở nào nhằm base vào cả, mà các bạn dev cũng không chịu nhận là bug thì cực tốt nhờ Team Leader hoặc PM hoặc scrum master giỏi ai đó chịu trách nhiệm về dự án công trình đó giải quyết, ví như PM nói ko là bug thì sau này có vấn đề gì PM phải chịu trách nhiệm

Nhưng cái đặc biệt quan trọng phải nhớ là: thảo luận với lòng tin đóng góp, xây cất với mục tiêu chung là đã tạo ra sản phẩm, ứng dụng tốt nhất cho người sử dụng chứ chưa phải tranh bào chữa vì cái tôi của chính mình (nhiều người luôn luôn bực bản thân vì bạn khác đúng cùng ý kiến của chính bản thân mình thì sai, chớ để dòng tôi vào công việc nhiều vượt nha phần lớn người).

Mọi bạn cứ luôn xem xét rằng, bản thân đang thao tác làm việc và mong mỏi muốn của chính mình là tác dụng tốt nhất cho ứng dụng, mục tiêu của bản thân mình là test và kiếm tìm bug để thành phầm đến tay người tiêu dùng có chất lượng tốt nhất. Bao gồm như vậy thì bản thân sẽ không xẩy ra tình cảm, suy nghĩ cá nhân, chiếc tôi,… nó làm ảnh hưởng đến thái độ thao tác làm việc của mình.

B. Kĩ năng để hoàn thiện bạn dạng thân:

Với góc nhìn nhiều người, tất cả khi Tester chả cần năng lực gì, cứ theo REQ khám nghiệm giống y là được. Nhưng từ kinh nghiệm một số năm làm tester của mình tôi nghĩ cần khá nhiều những kỹ năng sau đây để trả thiện phiên bản thân.

•Hiểu biết các kỹ thuật test, chuyên môn tạo kiểm tra design : bạn có thể test ko vận dụng kỹ thuật, cơ mà nó sẽ là chìa khóa để bạn làm tốt nhất có thể và đầy niềm tin với các bước của mình

•Có kĩ năng R&D cho technology mới : technology thì luôn thay đổi, ko chỉ Developer mà chúng ta làm Tester cũng phải biết về nó

•Kỹ năng giao tiếp : communication cùng với Dev, với PM, thậm chí cả với người sử dụng nếu bạn làm Outsource, làm cầm nào để làm hài hòa hầu hết thứ tuy vậy vẫn luôn ghi nhớ nhiệm vụ kiếm tìm bug của mình

•Khả năng chịu áp lực : Tester thường tuyệt bị đọc lầm. Đôi khi bạn tìm ra bug cùng đang cực kỳ sung mừng thầm với việc đó, bỗng nhiên gặp góc nhìn chếch chếch quan sát sang từ chúng ta DEV lừng chừng có bao giờ các chúng ta ấy hiểu mang đến tìm ra bug là output quá trình của tester, tester vui khi tìm ra bug tương tự như Dev vui khi tạo nên ra sản phẩm vậy chứ ko phải chúng tôi vui vì tìm ra tội vạ của chúng ta Developer.

• Tôi thấy hiện giờ ở những nước cải cách và phát triển , bản thân làm với người Nhật những năm họ vẫn hiểu được vai trò với vị trí của Tester trong đội dự án. Tuy vậy ở vn nhiều nơi, đa số người vẫn chưa hiểu được điều này, là vấn đề khá đáng ảm đạm cho các bạn Tester ở Việt Nam.

•Tính kiên trì : điều này chắc cực kì cần thiết. Tôi đã có lần phát chán ko đưa ra điểm gì hào hứng khi kiểm tra ròng các năm cho 1 dự án. Ngày nào thì cũng vẫn screen đấy, cũng vẫn cách xử lý đấy, thỉnh thoảng khách mặt hàng chỉ chuyển đổi 1 yếu ước rất nhỏ → viết Testcase phần change đó, với cả các chức năng liên quan không giống → kiểm tra lại, khách hàng tìm ra bug → chạy thử lại, chuyển đổi môi ngôi trường → demo lại, vòng quanh quẩn ko dứt. Demo hỏi ko có độ kiên trì cao ai có tác dụng được thế.

C. Một số kim chỉ nam cần có:

Ngoài các kỹ năng cần thiết như trên, tôi cũng muốn list ra một số trong những kinh nghiệm quan trọng luôn luôn nhắc nhở phiên bản thân khi làm việc

*

•Không quá cổ hủ nhưng cũng không ba phải

•Hãy quyết đoán

•Hãy biết lắng nghe nhiều phía

•Luôn luôn nghĩ đến khách hàng nhưng cũng hãy biết thảo luận với họ ( nếu khách hàng là ở vị trí thống trị )

•Luôn suy nghĩ về sản phẩm : không chỉ là quá trình tìm cùng post bug, hãy khiến cho mình tiến xa hơn thế

•Luôn nâng cấp skill của phiên bản thân khi tất cả thể

D.Kết luận:

Trên trên đây chỉ là suy nghĩ và ghê nhiệm của bạn dạng thân có thể không đúng với tương đối nhiều bạn. Tuy nhiên, điều do dự nhất của tôi mang lại đến bây giờ là 10 năm nữa mình bao gồm còn liên tiếp với nghề này khi kĩ năng nhanh tay, nhanh mắt cũng trở thành hạn chế do tuổi tác?

Có lẽ lúc này tôi chưa có thể bắt gặp trước được tương lai đó, dẫu vậy tôi tạm giữ vững niềm tin là sẽ có không ít cách, cơ hội ,vị trí để dù già tôi cũng vẫn giữ vững được cùng với nghề

Các link tham khảo:http://stackoverflow.com/questions/3657267/what-a-tester-need-to-do-when-he-found-a-bug-and-the-dev-does-not-want-to-fix-it