Là lập trình viên kiểm tra xấu?

Tôi biết điều này nghe có vẻ giống như những câu hỏi khác đã được hỏi, nhưng nó thực sự hơi khác. Dường như thường được coi là lập trình viên không giỏi trong việc thực hiện vai trò kiểm thử một ứng dụng. Ví dụ:

Joel trên phần mềm - Năm lý do hàng đầu (sai) Bạn không có người kiểm tra (nhấn mạnh của tôi)

Thậm chí đừng nghĩ đến việc cố gắng nói với các sinh viên tốt nghiệp CS đại học rằng họ có thể đến làm việc cho bạn, nhưng "mọi người phải làm một phần trong QA một thời gian trước khi chuyển sang viết mã". Tôi đã thấy rất nhiều điều này. Các lập trình viên không tạo ra những người kiểm thử giỏi và bạn sẽ mất một lập trình viên giỏi, người khó thay thế hơn rất nhiều.

Và trong câu hỏi này , một trong những câu trả lời phổ biến nhất nói (một lần nữa, tôi nhấn mạnh):

Các nhà phát triển có thể là người thử nghiệm, nhưng họ không nên là người thử nghiệm. Các nhà phát triển có xu hướng vô tình / vô ý tránh sử dụng ứng dụng theo cách có thể phá vỡ nó. Đó là bởi vì họ đã viết nó và chủ yếu kiểm tra nó theo cách nó nên được sử dụng.

Vì vậy, câu hỏi là lập trình viên xấu trong thử nghiệm? Có bằng chứng hay lập luận nào để hỗ trợ cho kết luận này? Có phải các lập trình viên chỉ xấu trong việc kiểm tra mã của riêng họ? Có bằng chứng nào cho thấy các lập trình viên thực sự giỏi kiểm tra không?

Ý tôi là gì khi "thử nghiệm?" Tôi không có nghĩa là thử nghiệm đơn vị hoặc bất cứ điều gì được coi là một phần của phương pháp được sử dụng bởi nhóm phần mềm để viết phần mềm. Ý tôi là một số phương thức đảm bảo chất lượng được sử dụng sau khi mã được xây dựng và triển khai theo bất cứ thứ gì mà nhóm phần mềm sẽ gọi là "môi trường thử nghiệm".

Câu hỏi dường như được hỏi cụ thể về Kiểm tra hệ thống , vì vậy đó là những gì tôi đang đề cập trong suốt câu trả lời này.

Tôi nghĩ rằng có một sự khác biệt quan trọng cần được thực hiện giữa việc trở thành một người xấu để chọn thực hiện kiểm tra và thực sự là kém trong kiểm tra.

Tại sao các lập trình viên rất tệ trong việc kiểm tra:

• Nếu bạn đã viết mã, bạn (nên) đã nghĩ ra càng nhiều cách càng tốt để mọi thứ có thể sai và đã xử lý chúng.
• Nếu việc tìm ra một lỗi đặc biệt rắc rối có nghĩa là bạn phải đi và sửa nó, trong một cơ sở mã bạn có thể bị bệnh, thì điều đó sẽ không giúp ích cho động lực của bạn.

Tại sao lập trình viên giỏi kiểm tra:

• Các lập trình viên có xu hướng là những người suy nghĩ logic, và giỏi làm việc một cách có hệ thống.
• Các lập trình viên có kinh nghiệm sẽ rất giỏi trong việc nhanh chóng xác định các trường hợp cạnh và do đó đưa ra các bài kiểm tra hữu ích. (Nếu có một quy trình thử nghiệm chính thức, thì hầu hết các trường hợp này đã được xác định và thử nghiệm trước khi thử nghiệm hệ thống.)
• Các lập trình viên khá giỏi trong việc đảm bảo rằng tất cả các thông tin hữu ích đều đi vào một báo cáo lỗi.

Tại sao lập trình viên là người kiểm tra tồi:

• Lập trình viên đắt hơn người thử nghiệm (trong phần lớn các trường hợp).
• Lối suy nghĩ về cơ bản là khác nhau: "Xây dựng một sản phẩm (đang hoạt động)" so với "Điều này không xảy ra với bất kỳ lỗi (chưa biết) nào trong đó."
• Người kiểm tra thường sẽ hiệu quả hơn - tức là thực hiện nhiều bài kiểm tra hơn trong cùng một khoảng thời gian.
• Lập trình viên chuyên về lập trình. Các chuyên gia QA chuyên thử nghiệm.

Tôi nghĩ rằng các lập trình viên rất tệ trong việc kiểm tra mã của riêng họ .

Chúng tôi muốn tin rằng mã của chúng tôi hoạt động hoàn hảo theo các yêu cầu và kiểm tra nó như vậy. Ở vị trí của tôi, chúng tôi kiểm tra mã riêng của mình, sau đó kiểm tra mã của nhau trước khi phát hành vào chu kỳ kiểm tra thực tế và nhiều lỗi đã được phát hiện theo cách đó hơn là chỉ kiểm tra mã của chính chúng tôi

Các lập trình viên chắc chắn là những người phù hợp để kiểm tra một số phần của hệ thống - ở những nơi họ là những người duy nhất có thể làm điều đó một cách hiệu quả.

Các lập trình viên một nơi có xu hướng rất tệ trong việc kiểm tra là toàn bộ bit "sử dụng UI như người dùng bình thường" - họ không phải là người dùng bình thường và không cư xử như họ. Ví dụ:

• Các lập trình viên có xu hướng rất giỏi trong việc nhận các mục nhập văn bản vừa phải. Một vấn đề khá phổ biến tôi thấy là dẫn đầu hoặc đặc biệt là dấu cách. Hầu hết mọi người không có vẻ như họ, nhưng các lập trình viên giỏi có lẽ tôn giáo về việc làm cho chuỗi của họ chỉ là chuỗi đúng mà không có không gian bên ngoài.
• Các lập trình viên có xu hướng trở thành bàn phím, tận dụng các tab và các phím tắt khác để tăng tốc công việc. Người dùng bình thường có xu hướng lấy chuột giữa các trường.
• Các lập trình viên có xu hướng hiểu những gì hệ thống đang nói với họ thay vì bỏ qua các thông báo lỗi và chỉ cần nhấp vào OK.

Vì vậy, người dùng bình thường làm rất nhiều thứ mà các lập trình viên không làm. Bạn không thể hoàn toàn dựa vào nhóm nhà phát triển cho UAT.

Ở cấp độ kỹ thuật (kiểm tra đơn vị, kiểm tra tích hợp, kiểm tra hồi quy) các lập trình viên có lẽ là những người đủ điều kiện để trở thành người kiểm tra, bởi vì các loại kiểm tra này có thể tự động hóa và do đó nên được tự động hóa, đó là điều cần phải lập trình.

Nhưng tôi không nghĩ đó là những gì bạn đang nói, và tôi khá chắc chắn đó không phải là ý nghĩa của Joel Spolsky - đó là phần còn lại, thử nghiệm thủ công thực tế: biến một tài liệu yêu cầu và thông số chức năng thành một kịch bản thử nghiệm và sau đó thực hiện tỉ mỉ kịch bản này đối với sản phẩm hoàn chỉnh.

Để trở thành một người thử nghiệm giỏi đòi hỏi những phẩm chất chủ yếu là trực giao với những người làm nên một lập trình viên giỏi. Có một chút trùng lặp - bạn phải có khả năng suy nghĩ phân tích, bạn cần một mối quan hệ nhất định với máy tính nói chung - nhưng khác với điều đó, các kỹ năng của một người thử nghiệm khác nhau nhiều. Điều đó tự nó không có nghĩa là bạn có thể có cả hai bộ kỹ năng, và trên thực tế, khá nhiều người có thể làm được. Tuy nhiên, để trở thành một lập trình viên thực sự giỏi đòi hỏi một sự lười biếng nhất định (mong muốn tự động hóa công việc của bạn đi), trong khi một người thử nghiệm thực sự tốt cần sự kiên trì (kiểm tra tất cả ba nghìn trường mẫu cho sự không nhất quán), và do đó, ngay cả những lập trình viên đó làm gì có thể là một người thử nghiệm thường ghê tởm ý tưởng.

Và sau đó là sự thiên vị có chọn lọc: Một lập trình viên đã tham gia vào một dự án, dù chỉ là ngoài lề, đã có một số kiến ​​thức bên trong về cơ sở mã hóa, và sẽ gặp khó khăn khi tiếp cận nó với một tâm trí trống rỗng, từ quan điểm của người dùng cuối . Nó thậm chí không cần phải rõ ràng, như trong "Tôi biết nút này hoạt động, vì vậy tôi sẽ chỉ lưu ý 'vượt qua'"; nó có thể tinh tế hơn, và những hiệu ứng tinh tế đó có thể dẫn đến các trường hợp cạnh quan trọng bị bỏ qua trong thử nghiệm.

Từ kinh nghiệm của tôi, vâng, lập trình viên là những người thử nghiệm tồi. Tôi thường thấy những người khác và bản thân mình "Huh, nhưng tôi đã kiểm tra điều đó trước khi tôi đăng ký!" khi đối mặt với một người kiểm tra tái tạo lỗi trước mặt bạn.

Tại sao? Chà, tôi không chắc tại sao lại như vậy nhưng có lẽ đó là vì chúng tôi muốn thấy những thứ đó hoạt động. Hoặc chúng tôi chỉ muốn vượt qua thử nghiệm tính năng này hoặc tính năng đó.

Dù sao, kiểm thử không phải là một kỹ năng chúng tôi đã học và chúng tôi không làm việc như một lập trình viên vì chúng tôi rất giỏi trong việc phá vỡ các tính năng. Ngoài ra, chúng tôi có thể không biết làm thế nào để lập kế hoạch kiểm tra phù hợp hoặc tất cả những thứ khác mà QA làm. Chúng tôi không còn đủ điều kiện để thực hiện công việc của người kiểm tra hơn là người kiểm tra đủ điều kiện để triển khai đường dẫn kết xuất 3d mới của bạn.

Như trong câu hỏi, kiểm tra không có nghĩa là bất cứ điều gì tự động mà thực sự kiểm tra bằng cách sử dụng chương trình.

Có nhiều cấp độ thử nghiệm. Việc kiểm tra "mức độ thấp" có thể và phải được thực hiện bởi các nhà phát triển. Tôi nghĩ tại đơn vị testig.

Mặt khác, thử nghiệm "cấp cao" hoàn toàn là một điều khác. Nói chung, tôi nghĩ rằng các nhà phát triển là người thử nghiệm tồi không phải vì họ bỏ lỡ các kỹ năng, mà bởi vì rất khó thay đổi cách suy nghĩ và cách làm việc trong một thời gian.

Tôi sử dụng để thử kiểm tra càng nhiều mã càng tốt, nhưng sau ít nhất 10 phút được thực hiện bởi người kiểm tra, một cái gì đó để xem xét lỗi hoặc tăng cường phát sinh. Điều này có nghĩa là kiểm tra một cái gì đó bạn tạo ra, là một công việc khó khăn. Bạn biết nhấp vào đâu, bạn biết khi nhấp, bạn biết logic kinh doanh, bạn có thể biết dữ liệu được duy trì như thế nào. Bạn là một vị thần bạn sẽ không bao giờ gục ngã.

Những loại thử nghiệm có nghĩa là gì? Nếu bạn có nghĩa là kiểm tra toàn diện thì tôi có thể thấy một số lý do để nói có mặc dù tôi nghi ngờ hầu hết mọi người sẽ kém trong thể loại này nếu người ta coi tất cả các kết hợp đầu vào có thể là một yêu cầu cho thử nghiệm đó.

Tôi có thể thừa nhận rằng nhà phát triển thiết kế phần mềm có thể có tầm nhìn đường hầm khi nói đến mã là gì để xử lý và bỏ qua một số trường hợp ranh giới có thể chưa được xem xét. Ví dụ: nếu tôi xây dựng một biểu mẫu web có một số, n và sau đó in từ 1 đến n trên màn hình, tôi có thể bỏ lỡ một số trường hợp đặc biệt như nếu không có gì được nhập hoặc một số không phải là số tự nhiên như e hoặc pi . Chương trình phải làm gì trong những trường hợp này có thể là nghi vấn.

Test Driven Development sẽ là một ví dụ về phương pháp phát triển đưa thử nghiệm vào một ánh sáng khác có thể đưa ra một cái nhìn khác ở đây.

Các lập trình viên rất xác định các bài kiểm tra khi họ xác định các bài kiểm tra trước khi viết mã. Với thực hành, họ thậm chí còn tốt hơn.

Tuy nhiên, khi xác định các bài kiểm tra cho mã họ đã viết, họ không làm rất tốt. Họ sẽ có những điểm mù giống nhau trong thử nghiệm mà họ đã có khi viết mã.

Sử dụng lập trình viên để làm kiểm tra thủ công chỉ là ngớ ngẩn. Tự kiểm tra là đủ ngớ ngẩn; làm cho lập trình viên làm điều đó là vô cùng ngớ ngẩn. Nó đắt tiền và xua đuổi các lập trình viên có thẩm quyền.

Một loại thử nghiệm mà tôi đặc biệt thấy các nhà phát triển thất bại là thử nghiệm nếu yêu cầu đã được đáp ứng. Những gì các nhà phát triển nghĩ rằng một cái gì đó trong một yêu cầu có nghĩa là gì và những người thử nghiệm nghĩ nó có nghĩa là gì thường là hai điều hoàn toàn khác nhau.

Tôi có thể nghĩ về một người gần đây, nơi develoepr được yêu cầu thực hiện xuất khẩu delta và nhà phát triển nghĩ rằng có được bất kỳ hồ sơ nào đã không được gửi một lần và những người thử nghiệm nghĩ rằng nó có nghĩa là có bất kỳ sự phục hồi mới và bất kỳ thay đổi nào. Họ phải quay lại khách hàng để tìm ra ai đúng. Tôi mã đã xem xét nó và tôi đã đưa ra giả định tương tự rằng nhà phát triển đã làm về yêu cầu. Bởi vì về mặt logic nếu bạn muốn bao gồm các bản cập nhật, bạn sẽ đề cập đến chúng. Và tôi thường giỏi phát hiện ra những điều mơ hồ đó bởi vì tôi đã từng ở cuối người dùng.

Vì vậy, các nhà phát triển khác đang thực hiện thử nghiệm sẽ có xu hướng đưa ra nhiều giả định giống nhau bởi vì họ cũng sẽ đưa ra một số giả định nhất định như "họ sẽ có nhiều chi tiết hơn nếu họ có nghĩa là X phó Y vì có rất nhiều chi tiết được trả lời trước khi tôi có thể làm Nhưng những người viết yêu cầu không nghĩ như vậy. Vì vậy, những người nghĩ giống như yêu cầu hơn, các nhà văn cần kiểm tra các giả định của nhà phát triển và ai đó không phải là nhà phát triển là người tốt hơn thậm chí còn thấy có vấn đề.