Đôi khi nhóm QA của tôi báo cáo lỗi, nhưng tôi hoặc họ không có ý tưởng nào về cách tái tạo chúng. Điều này dẫn đến các phiên gỡ lỗi rất dài và bực bội mà đôi khi thậm chí không mang lại kết quả.

Phần mềm của tôi được gắn chặt với phần cứng độc quyền để các lỗi có thể đến từ nhiều hướng cùng một lúc.

Tôi có nên mong đợi nhiều hơn từ họ hơn là "phần mềm của bạn bị sập khi tôi nhấn nút" hay tôi nên tự tìm hiểu xem chuyện gì đã xảy ra?

BIÊN TẬP:

Một trong những đồng nghiệp của tôi đã chỉ ra rằng có lẽ tất cả chúng tôi đều là nhà phát triển ở đây nên kết quả có thể bị sai lệch đôi chút

QA phải luôn cố gắng và tạo ra các lỗi dễ dàng để bạn tái tạo nhất có thể và mô tả lỗi phải chứa các bước đã thực hiện.

Tuy nhiên, nếu họ không thể dễ dàng tái tạo các lỗi, họ vẫn nên được nhập vào cơ sở dữ liệu lỗi với tiêu đề / tiêu đề phù hợp và mô tả đầy đủ về những gì họ đã làm để gây ra lỗi. Mô tả lỗi phải nêu rõ rằng họ không thể tái tạo lỗi (có thể với một số nhận xét dọc theo dòng chữ "đã thử năm lần, nó đã xảy ra một lần"). Bằng cách này, nếu người khác nhìn thấy cùng một lỗi, họ có thể thêm vào cơ sở dữ liệu lỗi bằng các phát hiện của họ và bạn cũng có được càng nhiều thông tin càng tốt, điều này có thể giúp bạn tiết kiệm thời gian theo dõi vấn đề.

Ngoài ra, bạn có thể lọc thông tin - có thể có rất nhiều lỗi trong các hệ thống khác nhau mà bạn biết đều được liên kết với (ví dụ) một khu vực của mã - nếu QA không báo cáo bất cứ điều gì (vì chúng không thể sao chép chúng ) sau đó thông tin này không nhận được cho bạn.

Có vẻ như bộ phận QA của bạn đang thực hiện quá nhiều thử nghiệm thăm dò (nghĩa là họ không có kế hoạch kiểm tra tốt).

Kiểm tra thăm dò là tốt và xác định các khu vực có vấn đề, nhưng từ đó họ nên xác định các trường hợp kiểm tra có thể lặp lại (nghĩa là một kế hoạch kiểm tra) để thực hiện sẽ tiết lộ các lỗi cụ thể.

Có một số lý do tại sao một repro chính xác là cần thiết (không chỉ tốt, mà còn cần thiết):

1. Bạn phải repro để bạn có thể gỡ lỗi / theo dõi nguyên nhân.
2. QA sẽ cần có thể xác minh sửa chữa sau khi bạn hoàn thành.
3. Các bài kiểm tra tiếp theo sẽ cần phải thực hiện hồi quy trên các lỗi trước đó.
4. Các lỗi đã biết có thể được loại bỏ nếu phơi sáng quá nhỏ hoặc repro quá khó xảy ra.

Vì vậy, như SteveCzetty lưu ý: Đóng nó như không repro và quay lại làm việc.

Nếu lỗi không thể được sao chép một cách nhất quán, làm sao QA biết được liệu nó đã được sửa chưa?

Vâng, bạn nên mong đợi nhiều hơn từ họ. Họ có thể nói:

1. Bắt đầu phiên bản mới của chương trình
2. Tôi nhấn nút A
3. Đã nhập "văn bản kiểm tra" vào trường TEST TÊN trên Mẫu số 1
4. Nhấn nút B
5. Quan sát thấy chương trình bị sập với thông báo này (xem ảnh chụp màn hình đính kèm).

Nếu tất cả những gì họ nói là "nó bị sập", thì chúng không tốt lắm. Ngay cả khi các bước trên không thể tái tạo 100%, một mẫu đủ lớn của các sự cố này có thể giúp thu hẹp nguyên nhân, một khi mẫu được phát hiện.

Lời khuyên của tôi là đọc những lỗi đó và suy nghĩ kỹ. Nếu bạn không thể tìm ra nguyên nhân tiềm năng, hãy quên chúng ngay bây giờ.

QA nên ghi lại mọi vấn đề họ tìm thấy, ngay cả khi họ không biết nó đã xảy ra như thế nào. Đó là công việc của QA để thử và tái tạo các vấn đề, nhưng thực tế điều này sẽ không luôn luôn có thể. Đôi khi nó không liên quan gì đến những gì họ đã làm trong 10 phút qua. Một cái gì đó đã rơi vào trạng thái không hợp lệ một ngày trước, và nó trở nên rõ ràng vì một trong 10 bước cuối cùng.

Với các lỗi "1 trong 1000" này, QA nên cố gắng tái tạo chúng một chút. Nếu họ không thành công, họ nên ghi lại lỗi, sau đó thử thêm một chút.

Lý do tại sao họ nên đưa lỗi vào khá sớm là vì lập trình viên biết mã tốt hơn rất nhiều so với QA và có thể biết ngay vấn đề. Nó có thể là mã họ tái cấu trúc. Nó có thể là chức năng mà họ thực hiện một nửa sau đó quên đi. Họ có thể không biết, nhưng không có ý nghĩa gì trong việc người thử nghiệm lãng phí vài giờ cố gắng tái tạo một vấn đề rõ ràng đối với người đã mã hóa nó. Người kiểm tra luôn có thể thêm chi tiết cho lỗi sau này.

Các lỗi nên bao gồm càng nhiều thông tin càng tốt. Bất cứ điều gì người kiểm tra có thể nhớ về vấn đề dẫn đến vấn đề nên được viết ra một cách chi tiết đau đớn. Bất kỳ bản ghi sự cố, ảnh chụp cơ sở dữ liệu hoặc ảnh chụp màn hình có liên quan cũng phải được đính kèm.

Nếu lỗi không bao giờ được sao chép, thật tuyệt! Nó không bị tổn thương khi có nó trong cơ sở dữ liệu. Nếu chương trình được phát hành và người dùng báo cáo lỗi tương tự sau đó, bạn có thể so sánh trải nghiệm của họ với những gì trong báo cáo và tìm kiếm bất kỳ điểm tương đồng nào.

Theo kinh nghiệm của tôi, các lỗi nhỏ nhất không được tìm thấy từ các kế hoạch kiểm tra. Đôi khi bạn phải để mọi thứ hầm trong vài tuần để mặt trăng và các ngôi sao thẳng hàng gây ra một lỗi khó chịu. Nếu QA có thể làm một số công việc thám tử và tìm thấy một số nguyên nhân có thể, hãy cho họ một cái vỗ nhẹ vào lưng. Nhưng đôi khi, ai biết chuyện gì đã xảy ra?

Rất nhiều lỗi không thể tái tạo cho đến khi bạn biết cách khắc phục chúng. Điều đó không có nghĩa là họ không cần phải sửa. Tôi đã sửa một lỗi vào năm ngoái mà tôi vẫn không biết cách sinh sản. Nó đòi hỏi một số kết hợp kỳ lạ của một lỗi truyền thời gian chính xác cùng với dữ liệu rác rất cụ thể trong một vị trí bộ nhớ nhất định trên ngăn xếp. Thật không may, một trong những khách hàng của chúng tôi đủ "may mắn" để luôn luôn ở trong tình trạng đó.

Vì vậy, bằng mọi cách khuyến khích QA bao gồm các bước tái sản xuất nếu có thể, nhưng đừng lỗi chúng nếu không thể. Đôi khi nó sẽ giúp bạn biết nơi để thêm đăng nhập. Đôi khi tất cả những gì nó làm là cho bạn biết những gì không gây ra lỗi, nhưng một báo cáo lỗi luôn hữu ích.

Nếu bạn có nghĩa là QA nên bao gồm các bước để tạo lại lỗi nếu có thể, thì câu trả lời là có. Nếu bạn có nghĩa là họ chỉ ghi lại lỗi mà họ có thể sao chép, thì hoàn toàn không. Lỗi là lỗi, cho dù chúng chỉ xảy ra vào nửa đêm vào lúc trăng tròn hoặc mỗi khi bạn nhìn vào nó. Một số lỗi không mang tính quyết định (ví dụ cổ điển là biến chưa được khởi tạo, trong đó giá trị được chọn là bán ngẫu nhiên), điều đó không có nghĩa là chúng không nên được ghi lại, điều tra và nếu có thể được sửa.

Các lỗi không thể lặp lại thường có mức độ ưu tiên thấp, nhưng chúng chắc chắn phải được ghi lại.

IMO, bạn nên. QA không thực hiện công việc của họ nếu họ không thể cung cấp cho bạn bất kỳ bước sinh sản nào. Đừng lãng phí thời gian của bạn để cố gắng tái tạo một cái gì đó mà bạn không thể, chỉ cần đóng nó thành "Không thể sao chép" và tiếp tục.

Thời gian của bạn có giá trị hơn nhiều.

Một báo cáo lỗi nên chứa:

• Các bước để tái sản xuất
• Hành vi thực tế
• Hành vi dự kiến

Ví dụ:

• Tôi đã xóa tất cả các nhà cung cấp khỏi cơ sở dữ liệu (sử dụng DELETE * FROM tSuppliers), mở hộp thoại nhà cung cấp và nhấp vào danh sách thả xuống của Nhà cung cấp.
• Danh sách chứa thông báo sau : GUPOS ERROR #0000000: SOMETHING WENT WRONG!. Khi tôi nhấp vào tin nhắn, ứng dụng biến mất khỏi màn hình và Trình quản lý tác vụ.
• Tôi dự kiến ​​sẽ thấy một danh sách trống hoặc (tốt nhất là) một thông báo như "Không tìm thấy nhà cung cấp". Nhấp vào danh sách trống hoặc tin nhắn sẽ không có hiệu lực. Ứng dụng rõ ràng không nên biến mất mà không có cảnh báo trong bất kỳ trường hợp nào.

Vì vậy, có - nó nên chứa các bước để tái sản xuất. Việc họ không cảm thấy cần phải bao gồm điều này dường như cho thấy rằng họ nghĩ rằng công việc của họ là "phá vỡ phần mềm", thay vì xác định lỗi.

QA sẽ có thể tái tạo các lỗi dựa trên các bước đã nhập. Nếu họ đã cố gắng hết sức mà vẫn không thể sao chép, họ vẫn nên nhập các lỗi với nhiều chi tiết họ có với dấu thời gian để các nhà phát triển có thể xem ứng dụng và ghi nhật ký gỡ lỗi để biết thêm chi tiết.

Tiền đang bị đe dọa ở đây. Tại sao bất kỳ thành viên nào trong nhóm có thể tạo ra một nhiệm vụ được xác định kém, cơ hội thành công thấp, gánh nặng cho một nhà phát triển được trả lương cao (hy vọng)?

Đây không phải là về trật tự, thứ bậc, sự kiêu ngạo, chúng ta so với họ, hoặc bất cứ điều gì tương tự. Đây chỉ là đầu tư vào các hoạt động làm tăng giá trị cho sản phẩm.

Khi một vấn đề có thể được chứng minh là ảnh hưởng tiêu cực và có thể đo lường được đến giá trị của sản phẩm, thì nó cần được điều tra, sao chép và sửa chữa. Sửa đường ống khuyết tật sản phẩm của bạn để lọc tiếng ồn.

đội QA của bạn hút

Đến gặp họ và bảo họ đọc một tài liệu mà bất kỳ người thử nghiệm chuyên nghiệp nào cũng phải in ngay trong não của họ (tôi đã từng là người thử nghiệm và tôi vẫn có nó ngay tại đó, trong não của tôi): Cách báo cáo lỗi hiệu quả .

Đặc biệt, hãy chỉ cho họ phần "Chỉ cho tôi cách thể hiện bản thân" :

Đây là thời đại của Internet. Đây là thời đại của truyền thông trên toàn thế giới. Đây là thời đại mà tôi có thể gửi phần mềm của mình cho ai đó ở Nga chỉ bằng một nút bấm và anh ấy có thể gửi cho tôi ý kiến ​​về nó một cách dễ dàng. Nhưng nếu anh ta có vấn đề với chương trình của tôi, anh ta không thể để tôi đứng trước nó trong khi nó thất bại. "Cho tôi xem" là tốt khi bạn có thể, nhưng thường thì bạn không thể.

Nếu bạn phải báo cáo lỗi cho một lập trình viên không thể có mặt trực tiếp, mục đích của bài tập là cho phép họ tái tạo vấn đề. Bạn muốn lập trình viên chạy bản sao chương trình của riêng họ, làm những điều tương tự với nó và làm cho nó thất bại theo cùng một cách. Khi họ có thể thấy vấn đề xảy ra ngay trước mắt, thì họ có thể giải quyết nó ...

Nếu họ bắt đầu la hét với bạn phàn nàn rằng "lỗi có thể đến từ nhiều hướng cùng một lúc" , hãy nói với họ rằng họ hút thậm chí nhiều hơn bạn nghĩ trước đây. Nói với họ rằng Khả năng kiểm tra là một tính năng mà họ nên đánh giá trong số các tính năng khác của dự án và họ nên đầu tư nỗ lực để có được tính năng này đúng.

• Những cải tiến về khả năng kiểm tra người ta có thể nhận được khi có một người thử nghiệm chuyên nghiệp tập trung vào nó có thể giống như phép thuật. Tôi đã học được rằng bản thân mình vài tháng trước. Kỹ sư QA làm việc với nhóm của chúng tôi đã cho tôi một số yêu cầu kiểm tra để phát triển cho một số thành phần trong ứng dụng của chúng tôi. Những điều anh ấy hỏi về tôi rất ít có ý nghĩa với tôi nhưng tôi chỉ đưa nó cho anh ấy giả định rằng anh ấy biết rõ hơn như một chuyên gia. Ngay sau khi tôi hoàn thành, anh ấy đã đưa ra một công cụ làm giảm các nỗ lực thử nghiệm theo mức độ lớn . Ông nói rằng hầu hết dựa trên những yêu cầu khó hiểu mà tôi đã thực hiện, hãy tìm hiểu.