Tại sao bạn cần Shift-left với thử nghiệm trên thiết bị di động

Tôi cảm thấy như luôn có mối quan hệ yêu-ghét với khái niệm thử nghiệm. Không còn nghi ngờ gì nữa, lợi ích của việc thử nghiệm bất cứ thứ gì bạn đang xây dựng sẽ giúp tránh việc khách hàng báo cáo những khám phá tương tự đó. Đó là phần tình yêu của mối quan hệ.

Phần đáng ghét là khi các mốc thời gian của dự án khiến việc kiểm tra trở thành mức độ ưu tiên thấp hơn… thường đến mức nó trở thành một mục trong danh sách mong muốn tồn đọng mà hiếm khi xuất hiện trong một lần chạy nước rút hiện tại. Điều này gần như đảm bảo rằng khách hàng sẽ liên hệ với bạn với những kết quả không mong đợi.

Khi vòng đời phát triển phần mềm (SDLC) đã hoàn thiện, việc thử nghiệm trở nên dễ dàng hơn, cho phép các nhà phát triển tạo các thử nghiệm đơn vị bao quát đầy đủ khía cạnh được xác thực. Việc sử dụng ChatGPT hoặc GitHub Co-Pilot đã phát triển đến mức các bài kiểm tra đơn vị như vậy có thể được tạo tự động. Các giải pháp công cụ tích hợp liên tục (CI) đã được cải tiến để thực thi mức độ bao phủ mã cao trước khi có thể hợp nhất bất kỳ yêu cầu kéo (PR) nào. Làm như vậy cho phép các nhóm chuyển sang trái trong quá trình phát triển của mình - buộc các vấn đề phải được giải quyết trong giai đoạn phát triển và cắt giảm chi phí cho các tính năng trong quá trình thực hiện.

Cách tiếp cận này có hiệu quả rất tốt đối với các API và khung web truyền thống, nhưng việc kiểm tra ứng dụng di động thường yêu cầu các nhóm thực hiện kiểm tra thủ công—thực thi từ danh sách các bước đã được công bố trên nhiều loại thiết bị khác nhau nhất có thể được quản lý.

Tôi muốn xem liệu tôi có thể xác định cách mà việc phát triển và thử nghiệm thiết bị di động có thể sử dụng khái niệm dịch chuyển sang trái hay không.

Những gì còn thiếu trong thử nghiệm trên thiết bị di động

Ở cấp độ cao, không gian ứng dụng di động phải có khả năng kiểm tra các tính năng và chức năng giống như cách các API và khung web đang thử nghiệm hiện nay. Điều này có nghĩa là bạn không cần phải thực hiện thử nghiệm theo cách thủ công bằng cách sử dụng kho thiết bị vật lý hoặc trình mô phỏng.

Trạng thái thử nghiệm di động lý tưởng này sẽ được điều khiển bởi giao diện người dùng để tránh viết các bài kiểm tra khó hiểu tập trung vào hoạt động của người dùng. Cách tiếp cận này có thể mở rộng công cụ này tới người tiêu dùng nội bộ hoặc chủ sở hữu sản phẩm muốn xác thực tầm nhìn của họ thành hiện thực.

Cũng giống như các thử nghiệm tích hợp hoặc đơn vị truyền thống, khả năng giới thiệu các mô-đun có thể xác thực các khía cạnh nhỏ của ứng dụng di động và được sử dụng làm khối xây dựng cho các quy trình lớn hơn. Khi làm điều này, các nhóm sẽ có thể giữ được “khô” (không lặp lại chính mình) và tránh làm việc trùng lặp.

Cuối cùng, những thử nghiệm này sẽ cần có khả năng trở thành một phần của quy trình CI/CD, mặc dù được điều khiển bởi giao diện người dùng đồ họa.

Ở trạng thái lý tưởng này, các kỹ sư phần mềm di động có thể chuyển sang trái một cách hiệu quả để phát triển và thử nghiệm thiết bị di động của họ.

Dù sao thì “Shift Left” là gì?

Bạn nên làm rõ ý tôi khi nói “dịch chuyển sang trái” để thử nghiệm trên thiết bị di động.

Wikipedia định nghĩa sự dịch chuyển sang trái để kiểm tra như được ghi chú bên dưới:

“Thử nghiệm dịch chuyển sang trái là một cách tiếp cận để thử nghiệm phần mềm và thử nghiệm hệ thống, trong đó thử nghiệm được thực hiện sớm hơn trong vòng đời (tức là di chuyển sang trái trong dòng thời gian của dự án). Đó là nửa đầu của câu châm ngôn 'kiểm tra sớm và thường xuyên'. Nó được đặt ra bởi Larry Smith vào năm 2001. ”

Đơn giản chỉ cần thực hiện shift left cho phép xác định các khiếm khuyết trong giai đoạn phát triển. Điều này rất quan trọng vì vấn đề có thể được giải quyết khi tính năng này vẫn còn mới trong tâm trí của (các) kỹ sư tập trung vào nguồn.

Dưới đây là một số lợi ích của việc áp dụng ca trái:

• Giảm chi phí để cung cấp các tính năng bằng cách tìm và khắc phục sự cố trong thời gian phát triển.
• Hiệu quả cao hơn do giảm được thời gian cần thiết để xem lại các giải pháp sau khi bàn giao.
• Chất lượng cao hơn do buộc phải bao quát và xác nhận đầy đủ trong giai đoạn phát triển.

Cuối cùng, khái niệm chuyển sang trái sẽ dẫn đến lợi thế cạnh tranh khi các giải pháp đến tay người tiêu dùng đã được xác thực và hoạt động như mong đợi.

Giới thiệu về Tosca

Năm ngoái, tôi đã khám phá cách sử dụng Tricentis Testim trong bài viết “ Cải thiện chất lượng ứng dụng đối mặt với khách hàng bằng Tricentis Testim ” của mình. Tôi rất ấn tượng về việc xác thực giải pháp Magic 8 Ball của mình dễ dàng như thế nào bằng cách sử dụng API RESTful dựa trên GO và ứng dụng khách dựa trên web Vue.js. Tôi muốn xem liệu Tricentis có giải pháp cho phép các nhóm chuyển sang trái để thử nghiệm trên thiết bị di động hay không.

Hóa ra họ có một sản phẩm tên là Tosca .

Sản phẩm Tosca cung cấp khả năng tạo thử nghiệm không cần mã hóa, cho phép tạo ra các mô-đun nhỏ có thể tái sử dụng và tự động hóa. Các mô-đun này có thể được coi là các khối Lego có thể được kết nối khi cần thiết nhờ vào hợp đồng tiêu chuẩn hóa giữa chúng. Tosca tiến một bước gần hơn đến vòng đời phát triển truyền thống hơn bằng cách cung cấp khả năng tận dụng AI để giúp tạo các thử nghiệm di động cho các tính năng của bạn.

Tosca cũng tận dụng sức mạnh của dự án Appium nguồn mở mà không cần phải học hỏi nhiều thông qua Tricentis Mobile Agent. Điều này cho phép tất cả sức mạnh được cung cấp trong bài viết trước của tôi được đưa vào hành trình chuyển sang trái với việc phát triển thiết bị di động.

Do đó, Tosca cho phép thử nghiệm các ứng dụng di động gốc, ứng dụng lai và web trên các thiết bị iPhone, Android, điện thoại di động và máy tính bảng thực mà không cần bảo trì và sở hữu các thiết bị này.

Cũng giống như sản phẩm Testim, giải pháp Tosca cung cấp khả năng thực hiện các thử nghiệm như một phần của quy trình CI/CD, cho phép thực thi việc áp dụng dịch chuyển trái.

Bạn có thể sử dụng Tosca để kiểm tra trực tiếp trên điện thoại iOS hoặc Android, cũng như thông qua trình mô phỏng hoặc trình mô phỏng có sẵn thông qua IDE như Android Studio. Sử dụng Tosca, bạn có thể quét ứng dụng của mình và yêu cầu nó tạo các trường hợp thử nghiệm:

Khi Tosca đã tạo các trường hợp thử nghiệm, bạn cũng có thể tạo các trường hợp thử nghiệm của riêng mình.

Một trong những ưu điểm của Tosca là nó cho phép bạn viết bài kiểm tra mà không cần phải viết mã. Điều này được thực hiện thông qua thư viện mô-đun có thể mô phỏng hầu hết mọi hành động, bao gồm mở trình duyệt hoặc điền vào biểu mẫu.

Trong ví dụ này, chúng tôi đã sử dụng ba mô-đun cho trường hợp thử nghiệm di động Tosca của mình. Chúng tôi kiểm tra:

1. Mở trình duyệt và nhấn điểm cuối của ứng dụng của chúng tôi
2. Lựa chọn một loại phương tiện cụ thể
3. Điền vào biểu mẫu về chiếc xe cụ thể đó

Lưu ý rằng tất cả những gì chúng ta phải làm là cung cấp thông tin đầu vào mẫu (trong ảnh chụp màn hình, chúng ta đang làm như vậy cho bước 3 được đánh dấu ở trên). Sau khi quá trình kiểm tra hoàn tất, bạn sẽ nhận được báo cáo chẩn đoán về Tosca.

Chuyển sang trái để kiểm tra thiết bị di động

Bằng cách tận dụng một sản phẩm như Tosca, các kỹ sư phần mềm tập trung vào phát triển thiết bị di động có thể giúp nhóm của họ có lợi thế cạnh tranh bằng cách sử dụng những thứ còn lại để thử nghiệm trên thiết bị di động:

• Các tính năng dành cho thiết bị di động được xác thực trong giai đoạn phát triển, tương tự như các dịch vụ và khung web.
• Các thử nghiệm được điều khiển bởi một giao diện người dùng có thể mở rộng tới người tiêu dùng nội bộ và chủ sở hữu sản phẩm để giúp củng cố tầm nhìn của họ.
• Bộ thử nghiệm có thể được xây dựng từ một tập hợp các mô-đun “khô” được cấu trúc để bao gồm đầy đủ các tính năng và chức năng mới.
• Các thử nghiệm có thể được thực hiện dựa trên kho thiết bị di động đầy đủ mà không cần sở hữu và bảo trì các thiết bị đó.
• Trước khi giới thiệu các tính năng mới cho nhánh mã chính, PR liên quan sẽ gọi các thử nghiệm do giao diện người dùng tạo theo cách tương tự như cách thực hiện các thử nghiệm đơn vị hoặc tích hợp trong quy trình CI/CD của khung web hoặc API.

Phần kết luận

Độc giả của tôi có thể nhớ lại rằng tôi đã tập trung vào tuyên bố sứ mệnh sau đây mà tôi cảm thấy có thể áp dụng cho bất kỳ chuyên gia CNTT nào:

“Hãy tập trung thời gian vào việc cung cấp các tính năng/chức năng giúp nâng cao giá trị tài sản trí tuệ của bạn. Tận dụng các khuôn khổ, sản phẩm và dịch vụ cho mọi thứ khác.” - J. Vester

Để đạt được năng suất cao nhất, các kỹ sư phần mềm tập trung vào phát triển thiết bị di động cần áp dụng shift left để thử nghiệm trên thiết bị di động . Tuy nhiên, lựa chọn lý tưởng nên xem xét mọi đường cong học tập liên quan và khả năng hỗ trợ khi tìm kiếm giải pháp.

Sản phẩm Tosca tuân thủ tuyên bố sứ mệnh cá nhân của tôi bằng cách cho phép các nhóm đạt đến trạng thái dịch chuyển sang trái mà không cần mã nguồn bổ sung để hỗ trợ và duy trì. Sản phẩm này cũng cho phép những người không phải là kỹ sư tham gia vào quá trình phát triển thử nghiệm, mang lại lợi thế cho các nhóm trong việc đảm bảo thiết kế phù hợp với mong đợi.

Cá nhân tôi đã áp dụng phương pháp dịch chuyển sang trái trong vài năm và đánh giá cao trải nghiệm mỗi khi tránh được lỗi chỉ bằng cách làm theo quy trình. Đã đến lúc phát triển thiết bị di động sử dụng khái niệm dịch chuyển sang trái.

Chúc bạn có một ngày thật tuyệt vời!