7 sai lầm chết người cần tránh trong quá trình kiểm thử ứng dụng di động

Linh Le

 

Chuyện kiểm thử ứng dụng di động so với kiểm thử web rất khác nhau. Người dùng ứng dụng di động muốn nhiều thứ hơn là những tính năng thông thường, chẳng hạn như thiết kế ưa nhìn, trải nghiệm người dùng (UX) đơn giản, và tốc độ nhanh. Chính vì thị trường đầy tính cạnh tranh mà người dùng có thể tìm được những ứng dụng thay thế tốt hơn nếu họ không hài lòng với ứng dụng mình đang dùng. Việc kiểm thử phần mềm nắm giữ một phần quan trọng trong việc xây dựng một ứng dụng chất lượng đảm bảo yêu cầu. Có khá nhiều khía cạnh mà các tester cũng như lập trình viên cần phải ghi nhớ khi thực hiện kiểm thử.

Dưới đây là 7 sai lầm mà mọi tester cần tránh khi kiểm thử các ứng dụng di động.

1. Kiểm thử khi không nắm rõ mục đích và không học hỏi

Sai lầm đầu tiên mà các tester có xu hướng phạm phải đó chính là tiến hành kiểm thử mà không nắm nguyên lý của các mô hình MVP, MVC và MVVM đối với các ứng dụng di động. Để việc kiểm thử được tốt hơn, team QA nên làm việc với các lập trình viên ngay khi bắt đầu dự án và học hỏi công nghệ đang được áp dụng trong ứng dụng di động đó. Bạn không thể nào học hỏi nếu bạn không hiểu mục đích của ứng dụng. Vì thế, trước khi bắt đầu kiểm, cần biết rõ mục đích của bạn là gì.

Đây là thách thức cần được xem xét đầu tiên vì nếu không nắm được mục đích, bạn sẽ có thể tạo ra những mục test không thể đánh giá chính xác được các yêu cầu của ứng dụng. Các lập trình viên và tester cần phải thiết lập những mục tiêu thương mại trước khi bắt đầu dự án, chúng sẽ đem lại ý tưởng rõ ràng cho quy trình phát triển và kiểm thử cũng như cách thiết kế các quy trình trong tương lai. Điều này không những tiết kiệm thời gian mà còn giúp giảm sức lực và mang lại phạm vi kiểm thử tốt hơn.

2. Kiểm thử mọi thứ, không có ưu tiên

Nhiều tester thường hay dùng cách này, họ kiểm thử tất cả các kịch bản có thể xảy ra mà không xếp hạng ưu tiên cho chúng. Việc làm này thường gây nên chậm trễ trong quy trình kiểm thử vì có thể có một số kịch bản tương tự nhau. Để sắp xếp hiệu quả quy trình kiểm thử, bạn nên ưu tiên cho những kịch bản và nội dung kiểm thử theo đặc tả yêu cầu và mức độ quan trọng của chúng.

Khi kiểm thử hồi quy, việc ưu tiên cho các test case trở nên rất quan trọng. Kiểm thử hồi quy được dùng để đảm bảo rằng các thay đổi hay những mục mới thêm vào chương trình không làm hỏng bất kì tính năng nào trước đó. Vì vậy khi bạn tạo bộ kiểm thử hồi quy, hãy đảm bảo rằng bạn đưa vào đó tất cả các test case bao quát hết các tính năng chính của ứng dụng.

Thông thường, kiểm thử hồi quy chứa hàng ngàn test case và phải mất một khoảng thời gian vô cùng lớn để chạy chúng. Nếu bạn không đủ thời gian để chạy hết các test case để kiểm tra hết các tính năng của ứng dụng thì sao? Lúc này bạn cần chạy các test case dựa trên mức độ ưu tiên.

Blocker

Những kiểu test case này rất quan trọng và chúng bao quát những tính năng chính của ứng dụng. Các test case này yêu cầu mức độ ưu tiên cao nhất vì chúng có liên quan tới những tính năng nền tảng của ứng dụng mà dựa vào đó các tính năng khác mới có thể hoạt động. Nếu bất cứ chức năng nào ngưng hoạt động thì nó sẽ ngăn cản những bước kiểm thử tiếp theo và vấn đề phải được giải quyết ngay. Ví dụ, nếu một ứng dụng không thể mở được thì bạn không thể tiếp tục test.

Critical

Những test case này liên quan tới các tính năng kết nối trực tiếp với người dùng và lỗi của các tính năng này có thể khiến người dùng gỡ ứng dụng. Vì vậy các test case này cần phải được thực hiện ngay sau khi test xong các “blocker”.

Major

Những test case này gắn liền với những tính năng đặc thù của ứng dụng, thứ tạo nên khác biệt với các đối thủ cạnh tranh. Thiếu sót các test case này không ảnh hưởng tới việc hoạt động chung của ứng dụng nhưng nếu ứng dụng thiếu chức năng thì nó sẽ không được người dùng đánh giá cao nữa.

Minor

Những test case này chứa các thay thế UI và những cải tiến nhỏ với tính năng trước đó. Chúng không ảnh hưởng tới việc sử dụng phần mềm và có thể bỏ qua nếu thời gian gấp rút.

Bạn có thể phân loại các test case của mình bằng việc kiểm tra mức độ ảnh hưởng của chúng tới tính năng. Thêm nữa, cái giá cho việc sửa lỗi blocker và critical cao hơn và đó chính là một trong những lí do để kiểm tra chúng đầu tiên. Bạn có thể phân chia test case và ưu tiên chúng bằng cách xem qua các đặc tả yêu cầu phần mềm và tài liệu yêu cầu chức năng. Hiểu rõ chúng có thể giúp việc phân loại dễ dàng hơn.

3. Kiểm thử Web và kiểm thử di động

Trong nhiều công ty, team QA làm việc với cả các ứng dụng di động lẫn ứng dụng web. Ngoài một số ý tưởng cốt lõi của công việc kiểm thử thì việc kiểm thử ứng dụng di động yêu cầu phương pháp khác. Mỗi người phải hiểu rằng ứng dụng di động khác hoàn toàn so với ứng dụng web. Người dùng di động luôn di chuyển chứ không ngồi một chỗ như khi dùng máy tính. Hơn nữa, ứng dụng web được xây dựng trên màn hình lớn hơn trong khi ứng dụng di động được tối ưu hóa cho màn hình nhỏ. Ngoài ra còn có nhiều yếu tố khác bạn cần cân nhắc nếu bạn chuyển từ kiểm thử web sang di động.

Giới hạn lưu lượng và RAM

Hầu hết các thiết bị di động có thể có dung lượng RAM 4 GB và bộ nhớ SSD 64 GB. Giới hạn dung lượng này tạo nên một số hạn chế lên khả năng lưu trữ và RAM trong các thao tác kiểm thử.

Các kiểu tương tác khác nhau với người dùng khác nhau

Với những ứng dụng máy tính hay laptop, phương thức nhập (bàn phím, chuột) được giữ ổn định và vẫn là chuẩn mực khi bạn lướt web hoặc chơi game. Ngược lại, ứng dụng di động có thể được vận hành dưới các thao tác chạm khác nhau như quét, kéo, thu-phóng bằng tay (pinching)… Tương tự, có các trợ lý giọng nói như Siri hay Google Now. Những cải tiến đặc thù của thiết bị như mô tả bằng tay trên một số tai nghe của Samsung hay bộ audio mới của iPhone đã làm tăng tính phức tạp cho việc vận hành di động.

Các loại ứng dụng khác biệt

Ứng dụng điện thoại không đơn giản. Chúng có thể là ứng dụng web, native hoặc ứng dụng lai (hybrid).

Các gián đoạn

Cần phải kiểm thử xem ứng dụng hồi đáp lại như thế nào khi nó bị gián đoạn bởi các thông báo đẩy, SMS hoặc cuộc gọi đến lúc đang hoạt động. Ứng dụng không được ngưng hoạt động và phải khôi phục lại trạng thái sau khi bị gián đoạn.

4. Phạm vi kiểm thử thiết bị còn thiếu sót

Khi thị trường di động ngày càng phân hóa mạnh hơn, thì việc kiểm thử nhiều loại phần cứng và phần mềm khác nhau trở thành một trong những thách thức hàng đầu. Chính điều này khiến các tester dễ bỏ sót nhiều thiết bị hiện có trên thị trường cũng như những thiết bị sắp ra mắt.

Dù cho đây có là thách thức thì chuyện quan trọng vẫn là phải tiến hành kiểm thử càng nhiều thiết bị càng tốt, bao gồm iPhone, iPad và các thiết bị Android. Nhưng vẫn phải tập trung vào những thiết bị có nhiều người dùng nhất mà bạn nhắm tới.

Để nâng cao lượng thiết bị được kiểm thử, bạn có thể dùng nền tảng kiểm thử dựa trên cloud, ví dụ như dịch vụ AWS Device Farm. Những nền tảng như thế này sẽ loại bỏ rắc rối trong kiểm thử thủ công thường gặp trong các thiết bị Android và iOS với các phiên bản OS (hệ điều hành) khác nhau. Dùng dịch vụ kiểm thử dựa trên cloud, bạn có thể kiểm thử bất kì thiết bị nào và chạy các test case thủ công lẫn tự động trên ứng dụng web dành cho điện thoại, native hoặc hybrid của mình.

5. Không ưu tiên kiểm UI/UX ngay từ đầu

Một trong những sai lầm lớn nhất có thể xảy ra đó là không cân nhắc tới việc kiểm thử tính khả dụng ngay từ đầu trong quy trình kiểm thử. UI/UX là cái nhìn đầu tiên mà ứng dụng mang tới cho người dùng nên nó cần được kiểm tra kĩ càng. Chính vì thế, kiểm thử tính khả dụng cần được thực hiện ngay từ ban đầu ở giai đoạn hoàn thiện wireframe nhằm kiểm tra xem tất cả các mục có nằm đúng vị trí chưa, việc giao tiếp với người dùng và phản hồi của hệ thống có đúng hay không.

Bạn có thể sử dụng các công cụ prototype (xây dựng bản mẫu) để đơn giản hóa và tăng tốc quá trình kiểm thử UI. Những công cụ này cho phép các lập trình viên viết code theo thiết kế. Mục tiêu chính của các prototype là kiểm tra xem các giải pháp đã phù hợp và chính xác hay chưa trước khi chúng được giao cho các lập trình viên.

6. Bỏ qua kiểm thử mạng

Các ứng dụng di động hoạt động với chế độ client-server gặp phải những khó khăn về kết nối do lượng dữ liệu tăng theo cấp số mũ và tính không đáng tin cậy của hệ thống mạng. Các ứng dụng di động phải hoạt động trên nhiều loại mạng chẳng hạn như Wi-Fi, 4G hoặc loại chậm như rùa bò là 2.5G.

Để khắc phục khó khăn này, cac tester cần đảm bảo rằng mỗi một ứng dụng di động đều phải trải qua những kịch bản test khắt khe liên quan tới “đặc tính hay biến đổi” của hệ thống mạng di động bên cạnh những yếu tố hiệu suất quan trọng khác. Nhưng kiểm thử ứng dụng di động với nhiều loại mạng khác nhau thực sự là thách thức nếu chỉ dùng phương pháp thủ công, bởi vì không thể nào kiểm thử các hành vi trong ứng dụng với tất cả các mạng khi bạn chỉ ngồi im một chỗ.

Để giải quyết vấn đề trên, các tester có thể dùng các bộ mô phỏng mạng. Chúng cho phép tạo ra các kịch bản thực tế có thật trong các mạng. Đó là những tình huống như mất dữ liệu, lỗi, jitter (rung pha), độ trễ cao và băng thông thấp. Tất cả các trường hợp này đều có thể được kiểm tra mà không cần bất cứ một sợi cáp hay thiết bị nào cả. Tương tự, bạn có thể lập trình một bản sao của mạng theo như nhu cầu để kiểm thử một ứng dụng với những tình huống vừa nêu.

7. Thiếu kiểm thử bảo mật

Các tester thường hay bỏ lỡ việc kiểm thử bảo mật trong quy trình phát triển phần mềm (SDLC). Trước đây, các phương pháp theo hình thức “Waterfall” được sử dụng phổ biến nhất, trong đó việc kiểm thử sẽ xảy ra sau các giai đoạn phát triển phần mềm. Nhưng khi việc phát triển phần mềm trở nên hoàn thiện hơn thì hầu hết các công ty đã áp dụng phương pháp Agile, với phương pháp này các tester cần phải hợp tác cùng với các lập trình viên trong một khoảng thời gian (sprint) định trước.

Dưới đây là các bước thiết lập kiểm thử bảo mật trong SDLC:

Tiến hành đánh giá rủi ro (risk assessment) với các thành phần của ứng dụng. Đánh giá rủi ro dựa trên các yếu tố bao gồm việc có thể truy cập vào ứng dụng thông qua Internet hay không và loại dữ liệu nào mà ứng dụng đang xử lý và lưu trữ.

Các yêu cầu bảo mật (security requirement) cần được xác định ngay từ đầu trong chu kỳ phát triển khi liệt kê các yêu cầu tính năng.

Việc tiến hành mô hình đe dọa mẫu (threat modeling) phải được thực hiện với quy trình thiết kế và phát triển kiến trúc. Tiến hành mô hình đe dọa bao gồm các bước: xác định, liệt kê, ưu tiên và xử lý các mối đe dọa ban đầu.

Sau pha mộ tả đe dọa mẫu, các tester và các lập trình viên cần cải tiến lại kiến trúc bảo mật, cũng chính là một nhân tố trong mẫu đe dọa. Tại giai đoạn này, các quy tắc viết code bảo mật cần được định nghĩa và việc kiểm thử bảo mật cần phải được làm sáng tỏ.

Để đưa các yêu cầu bảo mật vào tiến trình phát triển phần mềm, thì tất cả các yêu cầu này cần được lưu trữ trên hệ thống quản lý vòng đời sản phẩm (ALM), từ đây các lập trình viên và tester có thể sử dụng chúng nhằm đảm bảo hợp tác chặt chẽ với nhau.

Bạn đã đọc xong 7 lỗi kiểm thử ứng dụng di động phổ biến rồi, giờ thì bạn nên kiểm tra công việc kiểm thử của mình xem liệu bạn có bỏ lỡ thứ gì trong công việc hàng ngày không. Có lẽ bài tổng quan này sẽ giúp bạn nâng cao quy trình kiểm thử ứng dụng di động của mình đấy.

Chia sẻ bài viết ngay

Nguồn bài viết : https://sdtimes.com