Những gì các nhà phát triển nên kiểm tra trước khi gửi công việc của họ cho người kiểm tra? [đóng cửa]


8

Có một danh sách kiểm tra mà nhà phát triển phải đi qua trước khi chuyển công việc của họ cho người kiểm tra không?

Ngoài ra, các điều kiện / trường hợp nhà phát triển phải chú ý là gì?

Câu trả lời:


5

Có một danh sách kiểm tra mà nhà phát triển phải đi qua trước khi chuyển công việc của họ cho người kiểm tra không?

Chắc chắn rồi. Lý tưởng nhất, danh sách kiểm tra này bao gồm hai mục:

  • Xác minh rằng chu trình tích hợp liên tục đã chạy đến khi hoàn thành và
  • Tạo một mục trong hệ thống theo dõi lỗi / tính năng cho những thay đổi sẽ đến QA

Danh sách kiểm tra thực sự được ẩn đằng sau chiến lược tích hợp liên tục của bạn. Vì danh sách này được quản lý tập trung và hoàn toàn tự động, các nhà phát triển cá nhân không thể ném mã của họ lên tường để QA "quên" kiểm tra thứ gì đó quan trọng trước khi gửi công việc của họ cho nhóm QA. Bạn biết rằng các nhà phát triển thường trở nên "hay quên" dưới áp lực thời gian, phải không?

Hệ thống tích hợp liên tục cần chạy một bản dựng, và chạy tất cả các bài kiểm tra đơn vị và tích hợp. Không cần phải nói rằng các nhà phát triển cần phải cung cấp các thử nghiệm đơn vị mới cho hệ thống tích hợp liên tục khi họ phát triển các tính năng mới và sửa lỗi.

Các nhà phát triển không nên chạm vào những gì phát ra từ hệ thống tích hợp liên tục trước khi đưa nó cho QA, thậm chí không cài đặt và nhanh chóng dùng thử. Nếu QA nói rằng bản dựng không được cài đặt, bạn cần sửa chu trình tích hợp liên tục của mình để đảm bảo rằng nó không tạo ra các tạo phẩm không thể cài đặt hoặc không hoạt động.

Bước thứ hai là một bước dễ chịu (đánh dấu một lỗi đã được sửa hoặc hoàn thành một tính năng), vì vậy, hiếm khi các nhà phát triển quên làm điều đó.


1
Nếu không có CI thì sao?
dlp

3

Mà phụ thuộc. Có một số triết lý:

  • Test Driven Development muốn bạn viết Regression / Unit-Test trước khi bạn bắt đầu viết mã.
  • lập trình viên biết các phần khó khăn của mã và có thể kiểm tra tương ứng
  • một người kiểm tra độc lập có thể tìm thấy lỗi mà nhà phát triển không bao giờ nghĩ tới. Ngoài ra, người kiểm tra có thể quen thuộc hơn với khu vực nơi phần mềm thực sự được sử dụng và có thể thực hiện một số xác nhận ("Bạn có đang xây dựng đúng không?" So với xác minh "Bạn có đang xây dựng đúng không?").

Vì vậy, mức độ thử nghiệm mà mỗi đối tác thực hiện tùy thuộc vào dự án và tổ chức của bạn. Điều quan trọng là phải đồng ý về mức độ này trước. Tất nhiên mã ít nhất phải biên dịch và chạy mà không ném lỗi.


2

Liệu nó làm những gì nó được thiết kế để làm? Liệu nó có ném các ngoại lệ thích hợp khi đưa ra đầu vào xấu? Có sử dụng được không? (áp dụng cho API cũng như UI).

Mã của bạn phải - theo sự hiểu biết tốt nhất của bạn - không có lỗi trước khi đưa nó cho người kiểm tra. Bạn nên làm bất cứ thử nghiệm nào bạn cần làm để cảm thấy thoải mái với chất lượng mã của riêng bạn.


1

Mọi thứ bạn có thể sao cho QA không trả lời lại cho bạn, CC nói với người quản lý của bạn rằng "bạn rõ ràng không kiểm tra khả năng giao hàng này". Bạn có thể kiểm tra đơn vị, tích hợp, hệ thống và thủ công (tức là bạn) theo ý của bạn. Không làm những điều đó sẽ chỉ lãng phí thời gian của QA.

Một anh chàng QA làm việc cho tôi sẽ yêu cầu "bằng chứng" rằng các nhà phát triển đã thử nghiệm khả năng cung cấp. Đây có thể là kết quả xUnit, đầu ra từ tập lệnh hoặc thậm chí là danh sách kiểm tra trên giấy. Đủ để nói rằng điều này đã ngăn các nhà phát triển chỉ chuyển tiếp cho anh ta đầu ra bản dựng.


0

Từ quan điểm của người thử nghiệm, sai lầm lớn nhất của nhà phát triển là cung cấp mã không được biên dịch.


2
Có thể cho rằng nếu mã không biên dịch thành một tệp thực thi có thể sử dụng được, thì nó không sẵn sàng cho bất cứ ai nhìn thấy, chứ đừng nói đến QA / người kiểm tra.
joshin4colours
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.