Giá trị tương đối của hướng dẫn sử dụng so với thử nghiệm tự động


8

Tổ chức tôi làm việc gần đây đã thuê một nhân viên kiểm tra để chạy thử nghiệm thủ công, nhưng khi tôi hỏi về việc dành thời gian làm nhà phát triển để viết bài kiểm tra đơn vị thì câu trả lời là thử nghiệm thủ công sẽ tạo ra tiếng vang lớn hơn. Đó là điều gì đó cảm thấy sai đối với tôi và tôi đang tìm kiếm một phương tiện để đánh giá kiểm tra thủ công và tự động đối với nhau, đó là khoa học hơn là cảm giác ruột. Tôi không nói rằng không có nơi nào để kiểm tra thủ công - nhưng đối với tôi, ít nhất là kiểm thử tự động, để loại bỏ một số nhiệm vụ lặp đi lặp lại và nhàm chán hơn. Chúng tôi có một máy chủ xây dựng chạy một số thử nghiệm đơn vị và một số thử nghiệm selen - vì vậy nó không giống như ý tưởng về thử nghiệm tự động là không có, nhưng chỉ được xem là lợi tức đầu tư thấp hơn.

Tôi có thể hiểu rằng việc ai đó thực hiện kiểm tra toàn bộ từ đầu đến cuối hệ thống sẽ kiểm tra sản phẩm cuối cùng và cuối cùng đó là tất cả những gì người dùng quan tâm, nhưng nó chậm và rất lặp đi lặp lại. Kiểm tra hồi quy thủ công có nghĩa là lặp lại tất cả các thử nghiệm trước đó và xác nhận không có gì thay đổi và nếu có 4 đường dẫn qua một quy trình thì đó là 4 thử nghiệm thủ công có thể mất 5 phút mỗi thử nghiệm.

Vì vậy, có bất kỳ sự thật và số liệu có thể kiểm chứng mà tôi có thể sử dụng để làm cho trường hợp ngân sách thời gian cho thử nghiệm tự động? Đối với vấn đề đó, những bất lợi cho thử nghiệm tự động ngoài những người trong liên kết là gì?


1
Bỏ phiếu để đóng - không có đủ thông tin (và có lẽ không bao giờ có thể) về các chi tiết của tổ chức và phần mềm sẽ được kiểm tra để cung cấp câu trả lời có ý nghĩa. Bất kỳ câu trả lời có ý nghĩa nào cũng có thể quá cụ thể đối với cộng đồng nói chung
mattnz

@mattnz Tôi đánh giá cao rằng một câu trả lời đầy đủ sẽ đòi hỏi kiến ​​thức về tổ chức, văn hóa, tài chính, v.v. nhưng về mặt khái niệm tôi muốn biết liệu có bất kỳ đối số khách quan nào tôi có thể sử dụng để đưa ra trường hợp để kiểm tra tự động hơn không.
Simon Martin

Câu trả lời:


14

Tôi sẽ cẩn thận khi nghĩ về thử nghiệm "thủ công" so với thử nghiệm "tự động" trong bối cảnh hoàn vốn đầu tư (ROI). Đó là một dạng suy nghĩ sai lầm khi thảo luận về giá trị của tự động hóa (xem phần "Cỗ máy thời gian" của liên kết đó).

Tóm tắt sai lầm của cỗ máy thời gian là đây: cách duy nhất bạn có thể thực sự xác định ROI của phương pháp thử nghiệm là có một cỗ máy thời gian nơi bạn có thể truy cập vào tương lai và xem điều gì đã xảy ra. Vì bạn (rất có thể) không thể làm điều này, các ước tính ROI nên được xem là một heuristic tốt nhất, và không phải là một quy tắc cứng. Sử dụng thông tin hiện tại để đưa ra quyết định có căn cứ về nỗ lực thử nghiệm nhất định có hữu ích cho nhóm của bạn hay không.

Thay vào đó, khi nói đến thử nghiệm, hãy suy nghĩ về lĩnh vực nào trong sản phẩm của bạn cần được chú ý nhất và nơi có rủi ro lớn nhất. Có lẽ người ta đã xác định rằng thử nghiệm tích hợp đầu cuối có thể tìm thấy nhiều vấn đề nhất với ứng dụng của bạn. Ngay cả khi thử nghiệm đơn vị mang lại lợi ích, những lợi ích đó có thể không xứng đáng với chi phí liên quan (khiến nhà phát triển mua, viết và chạy thử nghiệm, v.v.). Tương tự như vậy, hãy thử suy nghĩ về lợi ích / chi phí thay vì lợi thế / bất lợi để thử nghiệm.


3
Có +1 đang chờ bạn nếu có thể tóm tắt điểm bạn liên kết đến trong câu trả lời của mình ...
vaughandroid

+1 là của bạn! :)
vaughandroid

4
+1 từ tôi cũng vậy, mặc dù tôi đoán có một cơ hội tốt rằng người đã nói với OP rằng "kiểm tra thủ công cung cấp tiếng nổ lớn hơn cho đồng tiền" cũng đã làm một số suy nghĩ ngụy biện.
Doc Brown

10

Trước tiên, bạn nên phân biệt rõ ràng các bài kiểm tra đơn vịcác bài kiểm tra tự động khác . Đó là hai điều khác nhau, với mục đích khác nhau.

Kiểm thử đơn vị là các kiểm tra để xác nhận các phần rất nhỏ trong mã của bạn. Chúng thường là các thử nghiệm hộp trắng, được viết bởi một nhà phát triển biết mã nguồn "đang thử nghiệm". Trong TDD, chúng được viết theo cách thử nghiệm đầu tiên, bởi một nhà phát triển sẽ viết mã nguồn sau khi anh ta viết thử nghiệm. Bản chất của những bài kiểm tra đó không thể được chuyển cho một "nhân viên kiểm tra" và nếu tổ chức của bạn không hoàn toàn sai lầm, bạn không cần phải hỏi ông chủ của mình nếu và khi nào bạn được phép viết chúng - giống như bạn không nên viết để hỏi sếp của bạn nếu và khi nào bạn được phép viết bình luận vào mã nguồn của mình.

Kiểm tra tích hợp, kiểm tra chấp nhận và kiểm tra hộp đen khác là một điều khác nhau. Nếu bạn có một nhân viên kiểm tra sẽ áp dụng các bài kiểm tra đó một cách thủ công và anh ta phải lặp đi lặp lại cùng một loại bài kiểm tra, thì anh ta cần phải tự động hóa, chứ không phải bởi bạn (tất nhiên, bạn nên làm rõ cho anh ta loại thử nghiệm nào bạn có thể tự động hóa, và loại nào không). Anh ta nên nói với bạn về loại thử nghiệm mà anh ta nghĩ rằng tự động hóa sẽ có ý nghĩa, và thử nghiệm nào không. Có lẽ anh ta sẽ tự động hóa, sử dụng một số công cụ kiểm tra hồi quy, hoặc anh ta sẽ nhờ bạn giúp đỡ để tạo ra một số công cụ cho anh ta.

Tất nhiên, khi bạn nghĩ rằng nếu anh ta không có kinh nghiệm hoặc không đủ thông minh để tự mình đi đến kết luận đó, bạn nên nói chuyện với anh ta (và nếu điều đó không có ích, có lẽ với sếp của bạn). Tuy nhiên, IMHO bạn chỉ nên làm điều này khi bạn có ấn tượng rằng nhân viên kiểm tra của bạn là một nút cổ chai trong sản xuất của bạn do một số tự động kiểm tra bị thiếu.


3

Mọi người luôn muốn các ví dụ và nghiên cứu bên ngoài, nhưng chúng không hiệu quả trong việc quản lý thuyết phục. Nếu kiểm tra thủ công thực sự là một nút cổ chai tại công ty của bạn, thì bạn sẽ có tất cả các ví dụ nội bộ bạn cần:

Một lỗi vô tình đi ra khỏi cửa. Bạn nói rằng nó được sử dụng để làm việc và yêu cầu nó được thêm vào các bài kiểm tra hồi quy. Người kiểm tra thủ công nói rằng nó sẽ làm cho kiểm tra hồi quy mất quá nhiều thời gian. Bạn đề nghị làm một bài kiểm tra tự động cho nó. Người kiểm tra thủ công hoan nghênh ý tưởng này vì anh ta đã cảm thấy choáng ngợp và muốn có nhiều thời gian hơn để tập trung vào các trường hợp thử nghiệm "thú vị" hơn. Với giọng nói của những khách hàng giận dữ vẫn vang lên bên tai, ban quản lý bắt đầu thấy quan điểm của bạn về tự động hóa thử nghiệm.

Nếu các cuộc họp như thế này không xảy ra tại công ty của bạn, sẽ không có nghiên cứu bên ngoài nào đưa ra trường hợp của bạn.

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.