Tôi có nên yêu cầu kiểm thử đơn vị từ các lập trình viên? [đóng cửa]

Tôi làm việc tại một nơi mà chúng tôi mua rất nhiều dự án CNTT. Chúng tôi hiện đang sản xuất một tiêu chuẩn cho các yêu cầu hệ thống cho việc trưng dụng các dự án trong tương lai. Trong quá trình đó, chúng tôi đang thảo luận về việc chúng tôi có thể yêu cầu thử nghiệm đơn vị tự động từ các nhà cung cấp của mình hay không.

Tôi tin chắc rằng kiểm thử đơn vị tự động thích hợp là cách duy nhất để ghi lại chất lượng và tính ổn định của mã. Mọi người khác dường như nghĩ rằng thử nghiệm đơn vị là một phương pháp tùy chọn chỉ liên quan đến nhà cung cấp. Do đó, chúng tôi sẽ không đưa ra yêu cầu kiểm tra đơn vị tự động, kiểm tra liên tục, báo cáo bảo hiểm, kiểm tra kiểm tra đơn vị hoặc bất kỳ loại nào. Tôi thấy chính sách này cực kỳ bực bội.

Tôi hoàn toàn không ở đây?

Vui lòng cung cấp cho tôi các đối số cho bất kỳ ý kiến.

Tôi tin chắc rằng, kiểm thử đơn vị tự động thích hợp là cách duy nhất để ghi lại chất lượng và tính ổn định của mã.

Vấn đề là bạn sẽ không (hoặc rất hiếm khi) nhận được thử nghiệm đơn vị tự động thích hợp bằng cách buộc nó vào người. Đó là một cách tốt để có được các bài kiểm tra tồi tệ và tăng chi phí của các dự án.

Cá nhân, tôi sẽ hướng tới một số nhu cầu hoặc SLA liên quan đến chất lượng; bất kể nó được thực hiện như thế nào 10 năm trước các bài kiểm tra đơn vị không thường xuyên nhất. Bạn không muốn còng tay các nhà cung cấp của mình sau 10 năm nữa khi chúng tôi có các phương pháp tốt hơn để đảm bảo chất lượng nhưng chính sách lỗi thời của bạn yêu cầu họ sử dụng cách cũ.

Cá nhân tôi nghĩ rằng trong trường hợp của bạn, bạn nên suy nghĩ về các bài kiểm tra chấp nhận thay thế:

• Bạn có một hộp đen được trao cho bạn, và bạn mong đợi nó hành xử theo một cách nhất định.
• Bạn sẽ không trả tiền cho đến khi nó.
• Viết các bài kiểm tra đơn vị thực hiện hành vi bạn cần xem, và nếu chúng thất bại, chúng phải sửa nó.

Cũng lưu ý rằng đây là một vấn đề của niềm tin. Nếu bạn không tin tưởng nhà cung cấp của mình thì bạn cần lấy mã nguồn, kiểm tra nó và tự biên dịch nó. Bất cứ điều gì ít hơn thế có nghĩa là bạn ít nhất tin tưởng họ một số .

Tôi tin chắc rằng, kiểm thử đơn vị tự động thích hợp là cách duy nhất để ghi lại chất lượng và tính ổn định của mã.

Nó làm tôi ngạc nhiên về cách suy nghĩ phổ biến này. Tự động, có. Kiểm tra đơn vị (một mình), không. Có nhiều cách để kiểm thử phần mềm tự động hơn là kiểm tra đơn vị. Còn về tích hợp, hệ thống, chức năng, QA thì sao? Vì một số lý do, mọi người có xu hướng nghĩ, "Ok, vì vậy chúng tôi có các bài kiểm tra đơn vị phù hợp. Hoàn thành với thử nghiệm, hãy gọi nó vào tối thứ sáu!" . Kiểm tra đơn vị chỉ là khởi đầu.

Dù sao, trở lại chủ đề. Tôi đồng ý với những người khác nói rằng việc ép buộc bất cứ ai vào bất cứ ai có thể sẽ mang lại kết quả ngược lại với những gì mong muốn. Bạn không bao giờ biết làm thế nào nhóm làm việc, có thể họ có bộ phận kiểm tra trị giá hàng triệu đô la và không bao giờ viết bài kiểm tra đơn vị.

Ở công việc đầu tiên của tôi, tôi đã từng làm việc ở một nơi mà chúng tôi có 0 bài kiểm tra đơn vị (chúng tôi là một đám đàn em ném vào những thứ ít nhiều nghiêm trọng). Tin hay không, nó đã làm việc. Chắc chắn, không ai được tâm sự tại sao lỗi này đã cố định, hoặc những gì sửa chữa này đã phá vỡ, nhưng nó làm việc. Đã có lúc một số lỗi hoàn toàn ngẫu nhiên xuất hiện, nhưnggậy bóng chày và có nguy cơ bị cháy hầmmột số giờ thêm có thể làm việc kỳ diệu. Có thể các nhà cung cấp của bạn sử dụng các kỹ thuật tương tự ?

Tôi nghi ngờ rất nhiều rằng quản lý của bạn sẽ sẵn sàng trả tiền cho thử nghiệm đơn vị thích hợp trong hợp đồng. Kiểm tra đơn vị phù hợp có chi phí tương đương với mã mà họ kiểm tra, nhưng cung cấp ít giá trị cảm nhận cho người dùng cuối để họ sẽ không bị coi là có giá trị như nhau. Không có công ty phát triển chất lượng nào sẵn sàng dành nỗ lực phát triển cho các bài kiểm tra đơn vị với chi phí thấp hơn các bộ phận khác, vì họ không bị tổn thương vì công việc, họ có thể tìm thêm 2 hợp đồng mà không mất nhiều thời gian như nhau yêu cầu kiểm tra đơn vị.

Các bài kiểm tra đơn vị yêu cầu sẽ có khả năng tăng báo giá nhận được của bạn đến một mức độ không hợp lý, và có khả năng sẽ là sự nhượng bộ đầu tiên được thực hiện để có được mức giá thấp hơn.

Chi phí của việc không có các bài kiểm tra đơn vị phụ thuộc vào số tiền bạn sẽ gia hạn / hỗ trợ mã cho mình. Việc kiểm tra các phần của mã để có ý tưởng về chất lượng cũng rất quan trọng.

Nếu bạn chỉ mua các dự án để bạn có thể sử dụng chúng như thư viện của bên thứ 3 và không tin rằng bạn sẽ sửa đổi chúng, thì nguy cơ mã chất lượng thấp sẽ ít hơn, miễn là nó thực sự hoạt động.

Cuối cùng, đây là những quyết định kinh doanh, mặc dù bạn phải chắc chắn rằng bất kỳ ai đang đưa ra quyết định đều biết về việc định giá kỹ thuật. Nếu bạn cần giải thích cho quản lý, hãy giải thích nó giống như mua một chiếc xe đã qua sử dụng. Cuối cùng, tùy thuộc vào người mua để quyết định xem nó có xứng đáng hay không, nhưng đưa nó đến một thợ máy là một ý tưởng tốt để bạn biết rằng bạn sẽ không nhận được một quả chanh.

Bạn đang trả tiền, bạn có thể yêu cầu bất cứ điều gì bạn muốn, bao gồm các bản sao / báo cáo của tất cả các thử nghiệm đơn vị của họ.

Bạn thậm chí có thể viết các bài kiểm tra, hoặc ít nhất là các thông số kỹ thuật kiểm tra.

Tôi đồng ý với quan điểm của bạn ở chỗ nó là thước đo rất tốt về chất lượng mã. Nếu một nhà cung cấp từ chối nhu cầu này, nó sẽ gióng lên hồi chuông cảnh báo, tại sao họ không muốn làm điều đó - họ có tiêu chuẩn chất lượng thấp và sử dụng phím tắt?

Bạn hoàn toàn đúng khi dự án của bạn cần kiểm tra đơn vị tự động, kiểm tra liên tục, báo cáo bảo hiểm và kiểm tra kiểm tra đơn vị.

Tuy nhiên, những thứ đòi hỏi sẽ không đạt được kết quả mà bạn mong muốn như những người khác đã nêu chi tiết.

Thử thách của bạn là giải thích và thuyết phục mọi người - một kỹ năng khó hơn nhiều!

Tôi sẽ bắt đầu ban đầu với việc quản lý, giải thích các thử nghiệm chuyên nghiệp và thử nghiệm và tiền chi trả. Hãy cẩn thận để không truyền đạt cảm xúc đằng sau các câu như 'Tôi viết bài kiểm tra đơn vị PROPER' (viết hoa của bạn). Bạn không muốn 'hét' các từ (như TẤT CẢ CAPS ngụ ý) bạn sẽ thuyết phục và thuyết phục mọi người để chính họ có thể chọn giải pháp phù hợp.

Cuối cùng, nếu bạn không thể giới thiệu những phương pháp này và khiến họ chấp nhận bạn đang ở đâu, cộng với nếu bạn đam mê chúng như bạn nói (điều đó tốt!) Tôi sẽ đến một công ty khác vì có nhiều người coi trọng những điều này và sẽ chào đón bạn trên tàu. Chỉ cần chắc chắn rằng bạn thẳng thắn về họ trong các cuộc phỏng vấn để họ biết niềm đam mê của bạn nằm ở đâu và liệu bạn có phù hợp hay không.

Buộc kiểm tra tự động trên một ai đó sẽ không đạt được kết quả mà bạn mong muốn như @Joachim Sauer và @Telastyn đã chỉ ra trong các nhận xét của họ. Đối với nhiều người, thử nghiệm đơn vị tự động là một sự thay đổi lớn trong suy nghĩ của họ. Bởi vì nhiều người viết mã hoạt động, nhưng không thể kiểm chứng được. Tôi có thể viết một trang web ASP.NET trong đó tất cả logic, truy vấn cơ sở dữ liệu, quy tắc kinh doanh, đối tượng, v.v. đều nằm trong mã phía sau. Trang sẽ hoạt động chứ? Vâng. Có thể kiểm tra bằng cách sử dụng thử nghiệm đơn vị tự động? Tuyệt đối không. Nếu một nhà cung cấp không có kiểm thử đơn vị tự động thì sẽ mất khá nhiều nỗ lực để tìm hiểu cách viết bài kiểm tra đơn vị đúng cách và kết quả của việc học này, viết lại hoặc tính lại mã của họ để dễ kiểm tra hơn. Rất có thể họ sẽ chuyển chi phí đó cho bạn.

Thực tế của vấn đề là nhà cung cấp đang cung cấp cho bạn một sản phẩm, có thể là một ứng dụng hay ứng dụng windows và bạn mong đợi nó hoạt động 99% thời gian. Chắc chắn có lỗi ở đây và ở đó, nhưng đối với hầu hết các phần nên hoạt động. Đó là một kỳ vọng hợp lý, đặc biệt nếu nhà cung cấp muốn giữ lại doanh nghiệp của bạn. Nếu đó là một hộp đen thì việc họ làm cho nó hoạt động như thế nào không quan trọng, họ có thể sử dụng một làn sóng người thử nghiệm, hoặc một căn phòng đầy khỉ ngẫu nhiên nhấn phím. Miễn là nó hoạt động. Nhưng họ sẽ cần cung cấp cho bạn một số loại tài liệu khác về cách sử dụng nó.

Tuy nhiên, nếu họ đưa cho bạn mã nguồn để bạn có thể sửa đổi nó, thì tôi sẽ mong đợi các bài kiểm tra đơn vị. Tôi sẽ không làm việc với một công ty không cung cấp các bài kiểm tra đơn vị. Làm thế nào khác bạn sẽ biết một sửa đổi bạn thực hiện không vòi toàn bộ?

Thử nghiệm đơn vị là một chỉ dẫn về cách nhà cung cấp đó xử lý rủi ro trong chu kỳ phát triển. Những người sử dụng các bài kiểm tra đơn vị làm giảm giá trị rủi ro và chất lượng của các bài kiểm tra đó là một dấu hiệu cho thấy mức độ rủi ro đã được quản lý.

Như đã nói, các bài kiểm tra đơn vị không xác định mức độ rủi ro mà dự án đang cố gắng giải quyết. Nó cũng không đóng vai trò gì trong việc giảm thiểu rủi ro do các thực tiễn lập trình xấu đưa ra.

Do đó, bạn có thể có một nhà cung cấp có các thực hành kiểm tra chắc chắn nhưng vẫn tiếp tục viết mã có rủi ro cao trong khi nhà cung cấp khác không kiểm tra nhưng viết mã rủi ro thấp. Nếu hai nhà cung cấp cung cấp cùng một sản phẩm, thì tốt nhất nên đi với nhà cung cấp rủi ro thấp.

Điều này chỉ có thể được đánh giá bằng cách phỏng vấn, cố vấn và tìm hiểu về tính cách và kỹ năng của những người liên quan với nhà cung cấp đó.

Tôi thấy bài viết này về việc mua phần mềm tùy chỉnh khá hữu ích: http://blog.8thlight.com/paul-pagel/2012/06/20/entusinessurs-guide-to-buying-software.html

Câu hỏi số một mà họ đề nghị đặt ra là liệu nhà cung cấp có viết bài kiểm tra hay không.

Đồng ý với những người khác rằng yêu cầu kiểm tra đơn vị sẽ dẫn đến thử nghiệm vì mục đích thử nghiệm; một cái gì đó rất trái ngược với những gì bạn muốn.

Trong quá trình kiểm tra các nhà cung cấp của bạn; hỏi họ quá trình phát triển của họ là gì vì thử nghiệm chỉ là một phần của quá trình đó.

Họ có một quy trình xây dựng tự động? Họ có tuân theo một số mô hình quản lý? Họ có người kiểm tra được đào tạo đúng cách và một nhóm đảm bảo chất lượng độc lập ? Làm thế nào về tiêu chuẩn tài liệu?

Những điều này sẽ giúp bạn đánh giá chất lượng tổng thể của quy trình của họ và lần lượt chất lượng của những gì họ sản xuất.

Dường như với tôi rằng bao gồm yêu cầu này sẽ có rất ít lợi ích thiết thực, vì nó sẽ không thể thực thi.

Bạn có thể yêu cầu mã cho các thử nghiệm thực tế hoặc báo cáo về những thử nghiệm thực tế đã được chạy và thông qua. Nếu đó là một dự án độc quyền, nhà cung cấp có thể sẽ không muốn cung cấp điều đó, vì nó có thể rất gợi ý về các chi tiết của mã, và có thể sẽ được thực hiện để cung cấp chi tiết triển khai ở mức độ thấp và cho biết cách thực hiện việc làm. Tại một số điểm, phải có một số niềm tin.

Nếu bạn không, họ cũng có thể thổi bay bạn nhưng chỉ cần đánh dấu vào ô bên cạnh "chạy bộ kiểm tra đơn vị" để đáp ứng yêu cầu bằng cách viết một bài kiểm tra vượt qua nếu tiện ích của họ biên dịch và chạy hoặc một nửa tương tự cố gắng.

Vì vậy, trong khi các bài kiểm tra đơn vị tự động là một thực tiễn đáng khen ngợi, tôi không nghĩ rằng việc thực hiện nó từ các nhà cung cấp bên ngoài là thực tế.

Như nhiều người đã chỉ ra, việc buộc người bán phải viết các bài kiểm tra đơn vị (hoặc tốt hơn, kết hợp các bài kiểm tra đơn vị tự động và tích hợp) để thực hiện hợp đồng có thể sẽ không mang lại kết quả chất lượng cao. Mặt khác, tôi đồng ý rằng cho đến nay, kiểm thử tự động là phương pháp tốt nhất hiện đang được sử dụng để đảm bảo chất lượng mã.

Tôi nghĩ rằng mã được viết bằng các bài kiểm tra đơn vị dễ bảo trì hơn nhiều so với mã được viết trước và có các bài kiểm tra đơn vị được thêm vào sau đó. Nó buộc các mô-đun và phụ thuộc tối thiểu. Các kiểm tra tích hợp cũng cần thiết để xác minh tính chính xác của mã, nhưng chúng không có tác động tương tự đến chất lượng của mã như được viết. Về bản chất, các thử nghiệm tích hợp tự động có thể được thêm vào sau khi thực tế, nhưng các thử nghiệm đơn vị có tác động lớn nhất khi được viết bằng mã gốc.

Lời khuyên của tôi cho tình huống của bạn là tìm kiếm những người bán hàng thích viết mã với các bài kiểm tra đơn vị và chọn họ hơn những người bán hàng có xu hướng không viết mã với các bài kiểm tra thống nhất. Nếu ban quản lý sẽ trả tiền cho nó, hãy đặt các bài kiểm tra tự động trong hợp đồng nhưng CHỈ NẾU NGƯỜI GIỚI THIỆU ĐƯỢC SỬ DỤNG ĐỂ VIẾT MÃ B WITHNG KIỂM TRA ĐƠN VỊ.

Trước tiên hãy có được các ưu tiên ...

Trong vai trò là khách hàng, mối quan tâm chính của bạn không phải là kiểm tra đơn vị

Nếu bạn đang sử dụng các nhà cung cấp sản xuất phần mềm cho bạn thì bạn thực sự không nên lo lắng nếu họ đang sử dụng phương pháp này hay phương pháp khác. Cổ phần của bạn là để có được một loại giải pháp sẽ giúp đạt được mục tiêu của bạn. Điều duy nhất bạn nên quan tâm là thời tiết đó có thể chấp nhận được hay không. Đó là lý do tại sao chúng tôi có thử nghiệm chấp nhận vì nó nằm trong trách nhiệm của bạn để đảm bảo rằng bạn có được những gì bạn muốn. Tại thời điểm quan trọng của sự chấp nhận của khách hàng, tiền sẽ được giao dịch từ túi của công ty bạn vào túi của nhà cung cấp.

Bạn có thể yêu cầu kiểm tra đơn vị theo yêu cầu có thể giao được nhưng có một số vấn đề di truyền với chúng, nghiêm trọng nhất là không có cách nào chắc chắn trước để xác định số liệu:

• Số lượng thử nghiệm đơn vị được chấp nhận là gì?

Có nên có 10 bài kiểm tra? Làm thế nào về 100 bài kiểm tra? Làm thế nào về 1000 bài kiểm tra? Trên thực tế, khá khó để xác định ngay từ đầu bạn sẽ cần bao nhiêu bài kiểm tra. Con số thực tế không thể xác định được thực sự ... giống như vấn đề tạm dừng ... nhưng chúng tôi không giải quyết vấn đề đó.

Bạn chỉ muốn phần mềm có các bài kiểm tra đơn vị để bạn có thể tiếp tục phát triển. Các bài kiểm tra đơn vị không cho biết những gì bạn đã phá vỡ, nhưng chúng rất phù hợp để cho bạn biết khi nào mã có lỗi hồi quy.

• Mức độ bao phủ mã được chấp nhận là gì?

"100%, tất nhiên!" bạn nghĩ Thật không may, số liệu đó là sai lệch; ngay cả khi bạn có phạm vi bảo hiểm 100% mã, bạn có thực sự chắc chắn mọi thứ đang hoạt động như mong đợi? Có thể có bảo hiểm 100% nhưng không được thực hiện.

Những gì bạn thực sự cần làm là thử nghiệm khám phá, tức là tìm một người thực sự giỏi trong việc phá vỡ mọi thứ và để họ làm thử nghiệm. Để tìm ra các lỗi mà không có nhà phát triển nào đã nghĩ đến.

Ngoài ra 100% đôi khi không thể đạt được với các thử nghiệm đơn vị thuần túy nếu bạn có một số hack hiệu suất cần thiết và sử dụng các mẫu thiết kế khó kiểm tra (tìm kiếm "singleton" và "tdd" trong công cụ tìm kiếm yêu thích của bạn và bạn sẽ tìm thấy một số ví dụ).

Bạn muốn phần mềm được phân phối hoạt động và tài liệu đặc tả là bảo hành duy nhất của bạn mà nó sẽ làm.

Bạn sẽ cần thử nghiệm ở cấp độ cao hơn

Tài liệu đặc điểm kỹ thuật của bạn phải được xác minh bằng cách nào đó. Mỗi điểm phải được thông qua với các nhà cung cấp của bạn có mục tiêu và tiêu chí chấp nhận rõ ràng. Một tổ chức QA hoạt động tốt (hoặc một người thử nghiệm tuyệt vời nếu bạn có ngân sách và trong phạm vi hạn chế) sẽ cung cấp các trường hợp thử nghiệm để kiểm tra các tiêu chí chấp nhận này. Bạn cũng cần một người để xác minh những tiêu chí chấp nhận.

Có một số cách để xác minh mục tiêu của bạn và nếu ai đó nói với tôi rằng bạn không thể đặt bất kỳ mục tiêu chất lượng, hiệu suất và hiệu quả lành mạnh nào, tôi sẽ đánh vào đầu họ bằng những cuốn sách lớn và nặng về kiểm tra khả năng khám phá, hiệu suất và khả năng sử dụng. Có thể dễ dàng quá mức với các mục tiêu, nhưng kiến ​​thức và giao tiếp sẽ giúp bạn thiết lập các mục tiêu thực tế.

Tôi không phải là luật sư nhưng hầu hết các hợp đồng dự án (về cơ bản là mẹ của tất cả các thông số kỹ thuật cho dự án) Tôi đã đọc thường có một tiêu chí tỷ lệ lỗi quy định có bao nhiêu lỗi được coi là chấp nhận được. Các lỗi thường được xác định thông qua mức độ nghiêm trọng, các lỗi dừng hiển thị được tìm thấy bởi QA có dung sai thấp trong khi các nhược điểm nhỏ có khả năng chịu đựng cao. Trong các dự án thực tế, rất khó để yêu cầu phần mềm phải có 0 lỗi. Thời hạn thường dừng lại để thực hành đó. Chính tại những tình huống này, bạn phải bắt đầu mặc cả phạm vi.

Hầu hết các phần mềm được cung cấp mà tôi thấy thường không được cung cấp với các bài kiểm tra đơn vị. Bạn có thể lập luận rằng các nhà cung cấp phải đủ chuyên nghiệp để cung cấp điều này, tuy nhiên lý do chính khiến bạn muốn kiểm tra đơn vị được giao cho bạn là để đảm bảo rằng bạn không gặp phải lỗi hồi quy và cũng cho phép tái cấu trúc. Trong cuộc sống thực với các dự án có thời hạn chặt chẽ, cả nhà cung cấp và khách hàng sẽ hạ thấp phạm vi và các bài kiểm tra đơn vị thường sẽ ra khỏi cửa sổ và bị xóa khỏi danh sách các sản phẩm được yêu cầu.

Có một chút buồn khi phần mềm nguồn mở cấu hình cao được phân phối với các bài kiểm tra đơn vị nhưng một nhà phát triển phần mềm chuyên nghiệp thì không thể, phải không?

Vì vậy, khi nào tôi, với tư cách là một khách hàng, có thể quan tâm đến thử nghiệm đơn vị?

Tôi sẽ lập luận rằng lần duy nhất bạn thực sự quan tâm đến kiểm thử đơn vị là nếu phần mềm có thể phân phối là một thành phần tự cung cấp không được thực hiện như một chương trình độc lập, trong đó kiểm tra đơn giản nhất bạn có thể làm là kiểm tra đơn vị . Các thư viện lớp sẽ là một loại sản phẩm có thể được phân phối cùng với các bài kiểm tra đơn vị.

Làm thế nào để bạn biết các nhà cung cấp không viết bài kiểm tra đơn vị.

Có thể quản lý và nhà cung cấp đã có một cuộc họp và nhà cung cấp cho biết, mã có giá $ X và các bài kiểm tra đơn vị có giá $ Y. Penny quản lý chèn ép cho biết chúng tôi chỉ muốn mã.

Nhà cung cấp quyết định viết bài kiểm tra đơn vị bằng mọi giá (vì chất lượng) và chỉ không chia sẻ chúng với bạn (vì lợi thế cạnh tranh).

Bây giờ bạn cần thực hiện một số điều chỉnh chính cho phần mềm. Vì bạn sở hữu mã, bạn có thể tự làm hoặc thuê nó một cách cạnh tranh (không nhất thiết phải là nhà cung cấp ban đầu). Nhưng vì bạn đã không mua các bài kiểm tra đơn vị, nhà cung cấp ban đầu sẽ có thể thực hiện công việc có chất lượng tương đương với giá rẻ hơn cho bất kỳ đối thủ cạnh tranh nào.

Có rất nhiều dự án rất thành công mặc dù thực tế là họ không sử dụng các bài kiểm tra đơn vị. Chỉ cần nhìn vào kernel linux, đây là một dự án khổng lồ với độ phức tạp vượt xa những gì bạn sẽ tìm thấy trong bất kỳ dự án bình thường nào, và nó vẫn hoạt động. Vì vậy, nếu kết quả là phần mềm tốt, bạn không nên quan tâm làm thế nào họ đạt được nó.

Không, bạn không nhất thiết phải yêu cầu các đơn vị kiểm tra hoàn chỉnh và tự động. Điều quan trọng hơn là họ cung cấp cho bạn các tài liệu chiến lược thử nghiệm thích hợp. Chúng tôi đang làm tốt theo cách này.