Lập trình viên làm thử nghiệm

Tôi tự hỏi làm thế nào điển hình cho các lập trình viên để chuyển đổi mũ và thử nghiệm trên công việc của nhau. Giả sử rằng nhóm muốn thực hiện một cách tiếp cận "trách nhiệm chung" đối với các nhiệm vụ chuyển từ được chính thức hóa sang phát hành -

1. Có phải là một ý tưởng tốt để các lập trình viên làm việc kiểm thử phần mềm miễn là họ không viết một tính năng?

2. Điều này có xảy ra thường xuyên không?

3. Ở mức độ nào một lập trình viên có thể "kiểm tra" công việc của chính họ?

Ngay cả với TDD và kiểm tra đơn vị, vẫn không cần một bộ máy kiểm thử phần mềm trong quy trình phát triển?

1. Có các lập trình viên kiểm tra các tính năng của họ có thể là một túi hỗn hợp. Một mặt, lập trình viên có thể "quá quen thuộc" với khối mã và chỉ cần kiểm tra các tham số loại pass / fail nổi tiếng. Mặt khác, nếu lập trình viên "quá quen thuộc" với mã của họ siêng năng làm cho tính năng hoạt động, họ sẽ có thêm kiến ​​thức về các trường hợp bên lề có thể gây ra sự cố, vì họ biết hoạt động bên trong của chức năng và các lỗ hổng tiềm năng trong đó

2. Tôi nghĩ rằng điều này xảy ra thường xuyên hơn không. Tôi nghĩ rằng phần lớn các cửa hàng lập trình ngoài kia đang ở trong các nhóm nhỏ, hoặc chịu nhiều áp lực phải hoàn thành công việc. Điều này không đủ khả năng cho họ sự sang trọng của một QA / Tester chuyên dụng trong nhóm của họ, vì vậy mọi người phải rút phần của họ. Vẫn còn một số lượng khá lớn các cửa hàng "cao bồi đơn độc" ngoài kia, nơi mỗi nhà phát triển chịu trách nhiệm chính cho toàn bộ vòng đời của ứng dụng. Đó là trường hợp của tôi.

3. Tôi sẽ trì hoãn trở lại # 1 cho việc này. Tôi nghĩ rằng một lập trình viên có khả năng kiểm tra công việc của chính họ, bên ngoài mô hình TDD, vì họ có kiến ​​thức sâu sắc về cách thức hoạt động của tính năng này. Họ cần phải cẩn thận để "lùi lại" và có thể bao quát các vấn đề cụ thể và rộng lớn với mã (chẳng hạn như "ngón tay mập" một trường nhập văn bản - điều gì xảy ra?), Nhưng điều đó có thể được thực hiện.

Các nhà phát triển kiểm tra mã của nhau không nên được thực hiện thay vì kiểm tra bởi một chuyên gia QA tập trung, nhưng sẽ rất tuyệt vời ngoài rađể kiểm tra bởi một người kiểm tra tập trung. Các nhà phát triển có kỹ năng suy nghĩ về cách làm cho sản phẩm hoạt động. Người thử nghiệm là những người duy nhất trong nhóm (BA, PM, dev, v.v.), những người tập trung vào việc tìm ra cách sản phẩm có thể thất bại. Đó là một suy nghĩ rất khác. Hãy suy nghĩ về công việc "hết giờ" của bạn - ví dụ, khi bạn đang phác thảo các dự án trong đầu khi tắm. Bạn có nghĩ, "Ồ, tôi cá rằng đây sẽ là một cách tốt để khắc phục tính năng đó!" hoặc bạn có nghĩ, "Này, tôi nên xem liệu tôi có thể khiến mã đó thất bại nếu tôi làm NÀY không!"? Công việc không chỉ xảy ra trong văn phòng và các nhà phát triển có thể sẽ không làm việc để phá mã trong "thời gian rảnh" của họ. Người kiểm thử cũng nên tích lũy nhiều kiến ​​thức về các công cụ và kỹ thuật kiểm tra và kinh nghiệm lựa chọn giữa chúng mà các nhà phát triển không có,

Đồng thời, kinh nghiệm liên ngành là một điều rất tốt và luôn có lợi ích khi làm việc với mã của các nhà phát triển khác. Việc các nhà phát triển nỗ lực kiểm tra nhiều hơn trước khi một người thử nghiệm / QA cụ thể xem mã có thể sẽ dẫn đến mã chất lượng tốt hơn, điều này có thể giúp quay vòng thử nghiệm nhanh hơn, bảo hiểm thử nghiệm tốt hơn và thậm chí có thể giảm (nhưng không loại bỏ) số lượng người kiểm tra chuyên dụng cần thiết.

Nếu bạn thực sự phải đánh đổi do tính khả dụng của số lượng đầu thấp hoặc nếu nhóm kỹ năng cho QA đặc biệt tệ ở nơi bạn ở, thì thiết lập này sẽ tốt hơn không có gì - nhưng mục tiêu vẫn là để có được một người thử nghiệm thực sự trước khi đội phát triển quá lớn.

Tôi chưa bao giờ thấy một phương pháp thử nghiệm tồi.

Các lập trình viên có nên kiểm tra mã riêng của họ? Vâng - rõ ràng.

Những người khác nên kiểm tra mã của họ? Vâng - rõ ràng.

Là thử nghiệm bảo hiểm là một ý tưởng tốt? Đúng.

Thử nghiệm Monte-Carlo có tốt không? Đúng.

Chúng tôi có thể có những gì chúng tôi xem là một thiết lập khá tốt để thử nghiệm, và sau đó một người mới thực hiện một số thử nghiệm. Đoán xem cái gì? Họ tìm thấy những vấn đề chưa được tìm thấy trước đây.

Một dấu hiệu cho thấy chất lượng đang trở nên tốt là khi tỷ lệ phần trăm các vấn đề được tìm thấy trong thử nghiệm không thực sự là lỗi tiếp cận 100%.

Có một phong trào phát triển lớn và đang phát triển được gọi là Phát triển dựa trên thử nghiệm hoặc TDD. Tôi không tự nhận mình là một chuyên gia và thực sự đã phải vật lộn để thực hiện phương pháp này theo mặc định, nhưng ý chính là nhà phát triển trước tiên viết một bài kiểm tra thất bại sau đó viết mã để vượt qua bài kiểm tra đó.

Khái niệm này có nhiều điểm mạnh. Một là bạn có một bộ thử nghiệm tuyệt vời. Một điều nữa là vì việc này được thực hiện theo nhiều bước nhỏ mà bạn biết ngay nếu bạn phá vỡ một cái gì đó. Một trong những điều mà tôi đã thấy với phương pháp này và các "nhiệm vụ" thử nghiệm khác là bạn không được các nhà phát triển chạy xung quanh để đưa vào các tính năng bổ sung vì chúng tuyệt vời hoặc gọn gàng. Luôn có một chi phí cho một tính năng và nhiều lần nhà phát triển không thấy hoặc cảm thấy chi phí đó. Với TDD họ làm, vì bạn viết một trường hợp thử nghiệm trước khi bạn viết mã.

Có những phần mở rộng trên lý thuyết này cũng như đưa bài kiểm tra đến nguồn yêu cầu nơi chuyên gia kinh doanh viết một tập các bài kiểm tra chức năng tạo nên thông số kỹ thuật và sau đó các nhà phát triển phát triển tập hợp các trường hợp kiểm thử đó.

Vì vậy, với TDD, nhà phát triển viết rất nhiều bài kiểm tra, một số người lập luận cho tỷ lệ 1: 1 cho các dòng mã kiểm tra với các dòng mã.

Xoay quanh vấn đề này - Tôi nghĩ rằng có giá trị lớn cần có trong việc tuyển dụng ít nhất một vài người cho đội ngũ kiểm tra giỏi hơn họ về mã hóa. Đó là một bộ kỹ năng khác với sự phát triển và tôi nghĩ - ngay cả với TDD và các thực hành nhanh nhẹn khác - rằng ai đó có con mắt tốt để thử nghiệm là vô giá đối với chất lượng sản phẩm.

Vì vậy, dễ hỏi - người kiểm thử nên mã hóa nhiều như người viết mã đang kiểm tra.

IMO - vâng, nên có ít nhất một chút hỗn hợp. Có một quan điểm về đầu bên kia của việc sản xuất một sản phẩm giúp bạn luôn tròn trịa và có thể nâng cao những hiểu biết mới.

Tôi nghĩ rằng trách nhiệm của một lập trình viên là phải thực hiện một số lượng khá cẩn thận trước khi kiểm tra một đoạn mã và ký tên, điều này có nghĩa là:

• Viết bài kiểm tra đơn vị kỹ lưỡng.
• Kiểm tra mã đó trong một kịch bản sử dụng thực tế và cố gắng phá vỡ nó - tức là tương tác với nó như nó sẽ được sử dụng trong sản xuất.

...

• Sau đó, một lập trình viên khác nên xem lại mã đó và các bài kiểm tra đơn vị.

• Sau đó, một người kiểm tra chuyên dụng / người QA nên kiểm tra mã đó.

Tôi không nghĩ rằng có bất kỳ lý do nào để không thực hiện lần đầu 3. Và tôi không nghĩ rằng có bất kỳ lý do nào để không thực hiện bước cuối cùng, nhưng có một thử nghiệm chuyên dụng kiểm tra mỗi bit mã là các công ty nhỏ hơn và đắt hơn (ít nhất là nghĩ) rằng đây là thứ xa xỉ mà họ không thể mua được.

Cá nhân, tôi không tin rằng việc kiểm tra cụ thể nên bị loại khỏi phương trình. Tôi nghĩ rằng bạn cần tìm những người ít nhất không phát triển cùng một sản phẩm (hoặc có thể là mô-đun lớn), điều này sẽ cho phép một số lập trình viên khác thử nghiệm, miễn là họ thực sự không biết việc triển khai là gì. Tôi nghĩ điều quan trọng nhất là dù họ có làm hay không, các nhà phát triển sẽ có thể hoạt động như những người thử nghiệm và những người thử nghiệm có thể hoạt động như những nhà phát triển. Có cả nền tảng kiến ​​thức và sự quen thuộc làm cho việc phát triển, thử nghiệm và giao tiếp giữa hai người trở nên dễ dàng hơn nhiều.

1. Có, mặc dù họ không "làm việc như kiểm thử phần mềm". Viết bài kiểm tra là một phần của công việc lập trình viên. Ngoài ra, viết bài kiểm tra tốt là một kỹ năng. Không thể kiểm tra đúng các tính năng của riêng bạn không phải là một lỗ hổng trong thử nghiệm, đó là một chỉ số thiếu kỹ năng *.

2. Tôi chắc chắn sẽ hy vọng như vậy.

3. Trong khi một lập trình viên hoàn toàn có thể kiểm tra công việc của họ, có thể có giá trị trong một quy trình QA bên ngoài. Tôi hiếm khi thấy rằng đó là trường hợp, tuy nhiên.

Mục tiêu của thử nghiệm là ba lần:

1. Để thúc đẩy sự phát triển
2. Để quản lý sự thay đổi
3. Để cung cấp sự tự tin

Kiểm thử nhà phát triển có thể và nên phục vụ tất cả các mục đích này. Nếu thử nghiệm dành cho nhà phát triển là đủ cho họ, thì không cần thử nghiệm thêm.

* Lập trình cặp khiến việc viết các bài kiểm tra tồi tệ như vậy thậm chí còn khó hơn vì bạn không bao giờ kiểm tra các tính năng của riêng mình.