Các nhà phát triển có nên chịu trách nhiệm cho các thử nghiệm khác ngoài thử nghiệm đơn vị, nếu vậy thì thử nghiệm nào là phổ biến nhất?

Tôi hiện đang làm việc trong một dự án khá lớn và tôi đã sử dụng JUnit và EasyMock cho chức năng kiểm tra đơn vị khá rộng rãi. Bây giờ tôi quan tâm đến những loại thử nghiệm khác mà tôi nên lo lắng. Là một nhà phát triển, tôi có trách nhiệm lo lắng về những thứ như chức năng, hoặc kiểm tra hồi quy? Có cách nào tốt để tích hợp những thứ này một cách có thể sử dụng trong các công cụ như Maven / Ant / Gradle không? Đây có phải là phù hợp hơn cho một Tester hoặc BA? Có những loại thử nghiệm hữu ích khác mà tôi đang thiếu?

Trách nhiệm của bạn là cố gắng cung cấp mã không có lỗi. Bạn nên viết, giúp viết hoặc đảm bảo các bài kiểm tra được viết hoặc thực hiện để giúp bạn tự tin hơn về mã bạn đang phân phối.

Lưu ý: Tôi không nói rằng bạn được yêu cầu cung cấp mã không có lỗi. Thay vào đó, bạn nên cố gắng viết mã tốt nhất có thể cho các yêu cầu bạn đã đưa ra. Một phần của việc có thể làm điều đó có nghĩa là mã phải được kiểm tra.

Cho dù điều đó có nghĩa là bạn chịu trách nhiệm cá nhân cho các bài kiểm tra chức năng và hồi quy chủ yếu là chức năng của cách tổ chức công ty của bạn. Tất cả các lập trình viên có tay nghề cao nhất mà tôi biết đừng tự hỏi mình "tôi có trách nhiệm viết các bài kiểm tra loại X không?". Thay vào đó, họ tự hỏi "tôi phải làm gì để đảm bảo mã của mình được kiểm tra đúng cách?". Câu trả lời có thể là viết các bài kiểm tra đơn vị, hoặc thêm các bài kiểm tra vào hồi quy, hoặc có thể có nghĩa là nói chuyện với một chuyên gia QA và giúp họ hiểu những bài kiểm tra nào cần được viết. Tuy nhiên, trong mọi trường hợp, điều đó có nghĩa là họ quan tâm đầy đủ về mã họ đang viết để đảm bảo nó được kiểm tra đúng cách.

Điểm mấu chốt: bạn phải chịu trách nhiệm cung cấp mã chất lượng cao. Nếu điều đó có nghĩa là bạn cần phải viết một số bài kiểm tra chức năng hoặc hồi quy, hãy làm nó.

Điều này có thể giúp bạn:

Q1 được viết bởi các nhà phát triển.

Q2 được tự động hóa bởi các nhà phát triển và được viết cùng với các doanh nghiệp và / hoặc người thử nghiệm.

Có những loại thử nghiệm hữu ích khác mà tôi đang thiếu?

Có thử nghiệm chấp nhận mà tôi khuyên dùng các khung kiểu BDD sử dụng ngôn ngữ Gherkin : JBehave (Java), Cucumber (Ruby), Behat (PHP), v.v. Loại thử nghiệm này có một số lợi thế so với thử nghiệm đơn vị:

• Các thử nghiệm không dễ đọc bởi những người không phải là nhà phát triển, vì vậy bạn có thể hiển thị chúng cho khách hàng
• Các thử nghiệm mô tả rõ ràng các quy trình kinh doanh mà không đi sâu vào chi tiết triển khai (ý tôi là việc triển khai không quan trọng - chắc chắn là vậy - nhưng sẽ tốt hơn khi bạn tách các yêu cầu kinh doanh khỏi chính mã)
• Kiểm tra làm những việc mà người dùng sẽ làm khi sử dụng ứng dụng của bạn
• Chúng dễ viết hơn (IMHO, có thể phụ thuộc vào ngôn ngữ và khung): không chế nhạo, ít chi tiết kỹ thuật

Kiểm tra chức năng có thể được tự động giống như kiểm tra đơn vị và rất hữu ích để kiểm tra cách các thành phần khác nhau trong dự án của bạn phối hợp với nhau và hệ thống của bạn phản ánh các quy tắc kinh doanh tốt như thế nào.

Ngoài ra, kiểm tra tự động này, đóng vai trò là bộ kiểm tra hồi quy và chấp nhận cho bất kỳ thay đổi lớn (hoặc nhỏ) nào bạn phải thực hiện đối với phần mềm (sửa lỗi, tái cấu trúc, thay đổi doanh nghiệp, chức năng mới, v.v.). Điều này giúp các nhà phát triển tự tin hơn rất nhiều để làm như vậy.

Có một số khung cho loại thử nghiệm này, chúng tôi đang sử dụng fitnesse với kết quả rất tốt. Có một thư viện rất tốt để kiểm tra các trang web (chúng tôi sử dụng nó để kiểm tra ứng dụng web và các dịch vụ web của chúng tôi) và nó tích hợp rất tốt với Maven và Jenkins .

Chúng tôi cũng đã từng thực hiện "thử nghiệm chức năng chéo", giữa các nhà phát triển, nhưng loại thử nghiệm này không "lặp lại", vì vậy tính hữu dụng của nó bị hạn chế ...

Là một nhà phát triển, tôi coi mình là người chịu trách nhiệm kiểm tra đơn vị tất cả mã của mình và đảm bảo tốt nhất khả năng của mình rằng nó không có lỗi. Đó là lý do tại sao chúng ta có rất nhiều công cụ theo ý mình, chẳng hạn như chế giễu. Mục tiêu của việc tạo các đối tượng nhạo báng trong các thử nghiệm của bạn chính xác là thử và cách ly mã của bạn khỏi thế giới "bên ngoài" và đảm bảo rằng nó hoạt động tốt và nếu có bất cứ điều gì thất bại, "đó không phải là lỗi của bạn".

Điều đó đang được nói, mặc dù thực tế đó không phải là lỗi của bạn và mã của bạn đang hoạt động như bình thường, điều đó không có nghĩa là bạn không thể giúp đỡ trong các thử nghiệm còn lại. Tôi tin rằng trách nhiệm của bạn là giúp đỡ và tích hợp công việc của bạn vào công việc do người khác thực hiện. Các nhóm phát triển CNTT nên làm việc mọi lúc như một cỗ máy được bôi dầu tốt, làm việc cùng với các bộ phận khác (như QA) như một nhóm lớn hơn để cung cấp phần mềm đáng tin cậy.

Nhưng đó là công việc của một nhóm, không chỉ của bạn.

Rõ ràng kiểm tra tích hợp ; chúng quan trọng hơn và khó viết hơn các bài kiểm tra đơn vị. Nó giống như xây dựng một ngôi nhà; với thử nghiệm đơn vị, bạn chỉ đảm bảo thực tế rằng các viên gạch là rắn và chống lại áp lực, nhiệt độ, độ ẩm và các điều kiện khác. Nhưng bạn không biết ngôi nhà trông như thế nào và ứng xử thế nào với những viên gạch ghép lại với nhau.

Vấn đề với các dự án lớn, đặc biệt là các dự án Java nằm trong một container là việc kiểm tra tích hợp rất khó khăn. Vì vậy, để tạo điều kiện cho các thử nghiệm tích hợp hệ thống trong các dự án lớn, cần có khung kiểm tra, được thực hiện đặc biệt cho dự án, đó là công việc của nhà phát triển để mã hóa nó. Gần đây, những cải tiến lớn đã được thực hiện trong lĩnh vực này và các nền tảng như Arquillian đơn giản hóa rất nhiều việc viết một khung kiểm tra (hoặc thậm chí thay thế nó).

Trong thế giới thực, bạn chỉ có trách nhiệm như nhóm / sếp của bạn khiến bạn phải chịu trách nhiệm. Nếu bạn được trả tiền hoặc được bảo hiểm để làm việc không ngừng nghỉ để tìm mọi trường hợp cạnh và góc cạnh và nhảy theo ý thích của sếp (hoặc tệ hơn là tiếp thị) về các lỗi logic kinh doanh, thì bằng mọi cách, bạn phải chịu trách nhiệm cho tất cả.

Vì vậy, nói cách khác, làm những gì được yêu cầu bởi phạm vi được cung cấp cho bạn. Đó là một bổ sung tuyệt vời để hiểu theo nghĩa thông thường hoặc thấy người khác sử dụng sản phẩm bạn đang xây dựng để hiểu được các trường hợp sử dụng và các vấn đề có thể khắc phục nhưng hãy đưa vấn đề này lên nhóm hoặc sếp của bạn trước khi "sửa chữa". Điều này bao gồm các công cụ lựa chọn của bạn. Tất cả những nỗ lực của bạn nên là một cái gì đó mọi người đang ở trên tàu.

Nếu câu hỏi của bạn là theo dõi lỗi hữu ích, tôi thích bugzilla, google docs, zendesk hoặc basecamp về hệ thống truyền thông.

Tôi không nghĩ rằng điều này đã được bảo hiểm - xin lỗi nếu tôi bỏ lỡ nó.

Một vấn đề là việc sử dụng hiệu quả thời gian của các nhà phát triển.

Các nhà phát triển thường thiếu các kỹ năng để giỏi một số loại thử nghiệm. Một phần, đây chỉ là tự nhiên. Đó là cùng một lý do tại sao các tác giả có biên tập viên. Rất khó để nhìn thấy những thiếu sót trong một cái gì đó nếu bạn quá gần với nó. Nhưng đó cũng là về bộ kỹ năng khác nhau và các chuyên ngành khác nhau.

Trong trường hợp đó, một nhà phát triển dành thời gian thử nghiệm rất kém về chi phí: các điều khoản lợi ích. Nhà phát triển đó sẽ làm việc hiệu quả hơn khi làm những việc khác và một người thử nghiệm chuyên gia sẽ làm việc hiệu quả hơn khi thực hiện thử nghiệm.

Tất nhiên, đó là những giả định khác nhau mà không nhất thiết phải hợp lệ. Trong một công ty nhỏ, chẳng hạn, có thể không có ý nghĩa gì khi tuyển dụng những người chuyên thử nghiệm. Mặc dù có thể có ý nghĩa hơn khi thuê nhân viên hỗ trợ thêm và yêu cầu họ thực hiện một số thử nghiệm hoặc ít nhất là để mọi người kiểm tra mã mà họ không tự viết.

Tôi tin rằng trách nhiệm của chúng tôi (cũng là một nhà phát triển) bao gồm tất cả các kịch bản thử nghiệm có thể có trước khi nó được phát hành cho QA. Mục đích của QA là xác nhận phần mềm. Thêm vào đó, việc tự khắc mã lỗi của bạn sẽ luôn khiến bạn trông ổn khi đến giờ QA.

Ai tốt hơn một nhà phát triển để biết trường hợp thử nghiệm nào là phù hợp nhất. Nhà phát triển phải chịu trách nhiệm thực hiện tất cả các thử nghiệm đơn vị, trong trường hợp có thể, nhà phát triển sẽ giúp viết và thực thi các kịch bản thử nghiệm. Vì điều này hiếm khi có thể trong thời gian dự án lớn nên nhà phát triển phải xem xét tất cả các trường hợp thử nghiệm. Ngoài ra, nhà phát triển nên có kiến ​​thức và sử dụng nhiều công cụ kiểm tra tự động có sẵn.

Trong sự nghiệp phát triển của tôi, tôi thấy rằng các dự án kết thúc với kết quả tốt hơn là có sự tích hợp chặt chẽ giữa các nhóm phát triển và các nhóm thử nghiệm.

ít nhất một thành viên từ mỗi đội cũng nên tham gia vào các cuộc họp lập kế hoạch và thực hiện khác.