Các thử nghiệm đầu cuối và tích hợp có đáng cho các công cụ quan trọng không phải là nhiệm vụ không?

Người ta biết rằng các bài kiểm tra đầu cuối và tích hợp rất tốn kém. Tất nhiên, nếu chúng tôi phát triển các ứng dụng mà mọi người có thể chết nếu mọi thứ không ổn, đó là một khoản đầu tư đáng giá. Tuy nhiên, trong các ứng dụng mà lỗi không phải là kết thúc của thế giới, sẽ không rẻ hơn nếu bỏ qua các bài kiểm tra E2E và kiểm tra tích hợp hoàn toàn và thay vào đó tạo ra một kế hoạch dự phòng nếu có sự cố? Giống như một bài kiểm tra thủ công về câu chuyện của người dùng + bài kiểm tra đơn vị + sử dụng ngôn ngữ được nhập tĩnh đủ?

Ví dụ như nếu một cửa hàng web bị mất đơn hàng, thay vào đó họ có thể gửi hàng miễn phí + một mặt hàng khác như một lời xin lỗi. Người dùng cuối có thể thậm chí còn hạnh phúc hơn theo cách đó và tổng thể công ty tiết kiệm tiền.

Tôi đoán câu hỏi của tôi là, nói chung, một bài kiểm tra tích hợp và bài kiểm tra E2E có chi phí bao nhiêu và nó tiết kiệm được bao nhiêu tiền? Có cách nào để tính toán rủi ro / chi phí cho việc này không?

Không quan trọng bạn có thực hiện các bài kiểm tra tích hợp và E2E hay không, bạn cũng cần một kế hoạch dự phòng . Không bao giờ mong đợi một hệ thống không có lỗi chỉ vì nó đã được thử nghiệm.

Do đó, trong ước tính chi phí của bạn, bạn không so sánh chi phí để thực hiện các thử nghiệm E2E với chi phí ước tính kế hoạch dự phòng của bạn trong trường hợp thất bại, bạn so sánh:

• Chi phí để thực hiện các bài kiểm tra E2E bằng tay (nhiều lần, trước mỗi lần phát hành mới)

so với

• Chi phí xây dựng (và duy trì) các bài kiểm tra E2E tự động

Trong trường hợp bạn có thể sử dụng các thử nghiệm E2E đó nhiều lần, thường sẽ có một số lần chạy thử trong đó chi phí đạt đến điểm hòa vốn. Đó phải là số liệu bạn áp dụng khi muốn lập kế hoạch trước các bài kiểm tra E2E mà bạn sẽ thực hiện thủ công và bạn sẽ tự động hóa.

Lưu ý rằng có thể có một số loại thử nghiệm E2E có thể được thực hiện dễ dàng, trong đó ROI ngay lập tức rõ ràng, nhưng cũng có những loại thử nghiệm E2E trong đó việc phát triển và bảo trì có thể tốn kém hơn khi thực hiện thủ công trong khoảng thời gian vài năm.

Có lẽ chống lại bằng trực giác, thử nghiệm tự động thực sự có thể làm giảm thời gian phát triển so với không thử nghiệm. Vì vậy, đó là một chiến thắng giành chiến thắng.

Ý tưởng là các bài kiểm tra đóng góp trên một số cấp độ

1. Buộc thu thập yêu cầu nghiêm ngặt và đặc điểm kỹ thuật

   Điều này làm cho một tác động rất lớn đến tốc độ phát triển. Không quay lại yêu cầu chi tiết hơn, không hiểu lầm, không có tính năng không cần thiết vv

2. Các nhà phát triển biết khi nào một tính năng hoàn thành

   Hầu hết các thử nghiệm được thực hiện bởi các nhà phát triển trong quá trình viết mã thay vì kiểm tra kiểm tra một sản phẩm hoàn chỉnh. Tự động hóa thử nghiệm này làm giảm khối lượng công việc này

3. Lỗi được giới thiệu bởi các tính năng mới được phát hiện ngay lập tức.

   Chúng có thể dễ dàng khiến bạn mất một lần chạy nước rút và yêu cầu viết lại toàn bộ tính năng nếu chúng không bị phát hiện.

4. Chu kỳ phát hành nhanh hơn

   Điều này có nghĩa là ít mã hơn trong chuyến bay, có nghĩa là ít hợp nhất hơn, có nghĩa là ít công việc hơn và ít phức tạp hơn cho các nhà phát triển

Đặc biệt nếu bạn có một thiết lập khung thử nghiệm, việc viết các thử nghiệm này mất ít thời gian hơn bạn tiết kiệm được trong các hiệu quả này.

Thêm vào đó, bạn tiết kiệm thời gian thử nghiệm thủ công, cộng với việc bạn nhận được một sản phẩm tốt hơn vào cuối.

Câu trả lời của tôi? Có lẽ, có lẽ là không .

Các xét nghiệm EOE là tốt khi chúng rất đơn giản. Nếu bạn đang có kế hoạch bao gồm các kịch bản cơ bản, bạn có thể quản lý để đạt được một số lợi thế với các bài kiểm tra EOE. Nhưng nếu bạn có một ứng dụng thực sự phức tạp và lớn (nhiệm vụ quan trọng hay không), bài kiểm tra EOE này sẽ tốn kém để duy trì và bạn cần biết kịch bản của mình để định giá nếu có giá trị.

Một số năm trước , Blog Thử nghiệm của Google thảo luận về chủ đề này. Tôi chỉ có thể đồng ý với tác giả. Một bài kiểm tra tốt cần phải nhanh chóng , đáng tin cậy và cách ly các thất bại , các tính năng mà các bài kiểm tra EOE không có khả năng cung cấp cho bạn.

Tôi đã làm việc trên một ứng dụng có hơn 12 giờ thử nghiệm từ đầu đến cuối bao gồm rất nhiều tình huống. Cuối cùng, chúng tôi đã quản lý để phân phối các thử nghiệm này trên các máy khác nhau, kiểm soát việc bắt đầu, thực hiện và kết thúc các thử nghiệm, thu thập và hợp nhất các kết quả. Ứng dụng được thử nghiệm là một ứng dụng nguyên khối (những gì dễ dàng hơn để đưa lên và chạy để kiểm tra) và là cơn ác mộng để duy trì các thử nghiệm.

Phần lớn thời gian chúng tôi đang duy trì các bài kiểm tra thay vì bắt lỗi từ kết quả của họ. Khám phá nguồn gốc của một lỗi trong bài kiểm tra đầu cuối mất rất nhiều thời gian. Chúng tôi cũng đã xử lý rất nhiều thử nghiệm "âm tính giả" và mất ít thời gian để hiểu vấn đề và khắc phục sự cố: Vấn đề tải ứng dụng Java, yếu tố dự kiến ​​không tìm thấy trên trang (cộng với các vấn đề khác về tốc độ tự động hóa), duy trì mã truy vấn chỉ được sử dụng trong kiểm tra bộ nhớ cơ sở dữ liệu (vì truy vấn ban đầu sử dụng mã cụ thể của cơ sở dữ liệu), v.v.

Tất cả điều này cần mọi người để duy trì và chạy. Cuối cùng, chúng tôi bắt đầu xóa một số bài kiểm tra EOE và thay thế chúng bằng nhiều bài kiểm tra đơn vị / tích hợp.

Vì vậy, lời khuyên bảo thủ của tôi là sử dụng kim tự tháp thử nghiệm từ Google:

Như một phỏng đoán đầu tiên, Google thường đề xuất mức chia 70/20/10: kiểm tra đơn vị 70%, kiểm tra tích hợp 20% và kiểm tra đầu cuối 10%. Sự pha trộn chính xác sẽ khác nhau cho mỗi đội, nhưng nói chung, nó nên giữ lại hình dạng kim tự tháp đó.

Theo kinh nghiệm của tôi, thử nghiệm E2E, bất kể mức độ quan trọng của ứng dụng, luôn thận trọng. Tôi luôn nghĩ về trường hợp xấu nhất, nếu mọi thứ trở thành hình quả lê, bạn có thoải mái đứng trước quản lý và biện minh cho cách tiếp cận của mình không? Nếu không, sau đó bạn cần thay đổi cách tiếp cận của bạn. Nhiều tổ chức giảm thiểu tầm quan trọng và tài nguyên được phân bổ để thử nghiệm, nhưng hãy yên tâm rằng khi có sự cố xảy ra, mọi người sẽ tìm kiếm ai đó để đổ lỗi và nếu bạn đưa ra quyết định hạn chế thử nghiệm hoặc đưa ra lời khuyên đó, thì bạn là người nổ súng hàng.

Phát triển phần mềm tất cả quá thường xuyên đòi hỏi một mắt về chính trị tổ chức.

"Chúng tôi biết rằng các thử nghiệm đầu cuối và tích hợp rất tốn kém."

Tôi nghĩ rằng tôi không đồng ý với khẳng định này.

Thứ nhất, các thử nghiệm E2E là những gì quan trọng đối với người dùng cuối và có thể là lựa chọn hiệu quả nhất / chi phí thấp nhất để thử nghiệm các hệ thống phức tạp. Chẳng hạn, khi ai đó mua xe, hầu hết mọi người không kéo nó ra từng mảnh và bắt đầu kiểm tra carb, hộp số, bánh xe một cách cô lập. Thay vào đó, họ mang nó đi lái thử.

Thứ hai, về mặt công cụ, E2E không có xu hướng làm chậm quá trình phát triển nội bộ của sản phẩm và tồn tại lâu hơn. Nếu bạn nghĩ về nó, bề mặt chức năng thực tế của hầu hết các sản phẩm hiếm khi thay đổi nhiều như vậy, trong khi bên trong nó có thể chịu mọi sự phát triển. Kết quả là, một khi công cụ kiểm tra đã hoạt động, nó thường kéo dài rất tốt. Ví dụ, nếu chúng ta quay trở lại tương tự xe hơi. Trường hợp thử nghiệm "mang nó cho một ổ đĩa" tương tự sẽ hoạt động khá nhiều trên Ford Model T như trên Tesla. Như các khoản đầu tư vào đường lăn, hầm gió, thiết lập thử nghiệm rò rỉ, v.v ... Có bao nhiêu thử nghiệm thành phần bên trong sẽ có ROI tốt như vậy trong suốt vòng đời của họ?

Trong đó thử nghiệm E2E có xu hướng đắt hơn / không phù hợp mặc dù trong thiết lập ban đầu và nếu nó được sử dụng để thử và kiểm tra mọi thứ. Thực tế, tôi nghĩ cách tốt nhất để tránh cái bẫy này là các ưu tiên tự động hóa việc kiểm tra những thứ:

1. Dễ dàng tự động hóa và không cần bảo trì nhiều để tiếp tục chạy.
2. Dành nhiều thời gian nhất để áp dụng các quy trình kiểm tra thủ công nhất quán, đầy đủ, phù hợp.
3. Rủi ro khiến bạn hoặc sếp của bạn trông như những kẻ ngốc nếu sản phẩm được phát hành cùng với nó bị hỏng.

Sử dụng bất kỳ hình thức kiểm tra nào kể cả E2E mà bạn cho là phù hợp. Tập trung vào những người mặc dù.

Bạn thực sự không thể so sánh chi phí của các bài kiểm tra tích hợp với chi phí của một trường hợp tốt nhất trong đó một lỗi chỉ ảnh hưởng đến một đơn hàng. Một lỗi logic sẽ có khả năng ảnh hưởng đến một số lượng lớn các đơn đặt hàng. Nói một lỗi có nghĩa là không có khoản thanh toán nào bị bắt - điều này có thể gây ra hậu quả tai hại cho bất kỳ doanh nghiệp nào.

Bạn nên hỏi lỗi trường hợp xấu nhất mà thực tế có thể kết thúc trong sản xuất là do thiếu kiểm tra E2E. Và hãy nhớ luật Murphys.

Tôi giả sử rằng câu hỏi này là về các ứng dụng web doanh nghiệp.

Đề xuất của tôi cho những thứ quan trọng:

• Thực hiện kiểm tra tự động cho API phụ trợ của bạn, đảm bảo rằng phụ trợ hoạt động như mong đợi. Các thử nghiệm này phải được viết bởi các nhà phát triển trong khi triển khai API.
• Đừng quan tâm đến các kiểm tra UI tự động, nghĩa là thực hiện kiểm tra lối vào bằng tay.

Tôi nghĩ rằng hầu hết các bài kiểm tra nên ở cấp độ API hoặc cấp độ thành phần. Tôi không quan tâm đến các bài kiểm tra đơn vị chỉ thực hiện một số chức năng nội bộ.