Kiểm tra thủ công cho người mới bắt đầu

Thử nghiệm là một lĩnh vực rộng lớn. Khi một ứng dụng phần mềm được phát triển, nó sẽ trải qua nhiều giai đoạn thử nghiệm khác nhau. Các bài kiểm tra có thể khác nhau từ chức năng đến phi chức năng, tùy thuộc vào yêu cầu kiểm tra.

Có hai cách để QA thực hiện kiểm thử:

• Bằng cách thực hiện thủ công các trường hợp kiểm tra như được đề cập trong kế hoạch kiểm tra bằng văn bản
• Bằng cách tự động hóa các kịch bản thử nghiệm bằng cách sử dụng các khung như Selenium WebDriver

Trong một thế giới công nghệ tiên tiến, nơi các công cụ và khuôn khổ tự động hóa đang giúp cuộc sống của các kỹ sư kiểm thử dễ dàng hơn, việc cho rằng kiểm thử thủ công đã lỗi thời là điều bình thường. Tuy nhiên, điều này là hoàn toàn sai sự thật. Bài viết này sẽ giải thích mọi thứ mà một người nên biết về kiểm thử thủ công. Nó cũng sẽ giúp người đọc hiểu tại sao không thể tránh hoàn toàn kiểm thử thủ công.

Kiểm thử thủ công là gì?

Kiểm tra thủ công, như thuật ngữ gợi ý, đề cập đến một quy trình kiểm tra trong đó QA kiểm tra ứng dụng phần mềm theo cách thủ công để xác định lỗi. Để làm như vậy, QA tuân theo kế hoạch kiểm tra bằng văn bản mô tả một tập hợp các kịch bản kiểm tra duy nhất. QA được yêu cầu phân tích hiệu suất của web hoặc ứng dụng di động từ góc độ của người dùng cuối.

QA xác minh hành vi thực tế của phần mềm so với hành vi dự kiến ​​và bất kỳ sự khác biệt nào đều được báo cáo là lỗi.

Hãy lấy một ví dụ đơn giản để giải thích điều này. Một nhà phát triển đã tạo một trang web và muốn kiểm tra chức năng của nó. Trong trường hợp này, hành vi dự kiến ​​là người dùng phải có thể nhập tên người dùng và mật khẩu và gửi thông tin đăng nhập bằng cách nhấp vào nút Đăng nhập .

Tuy nhiên, khi thử nghiệm được thực hiện, nút Đăng nhập không chuyển hướng người dùng đến trang chủ. Trong trường hợp như vậy, QA sẽ báo cáo lỗi cho nhà phát triển.

Kiểm thử thủ công là một phần thiết yếu của bất kỳ chiến lược kiểm thử nào vì nó giúp QA hiểu sâu hơn từ góc độ người dùng cuối. Vì thử nghiệm thủ công được thực hiện bởi con người mà không có sự can thiệp của khung tự động hóa thử nghiệm nên nó đánh giá phần mềm từ số liệu quan trọng nhất: Trải nghiệm người dùng.

Kiểm thử thủ công đóng một vai trò quan trọng trong kiểm thử khám phá hoặc trong các trường hợp kiểm thử được thực hiện một hoặc hai lần. Điều này giúp QA phát hiện ra các lỗi trong giai đoạn đầu của chu kỳ phát triển.

Các giai đoạn kiểm thử thủ công

1. Kiểm tra đơn vị

Kiểm tra đơn vị liên quan đến việc xác minh các thành phần hoặc đơn vị riêng lẻ của mã nguồn. Một đơn vị có thể được gọi là phần nhỏ nhất có thể kiểm tra được của bất kỳ phần mềm nào. Nó tập trung vào việc kiểm tra chức năng của các thành phần riêng lẻ trong ứng dụng. Nó thường được các nhà phát triển sử dụng để khám phá các lỗi trong giai đoạn đầu của chu kỳ phát triển.

Một trường hợp thử nghiệm đơn vị sẽ cơ bản như việc nhấp vào một nút trên trang web và xác minh xem nó có thực hiện thao tác mong muốn hay không. Ví dụ: đảm bảo rằng nút chia sẻ trên trang web cho phép bạn chia sẻ liên kết trang chính xác.

2. Kiểm thử tích hợp

Kiểm thử tích hợp là bước tiếp theo sau kiểm thử đơn vị. Nhiều đơn vị được tích hợp để được kiểm tra tổng thể. Ví dụ: thử nghiệm một loạt trang web theo thứ tự cụ thể để xác minh khả năng tương tác.

Cách tiếp cận này giúp QA đánh giá cách một số thành phần của ứng dụng phối hợp với nhau để mang lại kết quả mong muốn. Thực hiện kiểm thử tích hợp song song với quá trình phát triển cho phép các nhà phát triển phát hiện và định vị lỗi nhanh hơn.

3. Kiểm tra hệ thống

Như tên gợi ý, kiểm thử hệ thống liên quan đến kiểm thử toàn bộ các mô-đun tích hợp của phần mềm. Nó giúp QA xác minh xem hệ thống có đáp ứng các yêu cầu mong muốn hay không. Nó bao gồm nhiều thử nghiệm như xác thực đầu ra dựa trên đầu vào cụ thể,
thử nghiệm trải nghiệm người dùng, v.v.

Các nhóm thực hiện một số loại thử nghiệm hệ thống như thử nghiệm hồi quy , thử nghiệm căng thẳng, thử nghiệm chức năng , v.v., tùy thuộc vào khả năng tiếp cận thời gian và tài nguyên của họ.

4. Kiểm tra giao diện người dùng 

Kiểm tra giao diện người dùng , còn được gọi là Kiểm tra GUI kiểm tra và xác minh các khía cạnh khác nhau của bất kỳ phần mềm nào mà người dùng sẽ tương tác khi sử dụng phần mềm đó. Điều này thường có nghĩa là kiểm tra các yếu tố hình ảnh để đảm bảo rằng chúng đang hoạt động theo các yêu cầu về chức năng và hiệu suất. Kiểm tra giao diện người dùng bao gồm nhiều loại chỉ báo trực quan và biểu tượng dựa trên đồ họa – thanh công cụ, phông chữ, menu, hộp văn bản, nút radio, hộp kiểm, màu sắc, v.v. Nó đảm bảo rằng các chức năng giao diện người dùng không có lỗi và hoạt động chính xác như mong đợi.

Cùng với việc kiểm tra các yếu tố giao diện người dùng, kiểm tra giao diện người dùng phải tính đến các trình duyệt, phiên bản trình duyệt và thiết bị khác nhau. Mọi người truy cập internet từ nhiều cách kết hợp giữa trình duyệt-thiết bị-hệ điều hành, điều đó có nghĩa là giao diện người dùng phải hiển thị và hoạt động hoàn hảo từ mỗi cách kết hợp đó. Nói cách khác, kiểm tra trình duyệt chéo phải là một phần thiết yếu của bất kỳ chiến lược kiểm tra giao diện người dùng nào.

Thay vì tải xuống mọi phiên bản trình duyệt và mua mọi thiết bị mà đối tượng mục tiêu của bạn sử dụng, hãy cân nhắc sử dụng cơ sở hạ tầng thử nghiệm dựa trên đám mây, chẳng hạn như cơ sở hạ tầng do BrowserStack cung cấp. Đám mây thiết bị thực của BrowserStack cung cấp hơn 3000 thiết bị và trình duyệt thực để thử nghiệm thủ công và tự động hóa . Điều đó có nghĩa là người dùng có thể thử nghiệm trên nhiều thiết bị và trình duyệt thực bằng cách đăng ký, đăng nhập và chọn các kết hợp cần thiết. Kiểm tra giao diện và hoạt động của trang web hoặc ứng dụng của bạn trên các trình duyệt, thiết bị và hệ điều hành khác nhau bằng một vài cú nhấp chuột trên máy trạm của bạn.

5. Kiểm tra nghiệm thu

Mục tiêu chính của thử nghiệm chấp nhận là xác minh xem toàn bộ hệ thống có phù hợp để sử dụng trong thế giới thực hay không.

Kiểm thử chấp nhận được thực hiện cả bên trong và bên ngoài. Thử nghiệm chấp nhận nội bộ (còn được gọi là thử nghiệm alpha) được thực hiện bởi các thành viên của tổ chức. Thử nghiệm bên ngoài (còn được gọi là thử nghiệm beta) được thực hiện bởi một số lượng hạn chế người dùng cuối thực tế. Cách tiếp cận này giúp các nhóm đánh giá mức độ sản phẩm đáp ứng các tiêu chuẩn của người dùng. Nó cũng xác định các lỗi trong giai đoạn cuối cùng trước khi phát hành sản phẩm.

Trong số các hình thức kiểm tra chấp nhận khác, kiểm tra khả năng tiếp cận đáng được đề cập đặc biệt. Kiểm tra khả năng truy cập đảm bảo rằng mọi tính năng của trang web hoặc ứng dụng đều dễ sử dụng đối với những người có thể bị khuyết tật như khiếm thị hoặc khiếm thính, mù màu hoặc bất kỳ vấn đề thể chất nào khác. Họ có thể gặp một số dạng khuyết tật, có nghĩa là họ cần một số dạng công nghệ hỗ trợ để vận hành một số công nghệ nhất định.

Các loại kiểm thử thủ công

1. Kiểm thử hộp trắng

Kiểm thử hộp trắng, còn được gọi là kiểm thử hộp thủy tinh hoặc kiểm thử trong suốt, là một cách tiếp cận mà QA quen thuộc với mã nội bộ hoặc cấu trúc của ứng dụng. Nó chủ yếu được sử dụng để thử nghiệm đơn vị. Kiểm tra hộp trắng cũng bao gồm các kỹ thuật cụ thể như kiểm tra luồng dữ liệu, kiểm tra luồng điều khiển, phạm vi quyết định và kiểm tra đường dẫn, v.v.

2. Kiểm thử hộp đen

Kiểm thử hộp đen là một phương pháp kiểm thử trong đó QA không có bất kỳ kiến ​​thức nào về mã cơ bản hoặc cấu trúc của ứng dụng. QA tương tác với ứng dụng phần mềm giống như người dùng cuối để kiểm tra hành vi chức năng và phi chức năng của nó. Điều này giúp phát hiện ra một số lỗi thường bị bỏ qua trong các giai đoạn trước.

3. Kiểm thử hộp xám

Phương pháp kiểm thử Grey-Box là sự kết hợp của cả kỹ thuật kiểm thử hộp trắng và hộp đen. Mục đích chính của phương pháp này là xác định bất kỳ lỗi nào xuất hiện do cách sử dụng không phù hợp hoặc bất kỳ lỗi cấu trúc nào.

Cách thực hiện Kiểm thử thủ công

Dưới đây là cách thực hiện kiểm tra thủ công từng bước:

1. Phân tích yêu cầu từ tài liệu đặc tả yêu cầu phần mềm
2. Tạo một kế hoạch kiểm tra rõ ràng
3. Viết các trường hợp thử nghiệm bao gồm tất cả các yêu cầu được xác định trong tài liệu
4. Nhận các trường hợp thử nghiệm được xem xét bởi trưởng nhóm QA
5. Thực hiện các trường hợp thử nghiệm và phát hiện bất kỳ lỗi nào
6. Báo cáo lỗi, nếu có và sau khi đã sửa, hãy chạy lại các kiểm tra không thành công để xác minh lại các bản sửa lỗi