Kiểm tra tự động ứng dụng dành cho máy tính để bàn:tổng quan về tính hiệu quả và các khuôn khổ

Giới thiệu

Bạn chắc chắn đã nghe nói về kiểm thử hồi quy và chấp nhận. Nhưng bạn có biết số tiền thực sự được chi cho kiểm tra nghiệm thu trong một dự án là bao nhiêu không?
Chúng tôi có thể nhanh chóng nhận được câu trả lời cho điều này với sự trợ giúp của hệ thống theo dõi thời gian như TMetric.
Trong dự án của chúng tôi, kiểm tra chấp nhận một ứng dụng máy tính để bàn với khoảng 100 tổ hợp đã mất hơn 2 tuần người. Các chuyên gia QA mới không biết rõ về ứng dụng đang gặp khó khăn lớn nhất. So với các chuyên gia QA có kinh nghiệm hơn, họ đã dành nhiều thời gian hơn cho mỗi trường hợp thử nghiệm.
Tuy nhiên, theo tôi, phần khó chịu nhất là điều này - nếu phát hiện bất kỳ lỗi nghiêm trọng nào trước khi phát hành, thử nghiệm chấp nhận phải được thực hiện lại sau khi các lỗi này được sửa.
Các bài kiểm tra đơn vị đã viết đã giúp một chút, nhưng chúng hầu như vẫn làm giảm thời gian dành cho kiểm tra hồi quy. Với điều này, khi lượng thử nghiệm thủ công đạt đến mức quan trọng, chúng tôi bắt đầu chuyển sang tự động hóa.

ROI

Trước khi viết các bài kiểm tra giao diện người dùng tự động, chúng tôi cần đánh giá mức độ sinh lời của các khoản đầu tư của chúng tôi. Chúng tôi đã làm điều này với sự trợ giúp của ROI (Return On Investment https://en.wikipedia.org/wiki/Return_on_investment)
Tính toán ROI của thử nghiệm giao diện người dùng cũng trở thành một nhiệm vụ thú vị với nhiều biến chưa biết:

ROI =Lợi nhuận / Chi phí
hoặc
ROI =(Lợi nhuận - Chi phí) / Chi phí

Ở giai đoạn này, chúng tôi cần một nguyên mẫu nhỏ có thể giúp chúng tôi ước tính tất cả các chi phí cần thiết. Nó cho thấy kết quả rất đặc biệt:thực hiện kiểm tra chấp nhận mất khoảng thời gian tương đương với việc tự động hóa quy trình này. Ban đầu, thông tin này có vẻ đáng nghi vấn, nhưng khi chúng tôi điều tra thêm, lý do đã trở nên rõ ràng:

Các chuyên gia QA mới có thể có hiểu biết hạn chế về các bước được mô tả trong các trường hợp thử nghiệm. Khi điều này xảy ra, một vài người sẽ tham gia vào quá trình thử nghiệm chấp nhận để giúp hiểu rõ tình hình hơn. Ở đây, chúng ta cũng nên nhớ câu hỏi về mức độ liên quan của thông tin mà chúng ta có về các yêu cầu và cài đặt môi trường.
Đôi khi, những người tham gia thử nghiệm chấp nhận dành thời gian tìm hiểu tài liệu kỹ thuật.
Bản thân ứng dụng tương tác với một nhóm dịch vụ cụ thể. Nếu một trong số chúng không có sẵn, các chuyên gia QA ít kinh nghiệm hơn sẽ dành thời gian mô tả các lỗi mà đến lượt họ, các nhà phát triển sẽ điều tra. Do đó, thời gian bị lãng phí vì dịch vụ cần thiết không chạy đúng cách sau khi mất điện / cập nhật phần cứng / khởi động lại máy tính.
Máy tính của người kiểm tra QA không mạnh lắm. Nếu không có SSD, bạn sẽ nhận thấy nó trong khi cài đặt. Ngoài ra, nếu ứng dụng đang hoạt động khi tải nặng, thì có thể tệp hoán trang chậm sẽ được sử dụng.
Thành thật mà nói, chúng tôi đã bị cuốn đi và quên rằng chúng tôi đang làm việc với tự động hóa. Nhân tiện, bạn đã đóng tab Youtube trong trình duyệt của mình chưa?

Bây giờ, hãy quay lại ROI. Để làm cho mọi thứ trở nên đơn giản, các phép tính đã được thực hiện theo thời gian. Hãy tính toán lợi nhuận là khoản tiết kiệm trong các thử nghiệm thủ công và khoảng thời gian chúng ta sẽ xem xét là một năm:

Lợi nhuận =(X - Y) * N =(60 - 1) * 8 =472 ngày

X - thời gian dành cho kiểm tra thủ công (60 ngày)
Y - thời gian dành cho việc thực hiện kiểm tra tự động (1 ngày)
N - lượng thời gian chấp nhận được thực hiện

Tiếp theo, chúng ta sẽ xem xét các chi phí:

Chi phí =A + B + C + D + E + F =0 + 10 + 5 + 50 + 7 + 8 =80

A - Chi phí của giấy phép công cụ tự động hóa. Trong trường hợp của chúng tôi, một công cụ miễn phí đã được sử dụng.
B - Đào tạo một chuyên gia QA (10 ngày)
C - Chuẩn bị cơ sở hạ tầng (5 ngày)
D - Phát triển các bài kiểm tra (50 ngày)
E - Chạy thử nghiệm và mô tả các lỗi được phát hiện trong quy trình (7 ngày)
F - Bảo trì thử nghiệm (8 ngày)

Tổng:

ROI =Lợi nhuận / Chi phí =472/80 =5,9

Tất nhiên, một số khía cạnh ở đây là ước tính. Để đánh giá các tính toán của riêng mình, chúng tôi đã dành một khoảng thời gian để điều tra các khả năng được cung cấp bởi các giải pháp trả phí và các máy tính ROI khác nhau. Với điều này, chúng tôi đã tính toán giá trị ROI trung bình là 2 hoặc 3, đây là một kết quả tuyệt vời.

Các khung hiện có

Sau khi xem xét các câu hỏi về tổ chức, hãy tập trung vào các câu hỏi thuộc loại kỹ thuật. Điều quan trọng nhất trong số họ là chọn một khuôn khổ để tự động thử nghiệm ứng dụng máy tính để bàn của chúng tôi. Chúng tôi có các yêu cầu sau dựa trên các tính năng của dự án của chúng tôi:

Các bài kiểm tra sẽ được phát triển và chạy trên các máy Windows
Khung phải được điều chỉnh để thử nghiệm các ứng dụng dành cho máy tính để bàn
Kiểm tra giao diện người dùng có thể được tích hợp vào quy trình CI. Chúng tôi đã sử dụng Jenkins, vì vậy nó phù hợp hơn ở đây
Khả năng viết các bài kiểm tra trong một IDE thân thiện với người dùng - nó phải có đánh dấu cú pháp, điều hướng tập lệnh kiểm tra và hoàn thành mã kiểu IntelliSense
Chi phí tối thiểu về đào tạo QA. Vì một số lý do nhất định, các chuyên gia QA của chúng tôi không muốn viết các bài kiểm tra trong Brainfuck
Ưu tiên cộng đồng trên Stack Overflow, MSDN, v.v.

TestComplete

Nền tảng này ban đầu hấp dẫn chúng tôi do sự trưởng thành của nó, mang lại hy vọng về các khía cạnh kỹ thuật.
Điều đầu tiên chúng tôi gặp phải là một IDE không ổn định và khá lỗi thời. Môi trường xử lý cú pháp làm nổi bật ít nhiều một cách tinh vi, nhưng có những vấn đề nghiêm trọng với điều hướng (Đi tới định nghĩa), tìm kiếm và tự động hoàn thành mã:chức năng này không hoạt động ở khoảng 60% thời gian. Máy ghi âm tích hợp và một tín hiệu tương tự Kiểm tra hoạt động tốt. Cuối cùng, IDE đã mang đến cho chúng ta một bất ngờ khó chịu khi nó bắt đầu chuyển các đối số cho ứng dụng. Điều này dự kiến sẽ gây ra lỗi trong hiệu suất của ứng dụng:

--no-sandbox
program files (x86)\smartbear\testcomplete12\x64\bin\Extensions\tcCrExtension\tcCEFHost.dll;application/x-testcomplete12-0-chrome-browser-agent

Ở giai đoạn này, chúng tôi đã đưa bộ phận hỗ trợ của TestComplete vào tình huống này để cố gắng tiết kiệm thời gian và đánh giá chất lượng của hỗ trợ kỹ thuật trước khi có khả năng mua giấy phép. Sau một vài lá thư được gửi đến bộ phận hỗ trợ kỹ thuật, chúng tôi đã nhận được câu trả lời - chúng tôi nên bỏ qua các đối số được chuyển cho ứng dụng. Kỳ lạ phải không? Điều tra thêm, chúng tôi phát hiện ra rằng những đối số này là bắt buộc để kiểm tra các ứng dụng sử dụng CEF. Trong lá thư tiếp theo, chúng tôi đã tuyên bố rằng chúng tôi sử dụng CEF và được các chuyên gia hỗ trợ yêu cầu không được bỏ qua các lập luận. Khi chúng tôi hỏi cách chính xác để sử dụng chúng, câu trả lời đã thay đổi thành “Bỏ qua các tranh luận”.
Rời khỏi cuộc trò chuyện với bộ phận hỗ trợ kỹ thuật, chúng tôi chuyển sang tài liệu của IDE (không có nhiều hy vọng). Nó có nhiều thông tin hơn, nhưng chúng tôi không tìm thấy gì liên quan đến trường hợp được đề cập. Ngoài ra, theo cùng tài liệu này, IDE lẽ ra phải hoạt động khác ngay từ đầu.
Người ta cho rằng các bài kiểm tra trong TestComplete sẽ được viết bằng VBScript.

Nếu bạn nhìn vào nó đủ lâu, bạn có thể nghe thấy điều này. Microsoft khuyên bạn nên chuyển đổi “điều kỳ diệu” này thành các tập lệnh PowerShell. Thay vào đó, JavaScript và Python có thể được sử dụng, điều này giúp ích cho tình hình.

Là một công cụ miễn phí, TestComplete sẽ có thể sử dụng được, nhưng trang web của họ có trang định giá và giá là cho mỗi người dùng. Do đó, đây là những gì chúng tôi sẽ nhận được sau khi mua công cụ:

IDE bạn muốn đóng
Khả năng tương thích với các tập lệnh từ năm 1996
Một máy ghi âm để chúng tôi không ghi mọi thứ theo cách thủ công
Một cuộc kiểm tra khác, nhưng có chuông và còi
2 loại câu trả lời hỗ trợ kỹ thuật
Tài liệu không đại diện cho thực tế

Thỏa thuận thương mại tồi tệ nhất từ trước đến nay, hãy tiếp tục.

Giao diện người dùng được mã hóa

Rút lui chiến thuật, tập hợp lại, và chúng tôi giải quyết vấn đề. Mặt khác, chúng tôi đã học cách sử dụng Visual Studio làm IDE. Mặt khác, cách tiếp cận của chúng tôi dựa trên các thành phần Giao diện người dùng DevExpress mà chúng tôi đang sử dụng. Do đó, chúng tôi đã tìm thấy một số thông tin thú vị về khung giao diện người dùng được mã hóa được sử dụng chính thức trong DevExpress để tự động thử nghiệm giao diện người dùng. Khung công tác này được tích hợp vào quá trình thử nghiệm nội bộ đến mức thậm chí còn có phần mở rộng Visual Studio cho nó.
Có một cộng đồng rộng lớn, Microsoft đã quảng cáo công cụ này trên trang web của họ và sản phẩm này cũng đã được đề cập trên “Microsoft Kênh Visual Studio ”. Tóm lại là một câu chuyện ngắn, mọi thứ đều có vẻ đầy hứa hẹn và chúng tôi bắt đầu chuẩn bị khuôn khổ.
Yêu cầu đầu tiên mà chúng tôi gặp phải là Visual Studio Enterprise. Hơn nữa, phiên bản Visual Studio này không chỉ cần thiết để viết các bài kiểm tra mà còn để chạy chúng. Điều này có nghĩa là việc khởi chạy chậm nhất sẽ được thực hiện trong trường hợp với CI cũng phải là một phần của phiên bản Enterprise.
Tất cả các công cụ giao diện người dùng được mã hóa cần thiết có thể được cài đặt bằng cách bật các hộp kiểm tương ứng khi VS được cài đặt hoặc sửa đổi.

Cách tiếp cận để viết các bài kiểm tra khá dễ chịu:các lệnh được tích hợp vào shell cho phép nhanh chóng khởi chạy một bộ ghi tạo ra một bài kiểm tra đơn vị và một lớp “bản đồ” mô tả giao diện người dùng. Các công cụ bổ sung được tích hợp vào VS cung cấp khả năng tạo các lớp thử nghiệm riêng biệt mà không cần gọi mã.
Điểm đặc biệt duy nhất mà chúng tôi nhận thấy là một lớp một phần có mô tả điều khiển và được chia thành hai phần. Cùng với nhiều thứ khác, nó được mô tả trong tài liệu. Tài liệu này là đủ cho một quy trình làm việc thoải mái:các ví dụ mã và ảnh chụp màn hình giúp tất cả thông tin kỹ thuật có thể truy cập dễ dàng và dễ hiểu. Nói một cách đơn giản, khi trình ghi mô tả giao diện người dùng, một tệp “Designer.cs” sẽ được tạo. Tệp này chịu trách nhiệm sử dụng lại mã mô tả giao diện người dùng. Mọi thứ mà trình ghi không thể xử lý phải được ghi theo cách thủ công và lưu ở đâu đó bên ngoài phần được tạo tự động của lớp. Điều này rất giống với các lớp từng phần được viết bởi VS deigners khi tạo điều khiển. Mức độ ưu tiên của các hoạt động được thực hiện trên các điều khiển và kiểm tra trạng thái của chúng được mô tả trong một phương pháp mà bộ ghi bổ sung một cách hữu ích thuộc tính TestMethod tiêu chuẩn.
Các đám mây bắt đầu tập hợp trên khuôn khổ khi chúng tôi bắt đầu xem xét những thứ mà bộ ghi tạo ra . Trước hết, nó che khuất một số vấn đề của ứng dụng:một số thuộc tính Name của điều khiển không được chỉ định và người ghi cho rằng đây là trường hợp vi phạm quy tắc vô lý có thể chấp nhận được và đã tìm kiếm các điều khiển thông qua văn bản. Ngoài ra, nó xử lý các điều khiển phức tạp rất kém hiệu quả. Ví dụ:các nút TreeView được tìm kiếm theo chỉ mục nút khiến lớp “bản đồ” đã tạo không thể sử dụng được trong trường hợp mở rộng giao diện. Và giá trị của máy ghi âm đã giảm đáng kể trong mắt chúng tôi - điểm tự động tạo mã là gì nếu bạn cần kiểm tra nó sau đó?
Chúng tôi có thể làm hòa với tất cả những điều này và tìm ra giải pháp đáng khen ngợi, nhưng đột nhiên, sấm sét ập đến:Microsoft nói rằng công nghệ này hiện đã lỗi thời. Với điều này, VS 2019 đã trở thành phiên bản Visual Studio cuối cùng hỗ trợ giao diện người dùng mã hóa. Khả năng phụ thuộc vào VS 2019 ngay bây giờ và trong vài năm trước không thực sự có vẻ đáng sợ, nhưng dự án của chúng tôi khá lớn, vì vậy khó khăn có thể bắt đầu từ đâu đó (ví dụ như năm 2025).
Hãy tóm tắt lại. Với giao diện người dùng được mã hóa, chúng tôi sẽ có:

IDE trả phí mạnh mẽ
Tất cả cơ sở hạ tầng đã được tạo cho các bài kiểm tra:cả về phía IDE và CI của chúng tôi
Khả năng yêu cầu bất kỳ nhà phát triển nào từ dự án của chúng tôi trợ giúp vì chúng tôi đang viết các bài kiểm tra bằng C # trong cùng một IDE
Một lượng lớn tài liệu chất lượng tốt
Một số chuyên gia QA buồn đã đặt mã của họ vào phần được tạo tự động của lớp và sau đó làm mất mã đó trong quá trình tự động tạo
Nhiều mã được tạo hoạt động theo kiểu này và bạn cần phải xem xét nghiêm ngặt
Một cách tiếp cận cực kỳ minh bạch đối với CI:bạn có thể viết mã để khởi chạy các thử nghiệm một cách dễ dàng nhất khi nhắm mắt lại
Một gã khổng lồ tự động hóa màu đỏ đang chết dần chết mòn, không ngừng phát triển sau các thử nghiệm mới và nguy hiểm gần như biến thành một sao lùn trắng đang tàn lụi được thể hiện bằng một cỗ máy hoàn toàn biệt lập với phần mềm lỗi thời không thể phục hồi hoặc trở thành một vụ nổ siêu tân tinh khi dự án phát nổ dưới áp lực của các bản cập nhật mới.

Mọi thứ đều có vẻ tốt ngoại trừ điểm cuối cùng. Đây là lý do tại sao chúng tôi cần tiếp tục tìm kiếm.

TestStack.White

Chúng tôi đang làm việc trên các thử nghiệm tạo mẫu với sự trợ giúp của White song song với việc điều tra chức năng của giao diện người dùng được mã hóa.
Bản thân White là một phần mềm bao quanh các thư viện 'Microsoft.Automation' trông rất hứa hẹn và White cũng tương tự như Coded Giao diện người dùng. Tuy nhiên, khi xem xét kỹ hơn, chúng tôi thấy nó khắc khổ hơn nhiều, và bạn có thể nhận thấy nó ở khắp mọi nơi - từ thực tế là không có máy ghi âm cho đến cấu trúc bài kiểm tra thực tế. Ví dụ:chạy ứng dụng, tìm kiếm một cửa sổ và nhấn nút “Thực thi” sẽ trông giống như sau:

var appPath = @"C:\Program files\UiAutomatedTestApplication\TestApplication.exe";
var app = TestStack.White.Application.Launch(appPath);

var windowSearchCriteria = SearchCriteria.ByAutomationId("MainForm");
var window = app.GetWindow(windowSearchCriteria, InitializeOption.NoCache);

var execute = window.GetElement(SearchCriteria.ByText("Execute"));
var invokePattern = (InvokePattern)execute.GetCurrentPattern(InvokePattern.Pattern);
invokePattern.Invoke();

app.WaitWhileBusy();

Ngay cả khi không có phàn nàn nào khi chạy ứng dụng, thì sự cần thiết phải làm việc với lớp InvokePattern là rất đáng nghi ngờ. Lớp InitializeOption trông cũng lạ vì nó có quyền truy cập vào thành viên tĩnh WithCache, nhưng được cho là được sử dụng nội bộ nghiêm ngặt:

public class InitializeOption {
//
// Summary:
//     This option should not be used as this is only for internal white purposes
public static InitializeOption WithCache { get; }
public static InitializeOption NoCache { get; }
public virtual bool Cached { get; }
public virtual string Identifier { get; }
public virtual bool NoIdentification { get; }

//
// Summary:
//     Specify the unique identification for your window. White remembers the location
//     of UIItems inside a window as you find them. Next time when items inside the
//     same window is found they are located first based on position which is faster.
//
// Parameters:
//   identifier:
public virtual InitializeOption AndIdentifiedBy(string identifier);
public virtual void NonCached();
public override string ToString();
}

Những quyết định kỳ lạ như thế này có ở khắp mọi nơi và khuôn khổ trở nên quá trừu tượng đối với QA.

Tài liệu có chất lượng tốt và đã để lại ấn tượng chung tốt. Mã nguồn của dự án được lưu trữ tại github, nhưng cam kết mới nhất được ghi vào ngày 8 tháng 1 năm 2016.
Tổng hợp thông tin về White, chúng tôi sẽ có:

Tài liệu phong phú
Quyền truy cập vào mã nguồn
Một cộng đồng nhỏ
Sự cần thiết phải giải thích cho tất cả các chuyên gia QA rằng hành vi của kiểm soát được thực hiện thông qua lớp Mẫu
Một kho lưu trữ cũ mà từ đó chúng tôi chắc chắn sẽ cần phân tách

Phần khó chịu nhất là cần phải phát triển khuôn khổ của riêng chúng tôi, điều mà chúng tôi muốn tránh. Vì vậy, chúng tôi phải tiếp tục.

Appium

Trước đây, chúng tôi đã gặp Appium trong tìm kiếm của mình, nhưng chỉ bắt đầu xem xét nó một cách nghiêm túc sau khi Microsoft ngừng sử dụng Giao diện người dùng mã hóa.
Thoạt nhìn, thử nghiệm với sự trợ giúp của Appium trông giống như một máy đánh bạc có ba cuộn. Đầu tiên hiển thị ngôn ngữ có API cho phép tương tác với trình điều khiển. Điều này cung cấp khả năng viết các bài kiểm tra bằng bất kỳ ngôn ngữ quen thuộc nào:Python, C #, Java, v.v. Cuộn thứ hai hiển thị ứng dụng trình điều khiển đóng vai trò là lớp trung gian giữa các bài kiểm tra và sản phẩm mà chúng tôi đang kiểm tra. Như được mô tả trong tài liệu, tương tác với các bài kiểm tra được thực hiện bằng Giao thức dây JSON - đây là điều thực sự mang lại cho chúng tôi khả năng viết bài kiểm tra bằng bất kỳ ngôn ngữ nào. Và cuộn thứ ba hiển thị đối tượng mà chúng tôi đang thử nghiệm. Không thực sự quan trọng nếu đó là trang web, ứng dụng dành cho thiết bị di động hay ứng dụng dành cho máy tính để bàn miễn là trình điều khiển tương ứng đang chạy. Như bạn có thể thấy, các thành phần có thể hoán đổi cho nhau một cách trang nhã.
Việc ước tính mức độ liên quan của gói được đáp ứng - trên trang Github, chúng ta có thể thấy rằng kho lưu trữ có các cam kết mới. Trong khi kiểm tra kho lưu trữ WinAppDriver, chúng tôi biết rằng thậm chí còn có một trình ghi trong đó.
Chúng tôi bắt đầu nhận thấy một số vấn đề trong khi viết nguyên mẫu. Ví dụ:vì khuôn khổ quá đa mục đích, WindowsElement chịu trách nhiệm về điều khiển màn hình có phương thức FindElementByCssSelector sẽ ném ra ngoại lệ sau khi thực thi:“Lỗi không mong muốn. Lệnh chưa hoàn thành:chiến lược định vị bộ chọn css không được hỗ trợ ”. Trong bài viết tiếp theo, chúng tôi sẽ nói chi tiết hơn về các vấn đề chúng tôi gặp phải khi làm việc với khung này, nhưng bây giờ tôi muốn nói rằng chúng tôi đã giải quyết được tất cả.

Tóm lại, đây là những gì chúng tôi sẽ có khi sử dụng Appium:

Khả năng kiểm tra chức năng ứng dụng yêu cầu tương tác với trình duyệt (mở trang phản hồi, kích hoạt trực tuyến, kiểm tra việc gửi email) trong phạm vi của một cơ sở hạ tầng và một lần kiểm tra
Khả năng làm việc với bất kỳ phiên bản nào của Visual Studio
Khả năng kiểm tra ứng dụng dành cho máy tính để bàn sử dụng trình duyệt để hiển thị giao diện người dùng. Một ví dụ điển hình về điều này là Azure Data Studio
Tất cả những lợi ích mà chúng tôi nhận được với Giao diện người dùng được mã hóa
Một khuôn khổ miễn phí mà Microsoft khuyên bạn nên sử dụng
Cơ sở hạ tầng quen thuộc với các chuyên gia QA đã làm việc với Selenium
Kho lưu trữ được cập nhật với các cam kết mới
Tuy nhiên, một cộng đồng rất lớn nhưng không lớn bằng cộng đồng của Giao diện người dùng được mã hóa
Máy ghi âm có chức năng hạn chế
Sự cần thiết phải chạy ứng dụng trình điều khiển để thử nghiệm. Không thuận tiện lắm, nhưng nó có chức năng ghi nhật ký riêng
Rất nhiều cơ hội để tự bắn vào chân mình do sự kế thừa đáng tiếc của WindowsElement từ AppiumWebElement

Xem qua tất cả các điểm với các yêu cầu cho khuôn khổ và so sánh tất cả các vấn đề được tìm thấy trong mỗi khuôn khổ đó, cuối cùng chúng tôi đã chọn Appium.

Kết luận

Thật thú vị khi làm việc với tất cả các khuôn khổ này vì mỗi khuôn khổ trong số chúng đều dựa trên một triết lý duy nhất về cách tiếp cận kiểm thử tự động. Một phần trong số họ chỉ bắt đầu con đường của mình trong khi những người khác đang đạt đến nhật thực hoặc đã biến mất. Bạn có thể tránh bị lạc trong nhiều giải pháp có sẵn bằng cách tạo danh sách các yêu cầu cụ thể cho công cụ và có một nhóm chịu trách nhiệm với sự tương tác được thiết lập tốt giữa các thành viên của nó. Và đừng quên rằng các thử nghiệm trong tương lai cũng giống như một dự án như mã thông thường, với tồn đọng, bảng, CI, tái cấu trúc và mọi thứ khác.