Là phát triển thử nghiệm đơn vị hoặc thử nghiệm?

Tôi đã có một cuộc thảo luận với một người quản lý kiểm tra về vai trò của kiểm thử đơn vị và tích hợp. Cô yêu cầu các nhà phát triển báo cáo những gì họ có đơn vị và tích hợp đã thử nghiệm và làm thế nào. Quan điểm của tôi là thử nghiệm đơn vị và tích hợp là một phần của quá trình phát triển, không phải là quá trình thử nghiệm. Ngoài ngữ nghĩa, điều tôi muốn nói là các bài kiểm tra đơn vị và tích hợp không nên được đưa vào các báo cáo thử nghiệm và người kiểm tra hệ thống không nên quan tâm đến chúng. Lý luận của tôi dựa trên hai điều.

1. Các bài kiểm tra đơn vị và tích hợp được lên kế hoạch và thực hiện dựa trên giao diện và hợp đồng, luôn luôn. Bất kể bạn có sử dụng hợp đồng chính thức hay không, bạn vẫn kiểm tra xem ví dụ phương pháp nào được thực hiện, tức là hợp đồng.

   Trong kiểm thử tích hợp, bạn kiểm tra giao diện giữa hai mô-đun riêng biệt. Giao diện và hợp đồng xác định khi thử nghiệm vượt qua. Nhưng bạn luôn kiểm tra một phần giới hạn của toàn bộ hệ thống. Mặt khác, việc kiểm tra hệ thống được lên kế hoạch và thực hiện theo các thông số kỹ thuật của hệ thống. Thông số kỹ thuật xác định khi thử nghiệm vượt qua.

2. Tôi không thấy bất kỳ giá trị nào trong việc truyền đạt độ rộng và độ sâu của các bài kiểm tra đơn vị và tích hợp đến người kiểm tra (hệ thống). Giả sử tôi viết một báo cáo liệt kê loại thử nghiệm đơn vị nào được thực hiện trên một lớp lớp nghiệp vụ cụ thể. Anh ấy / cô ấy phải lấy gì từ đó?

   Đánh giá những gì nên và không nên được kiểm tra từ đó là một kết luận sai vì hệ thống vẫn có thể không hoạt động theo cách mà thông số kỹ thuật yêu cầu mặc dù tất cả các bài kiểm tra đơn vị và tích hợp đều vượt qua.

Điều này có vẻ như là cuộc thảo luận học thuật vô ích nhưng nếu bạn làm việc trong một môi trường chính thức nghiêm ngặt như tôi, điều đó thực sự quan trọng trong việc xác định cách chúng ta làm việc. Dù sao, tôi hoàn toàn sai?

Viết bài kiểm tra tự động là công việc của nhà phát triển; các thử nghiệm là một phần của codebase và nên được xử lý như vậy - chúng phải tuân theo cùng các đánh giá mã, tiêu chuẩn mã hóa, kỷ luật kiểm soát nguồn, v.v., như phần còn lại của dự án.

Chạy thử nghiệm cho biết được thực hiện vì hai lý do: Thứ nhất, như một công cụ trong việc hướng dẫn các nhà phát triển. Bạn chạy thử nghiệm để xác minh rằng mã bạn vừa viết thực hiện đúng như ý muốn, bạn sử dụng chúng làm tài liệu bổ sung và để xác minh rằng các thay đổi không phá vỡ bất kỳ chức năng hiện có nào. Nếu bạn làm TDD thực sự, các bài kiểm tra cũng là nguồn chính xác của các thông số kỹ thuật. Lý do thứ hai để sử dụng các bài kiểm tra là trong quá trình QA và triển khai. Chạy tất cả các bài kiểm tra tự động phải là một trong những bước đầu tiên trong mỗi vòng kiểm tra; chạy thử nghiệm tự động là rẻ (hầu như không cần nhân lực) và sẽ không có ý nghĩa gì khi thử nghiệm thủ công nếu thử nghiệm tự động thất bại.

Điều này có nghĩa là các trách nhiệm phải như thế này:

• Các nhà phát triển viết các bài kiểm tra tự động
• Các nhà phát triển chạy các thử nghiệm tự động riêng lẻ khi cần thiết, như là một phần của quy trình phát triển của họ
• QA chạy tất cả các bài kiểm tra tự động là một trong những giai đoạn đầu tiên của bài kiểm tra

Nếu bạn có máy chủ xây dựng, thì nhiệm vụ của QA (liên quan đến kiểm tra tự động) sẽ thực hiện để "mở báo cáo của máy chủ xây dựng và xác minh rằng mọi thứ đều xanh".

Tôi nghĩ rằng điều quan trọng nhất đối với bạn sẽ là làm rõ lý do tại sao cô ấy cần báo cáo đó.

Có thể có những giải thích khác nhau (như được đề xuất bởi một số câu trả lời), đòi hỏi các chiến lược rất khác nhau.

• nếu cô ấy là một người hợp lý, chỉ đơn giản là muốn có được thông tin để giúp đỡ công việc của nhóm thử nghiệm của cô ấy, thì nên tìm hiểu chung và tìm ra giải pháp phù hợp với cả hai bạn. Bạn có thể thảo luận với cô ấy về bản chất của kiểm tra đơn vị và sự khác biệt cơ bản giữa đơn vị so với kiểm tra chức năng / hệ thống / chấp nhận. Hy vọng bạn có thể khiến cô ấy hiểu rằng những công việc này ở các cấp độ rất khác nhau và không thể thay thế cho các cấp độ khác.
• nếu cô ấy là một người thích kiểm soát hoặc quan liêu, yêu cầu một báo cáo chỉ vì lợi ích của nó, bạn có thể tạo ra một cái gì đó để đáp ứng ý thích bất chợt của cô ấy với ít nỗ lực nhất (ví dụ như những gì @Doc đề xuất :-).
• nếu cô ấy tham gia một trò chơi quyền lực nào đó, bạn có thể đặt câu hỏi liệu cô ấy có quyền yêu cầu báo cáo từ các nhà phát triển hay không. Theo kinh nghiệm của tôi, các nhà phát triển thường không cần phải báo cáo cho bộ phận QA.

Tôi nghĩ vai trò của QA và Phát triển, và sự tương tác, có thể khác nhau rất nhiều giữa các tổ chức. Nhưng nói chung, trong nhóm của tôi, tôi nói với các thành viên tham gia về cơ bản giả vờ như không có đội QA, theo nghĩa là họ chịu trách nhiệm cho những thay đổi mà họ đang đưa vào sản xuất. Đổi lại, nhóm QA của chúng tôi không giả định nhiều về thử nghiệm của nhà phát triển và thực hiện một số lượng khá lớn thử nghiệm hệ thống như một tổng thể chức năng.

Vì lý do này, nhóm QA của chúng tôi không quan tâm nhiều đến những gì và không phải là đơn vị được thử nghiệm trước khi họ bắt đầu thử nghiệm.

Tôi nghĩ rằng nhóm QA sẽ hữu ích để hiểu những gì các bài kiểm tra đơn vị làm và không bao gồm, ở mức độ cao, để chúng ta có thể làm việc chung để xác định các khoảng trống và các khu vực có thể cần nghiêm ngặt hơn. Vì vậy, có thể đồng nghiệp của bạn là sau một bản tóm tắt cấp cao, trái ngược với các chi tiết đẫm máu.

Cô nhấn mạnh rằng các nhà phát triển báo cáo những gì họ có đơn vị và tích hợp đã thử nghiệm và làm thế nào.

Cô ấy thực sự đang cố gắng tranh luận về việc liệu loại thử nghiệm này có thực sự nằm trong lĩnh vực "phát triển" hay không, hay cô ấy chỉ đang cố gắng tìm hiểu xem mã của bạn được bao phủ bởi thử nghiệm đơn vị như thế nào? Chỉ cần nhìn vào thông tin bạn đã cung cấp, có vẻ như cô ấy chỉ muốn biết phần nào của mã được bảo hiểm và nơi cô ấy nên tập trung nỗ lực của nhóm mình.

Tôi đã làm việc trong một nhóm thử nghiệm ngay khi ra trường trước khi tôi chuyển sang vai trò phát triển và tôi có thể thấy điều này có thể có giá trị như thế nào đối với cô ấy và nhóm của cô ấy.

Tôi không thấy rằng nó quá quan trọng.

Nếu bạn không cung cấp cho họ QA / Kiểm tra và họ không thực hiện các thử nghiệm thích hợp và không thành công trong sản xuất, đó là lỗi của họ khi cho phép nó qua QA vào sản xuất mà không xác minh nó hoạt động như được chỉ định.

Nếu bạn cung cấp cho họ QA / Kiểm tra và họ không thực hiện các xét nghiệm thích hợp ... kết quả tương tự như khi bạn không cung cấp cho họ.

Tuy nhiên, nếu bạn cung cấp cho họ, họ cũng có thể so sánh chúng với thông số kỹ thuật và / hoặc đề xuất thử nghiệm nào có thể thiếu sót hoặc cần thay đổi vì họ đã tìm thấy lỗi.

Thực sự, tôi không thấy nhiều nhược điểm trong việc cung cấp chúng. Nó vẫn đang trên QA / thử nghiệm để xác nhận đối với thông số kỹ thuật. Nếu họ làm theo cách lười biếng và chỉ tin rằng thử nghiệm của bạn là đủ tốt bởi vì tất cả họ đều vượt qua, thì đó là thất bại trong công việc của họ. Miễn là họ vẫn có thông số kỹ thuật, kết quả của các bài kiểm tra đơn vị / tích hợp chỉ là vô nghĩa và không thể làm tổn thương bạn bằng cách này hay cách khác. Đây là lý do chúng tôi có dev và QA. Nhiều kiểm tra mà ứng dụng thực hiện theo quy định.

Các nhà phát triển mắc lỗi, QA mắc lỗi, lý tưởng là cả hai đều không mắc lỗi trên cùng một mặt hàng ... và nếu họ làm ... đó có khả năng là một nhà phân tích đã bỏ quả bóng viết một thông số không rõ ràng.

Kiểm thử đơn vị là trách nhiệm của các nhà phát triển rằng các thử nghiệm có thể hữu ích để hiểu cách các đoạn mã tự hoạt động. Một số có thể coi đây là một dạng tài liệu và do đó có một số giá trị mặc dù có thể có phí nếu các bài kiểm tra đơn vị được thay đổi thường xuyên.

Giá trị khác trong việc vượt qua các bài kiểm tra là điều này có thể tránh tăng gấp đôi trong các bài kiểm tra có thể là dư thừa về mặt đảm bảo chức năng cơ bản.

Ngoài ra còn có thử nghiệm chấp nhận của người dùng tách biệt với tất cả những điều này vì người dùng cuối có thể có sự hiểu biết của riêng họ về cách hệ thống hoạt động.

Nếu công ty của bạn có một phương pháp xác định để đảm bảo chất lượng sản phẩm của họ (nếu chúng tuân thủ SOX hoặc đang cố gắng cải thiện mức CMMI, thì có lẽ họ sẽ làm), sau đó các sản phẩm phải có thể đứng lên để kiểm tra để cho thấy rằng quy trình đã được theo dõi.

Thông thường, quy trình được xác định bao gồm kiểm tra đơn vị (đó là một điều tốt). Thật không may, điều này cũng có nghĩa là bạn phải ghi lại các bài kiểm tra đơn vị của mình và chứng minh rằng chúng đã được chạy để đứng lên kiểm toán. Vì vậy, điều đó có nghĩa là bạn cần một cách để báo cáo về các bài kiểm tra đơn vị của bạn.

Nhìn vào một công cụ như Sonar để giúp bạn hiểu - nó sẽ báo cáo mức độ bao phủ mã và kết quả của bài kiểm tra đơn vị của bạn.

Điều này thực sự phụ thuộc vào công ty, nhưng từ kinh nghiệm của tôi, tôi đã làm việc như một người kiểm tra hệ thống theo cách tiếp cận truyền thống nhưng cũng là người thử nghiệm làm việc trong một nhóm nhanh nhẹn trong mô hình CD, biết những gì đã được kiểm tra đơn vị và tích hợp là vô cùng hữu ích.

Chất lượng là trách nhiệm của nhóm - cả nhà phát triển, người thử nghiệm và Quản lý sản phẩm và làm việc cùng nhau là cách tốt nhất để đảm bảo điều đó.

Vì vậy, người quản lý kiểm tra muốn biết những gì đã được đơn vị và tích hợp thử nghiệm và đó là một công việc bổ sung thêm cho các nhà phát triển nhưng nó tiết kiệm toàn bộ công việc cho dự án! Bằng cách cung cấp thông tin cho người quản lý kiểm tra, họ có thể tập trung nỗ lực của nhóm kiểm tra vào những gì quan trọng và quan trọng. Như đã đề cập trước đây, nếu một khu vực mã không được kiểm tra đơn vị, nhóm có thể tập trung nỗ lực của họ ở đó so với khu vực được kiểm tra nhiều - tại sao lại nhân đôi nỗ lực? Tất cả bạn đang làm việc hướng tới cùng một mục tiêu cuối cùng là phần mềm chất lượng cao hơn được phát hành đúng thời gian.

Tôi nghĩ rằng sẽ có ích khi cung cấp loại điều này. Phạm vi kiểm tra đơn vị phải là một cái gì đó được biết đến bởi sự phát triển và thử nghiệm để họ có thể giải thích cho điều đó.

Rõ ràng, bạn phải kiểm tra các công cụ quan trọng trong kinh doanh bất kể điều gì. Bạn phải kiểm tra các chức năng thường được sử dụng cứng bất kể nó có phạm vi kiểm tra đơn vị tuyệt vời hay không. Không thể đau lòng khi cho họ biết những nơi khác được bao phủ bởi các bài kiểm tra đơn vị. Mã đã kiểm tra các trường hợp cạnh trong điều khiển nhỏ này chưa? Loại công cụ này là hữu ích để biết về tất cả các khía cạnh của doanh nghiệp.

Điều đáng nói là cách tiếp cận được thảo luận trong cuốn sách "Cách Google kiểm tra phần mềm": Kiểm tra và kiểm soát chất lượng là trách nhiệm của mọi người và các tiêu chuẩn rất nghiêm ngặt.

Các thực vai trò của những gì được truyền thống gọi là "kiểm tra" bộ phận, thực sự là năng suất phát triển; tức là tự động hóa để cho phép tổ chức đạt được mức độ nghiêm ngặt cần thiết về mặt kinh tế.