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ịnh hành tốt nhất cơ mà bất kể Tester nào thì cũng đề xuất đối đầu và cạnh tranh ít nhất 1 lần trong lĩnh vực. Nó có thể xảy ra nghỉ ngơi bất cứ dự án làm sao. Đây cũng là câu hỏi cơ mà chúng ta hay gặp gỡ khi tmê man gia một cuộc chất vấn apply mang lại vị trí Tester

*

Ai cũng phát âm Dev team cùng Test team rất nhiều là 1 phần của dự án công trình cùng thuộc hiến đâng chấm dứt nó cùng với unique rất tốt, tuy nhiên Dev ko bao giờ muốn thừa nhận bug của chính bản thân mình Thế phải vấn đề này là phân biệt xảy ra với ko tất cả gì làm cho không thể tinh được cả Lúc Tester không tìm được sự hiệp tác của Dev => Tester luôn luôn luôn sẵn sàng tâm lý, trạng thái cho ngôi trường hợp này nhé, không nên trầm trồ hể hả Lúc tìm kiếm được bug

Vậy làm gì lúc cả 2 bên đa số vẫn hy vọng ttiết phục đối phương chấp nhận theo cách của mình? Với kinh nghiệm mấy năm trong nghề, mình xin được share tay nghề bản thân cách xử trí vần đề này như sau:

A. Một số Cách xử lý Khi Dev không thừa nhận Bug

1.trước hết Tester phải làm cảnh giác công việc sau biểu đạt về bug:

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

•Môi ngô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 làm test (nếu vào ngôi trường thích hợp chạy thử di động, phầm mềm..)

•Cheông chồng sống Các môi trường khác có lộ diện bug không? Số lần xuất hiện/ tổng số lần triển khai.

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 để làm test

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

2.Thứ hai, "nói có sách méc bao gồm chứng".

Tester muốn vun ra lỗi của Dev vào quá trình thành lập ứng dụng thì nên bao gồm bệnh cđọng rõ ràng. Ai cũng biết định nghĩa bug là lỗi mà lại phần mềm hoạt động không như ao ước hóng của công ty.

Thế bắt buộc giả dụ Dev ko công nhận bug thì chúng ta cứ đọng giới thiệu các tài liệu liên quan nhằm xác thực được dòng bản thân nói bao gồm cơ sở. Cụ thể là Requirement document, Detail Design, Test spect, Test case,...

3.Đặc biệt mang lại trường đúng theo Dev soccer sang chân không giống, tức thị đổ lỗi đến framework, OS, computer,... thì các bạn nên nhờ vào đến nhân thứ thứ 3.Partner trung gian này hoàn toàn có thể là một trong tester khác (gồm OS, computer... tương tự để biểu đạt lại bug).

Hoặc cũng rất có thể là Test Leader hay PM để phân giải xem trên đây bao gồm thực sự là bug xuất xắc ko, và bắt buộc xử lý vậy nào với nó (Dev yêu cầu fix xuất xắc đã clarify/on hold / limitation...)

4.Trong trường hòa hợp Dev luôn luôn có status không được giỏi vào quá trình thao tác làm việc. Tester hoàn toàn có thể lý giải & cảnh báo Dev kia rằng Tester ko yêu cầu là bạn tạo thành bug, Tester chỉ cần tín đồ tìm ra bug nhằm improve sầu sản phẩm trước lúc giao cho khách hàng hàng

5.Thông thường Bug bị dev reject bởi vì lý do requirement ko biểu đạt. Đây chính là trường thích hợp requirement bị thiếu hụt. Nếu bug của chúng ta tất cả tương quan cho tới chức năng business nó hoàn toàn có thể được gật đầu đồng ý hoặc reject bởi 1 BA. Thì chúng ta nên đồng tình cùng với nó.

Xem thêm: Các Bài Tập Nguyên Lý Hệ Điều Hành Có Lời Giải, Đề Cương Ôn Tập Nguyên Lý Hệ Điều Hành

*

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

Nhưng cái đặc biệt nên ghi nhớ là: đàm luận với ý thức đóng góp, thiết kế với mục tiêu bình thường là đã cho ra thành phầm, ứng dụng rất tốt cho người tiêu dùng chứ đọng không phải tranh cãi xung đột vày dòng tôi của chính bản thân mình (nhiều người dân luôn bực mình vì người khác đúng với chủ kiến của chính mình thì không đúng, đừng nhằm mẫu tôi vào các bước những vượt nha phần đông người).

Mọi fan cứ đọng luôn quan tâm đến rằng, bản thân sẽ làm việc và mong ước của bản thân mình là hiệu quả cực tốt mang đến ứng dụng, phương châm của chính mình là thử nghiệm cùng tìm kiếm bug nhằm thành phầm mang đến tay quý khách bao gồm unique rất tốt. Có những điều đó thì mình vẫn không bị tình yêu, suy nghĩ cá nhân, loại tôi,… nó làm cho ảnh hưởng mang đến cách biểu hiện thao tác làm việc của bản thân mình.

B. Kỹ năng nhằm hoàn thành bạn dạng thân:

Với ánh nhìn nhiều người, có khi Tester chả yêu cầu kĩ năng gì, cđọng theo REQ khám nghiệm kiểu như y là được. nhưng kể từ tay nghề một số trong những năm làm cho tester của mình tôi suy nghĩ đề nghị không ít hầu hết năng lực dưới đây nhằm hoàn thiện phiên bản thân.

•Hiểu biết các kỹ thuật chạy thử, nghệ thuật chế tác kiểm tra kiến thiết : bạn có thể kiểm tra ko vận dụng nghệ thuật, nhưng mà nó vẫn là chìa khóa nhằm chúng ta có tác dụng tốt nhất có thể với sáng sủa với các bước của mình

•Có năng lực R&D đến công nghệ bắt đầu : technology thì luôn luôn chuyển đổi, ko chỉ Developer cơ mà các bạn 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 quý khách hàng nếu như khách hàng làm Outsource, có tác dụng gắng nào để làm hài hòa đông đảo thứ mà lại vẫn không bao giờ quên trách nhiệm kiếm tìm bug của mình

•Khả năng Chịu đựng áp lực : Tester hay tốt bị hiểu nhầm. Đôi khi chúng ta đưa ra bug với vẫn cực kỳ vui miệng với vấn đề kia, thiên nhiên gặp gỡ góc nhìn chếch chếch chú ý lịch sự trường đoản cú chúng ta DEV Không biết gồm lúc nào chúng ta ấy phát âm mang đến đưa ra bug là output các bước của tester, tester vui lúc đưa ra bug tương tự như Dev vui Lúc tạo nên sản phẩm vậy chứ đọng ko bắt buộc chúng tôi vui vày đưa ra tội tình của chúng ta Developer.

• Tôi thấy hiện nay sống những nước trở nên tân tiến , bản thân có tác dụng với những người Nhật những năm bọn họ sẽ đọc được vai trò với vị trí của Tester vào nhóm dự án. Tuy nhiên sinh sống đất nước hình chữ S những nơi, không ít người vẫn chưa biết đến được vấn đề đó, là vấn đề tương đối đáng ai oán mang lại chúng ta Tester ngơi nghỉ nước ta.

Xem thêm: Cách Khắc Phục Mạng Fpt Lag Vào Buổi Tối Như Thế Nào? Cách Khắc Phục Mạng Fpt Chậm Về Đêm, Giờ Cao Điểm

•Tính kiên trì : tính năng này có thể rất là cần thiết. Tôi đã từng có lần phân phát chán ko tìm ra điểm gì hứng thú Lúc chạy thử ròng rã các năm cho một dự án. Ngày nào thì cũng vẫn màn hình đấy, cũng vẫn biện pháp xử trí đấy, thỉnh thoảng khách hàng chỉ thay đổi 1 yếu cầu rất nhỏ → viết Testcase phần change kia, với cả các tác dụng liên quan không giống → kiểm tra lại, khách hàng đưa ra bug → test lại, đổi khác môi trường → kiểm tra lại, vòng luẩn quẩn ko xong. Thử hỏi ko bao gồm độ kiên nhẫn cao ai làm cho thừa thế.

C. Một số phương châm đề xuất có:

Ngoài những kỹ năng cần thiết nlỗi trên, tôi có muốn menu ra một vài kinh nghiệm cần thiết luôn luôn nhắc nhở bản thân lúc làm việc

*

•Không thừa cổ hủ dẫu vậy cũng không ba phải

•Hãy quyết đoán

•Hãy biết lắng nghe các phía

•Luôn luôn nghĩ về cho người sử dụng cơ mà cũng hãy biết thảo luận với họ ( nếu khách hàng là tại đoạn quản lý )

•Luôn nghĩ về sản phẩm : không chỉ là các bước search và post bug, hãy làm cho bản thân tiến xa hơn thế

•Luôn cải thiện skill của bạn dạng thân khi tất cả thể

D.Kết luận:

Trên phía trên chỉ là quan tâm đến và ghê nhiệm của phiên bản thân có thể không đúng cùng với nhiều người. Tuy nhiên, điều do dự độc nhất của tớ cho tới từ bây giờ là 10 năm nữa bản thân bao gồm còn thường xuyên với nghề này Lúc khả năng nhanh hao tay, nkhô nóng mắt cũng bị giảm bớt vày tuổi tác?

Có lẽ bây chừ tôi chưa tồn tại thể bắt gặp trước được tương lai đó, nhưng lại tôi tạm bợ đứng vững niềm tin là sẽ có tương đối nhiều phương pháp, cơ hội ,địa chỉ nhằm dù già mình cũng vẫn giữ được vị trí được với nghề

Các links tđắm say 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