Manual testing là gì? Tương lai của một loại thử nghiệm lâu đời

1. Manual testing là gì? Các cách kiểm tra thủ công Manual testing

Manual testing là hình thức kiểm tra phần mềm lâu đời nhất và thiết yếu nhất. Về cốt lõi, nó đại diện cho một người thử nghiệm tương tác với một ứng dụng như người dùng và tìm kiếm các khiếm khuyết và liệu ứng dụng có đáp ứng các yêu cầu công nghệ đã nêu hay không. Khi những tiến bộ vượt bậc của công nghệ thông tin đã được thực hiện trong nhiều năm qua, ngày càng có nhiều bài kiểm tra trở nên tự động trên các lớp khác nhau của ứng dụng được thử nghiệm. Mặc dù vậy, nghệ thuật và khoa học của Manual testing vẫn tiếp tục quan trọng đối với chất lượng phần mềm trong tương lai gần.

1.1. Kiểm tra thủ công theo kịch bản

Khi công việc của Hetzel xông ra vào năm 1972, hầu hết các tổ chức đều sống trong hỗn loạn, hoặc cố gắng làm theo một số hình thức mô hình thác nước. Dưới thác nước, chương trình được xây dựng, sau đó hệ thống kiểm tra cho đến khi các lỗi rơi ra và sửa chữa, và sau đó sản phẩm được chuyển đi. Người kiểm tra thường là người dùng cuối, người từ bộ phận hỗ trợ khách hàng hoặc các vai trò khác. Các kịch bản nói với họ phải làm gì. Khi phần mềm cần nâng cấp, các kịch bản có thể được chạy lại. Về lý thuyết, họ cho phép công ty trao đổi bất kỳ ai để thực hiện kiểm tra, hạ thấp tỷ lệ hàng giờ và giúp việc tìm kiếm người kiểm tra dễ dàng hơn.

Trong thực tế, điều này dẫn đến công việc nhàm chán thường được thực hiện tồi. Một số người cho rằng các ứng dụng của họ quá phức tạp; các kịch bản cung cấp hướng dẫn điều hướng cho người thử nghiệm mới. Theo dõi kịch bản khuyến khích mọi người làm theo các bước tương tự mỗi lần. Nó có thể nhất quán, nhưng nó có thể giảm phạm vi bảo hiểm theo thời gian khi các tính năng được thêm vào ứng dụng. Tệ nhất là, các trường hợp thử nghiệm có thể khiến người xem chúng chỉ tập trung vào kết quả mong đợi, thiếu các lỗi khác trong phần mềm.

Việc làm it phần mềm tại Hồ Chí Minh

1.2. Kiểm tra thủ công như thăm dò

Khi Adam Yuret bắt đầu sự nghiệp công nghệ, anh ấy đang làm thử nghiệm. Nhiệm vụ đầu tiên của anh ấy là lấy một phần mềm mới và chơi với nó. Trực tiếp với âm thanh của những từ mà chơi với nó, một số chuyên gia sẽ nhăn nhó. Tuy nhiên, chơi, về cơ bản, là khám phá kết thúc mở. Thử nghiệm khám phá là quá trình tìm hiểu về phần mềm trong khi thử nghiệm nó, có ý tưởng thử nghiệm tiếp theo xuất phát từ kết quả của trước đó. Giống như cờ vua, nó thực sự có kỹ năng và kỷ luật để làm tốt - trong khi xuất hiện không thể đoán trước, thậm chí khó hiểu cho người quan sát bên ngoài.

Vấn đề với thăm dò hay nói cách khác là thử nghiệm và các bài test là vấn đề rắc rối của bảo hiểm. Làm thế nào để bạn biết khi bạn được thực hiện? Làm thế nào chúng ta có thể tự tin rằng chúng ta đã chạm vào tất cả các phần của ứng dụng quan trọng đối với khách hàng? Và, làm thế nào bạn có thể mô tả công việc bạn đã làm cho người khác? Một cách khác là tạo bản đồ hoặc bảng điều khiển thử nghiệm. Bảng điều khiển thử nghiệm cho phép người kiểm tra đánh giá mức độ bao phủ mà họ có đối với bất kỳ tính năng nào và chất lượng, theo thang điểm từ một đến mười.

Xem thêm: Trọn bộ thông tin về Apache là gì? Ưu – nhược điểm của Apache

1.3. Sử dụng các công cụ để khám phá

Một loại Manual testing thứ ba là sử dụng các công cụ để thu thập hoặc tổng hợp dữ liệu. Một người kiểm tra cư trú trong lưới, cắt và dán dữ liệu vào bảng tính và áp dụng hàm tổng để xem liệu tổng cộng có chắc chắn đang thực hiện Manual testing hay không. Điều gì xảy ra nếu dữ liệu ra khỏi cơ sở dữ liệu và người kiểm tra đã viết một câu lệnh CHỌN, sau đó chạy nó thông qua một công cụ khác để so sánh với bản phát hành trước đó? Đó có phải là Manual testing?

Sự khác biệt chính là giữa các công cụ chạy với phần mềm không được giám sát, tạo ra kết quả và các công cụ được người thử nghiệm tạo ra để sử dụng một lần. Lần đầu tiên người thử nghiệm tạo ra công cụ và chạy nó, công việc là thủ công. Họ đang tích cực làm việc với sản phẩm, học hỏi và thay đổi những gì họ làm dựa trên thông tin đó. Nếu kiểm tra trở thành một cái gì đó chạy tự động, chỉ tạo một cảnh báo email trong trường hợp thất bại, thì đó không còn là Manual testing. Rất ít người gọi đó là Manual testing - nhiều khả năng họ gọi đó là thử nghiệm kỹ thuật trên đường.

2. Tương lai của Manual testing

Ở đây, thách thức: Đối với bất kỳ lần chạy nước rút nào, nhân viên kỹ thuật có thể có khoảng 200 giờ làm việc để thử nghiệm trên cấp độ đơn vị (mã). Ghi lại một phần của tự động hóa có thể mất 10 giờ; làm bằng tay có thể mất một. Nhân viên kỹ thuật cần quyết định xem họ sẽ tạo ra hai mươi kiểm tra tự động hay 200 kiểm tra tính năng của con người. Câu trả lời của bên phải có lẽ là sự kết hợp của cả hai. Mặt thủ công có thể chứa một số hướng dẫn, một số thăm dò và một số công cụ. Bác sĩ Kaner đề xuất danh sách kiểm tra, cho phép nhân viên làm xét nghiệm trước, sau đó tham khảo danh sách kiểm tra để xem họ có bỏ sót điều gì không.

Cách tốt nhất để sử dụng công cụ là giữa đường cong chuông: các ứng dụng vừa đủ phổ biến để có nhu cầu thị trường về hỗ trợ công cụ và đủ trưởng thành để hỗ trợ nhu cầu đó. Sau đó là các bối cảnh khác: phần mềm được điều chỉnh, giao diện không ổn định và các ứng dụng cường độ đồ họa trong đó các vấn đề có thể nói dối là những vấn đề mà chỉ con người mới có thể nhận ra. Và, tất nhiên, kiểm tra tính năng. Một số công việc Manual testing có thể thú vị, thú vị và có giá trị. Một số trong đó, như công việc quy định, có thể nhàm chán nhưng quan trọng. Hầu hết các tổ chức sẽ sử dụng hỗn hợp các phương pháp cho các phần khác nhau của quy trình và hỗn hợp đó sẽ thay đổi theo thời gian. Vì điều này, bạn cần có một chiến lược có ý thức. Hiểu những gì bạn dành thời gian của bạn trên. Quan trọng nhất, hãy chuẩn bị để thay đổi cách tiếp cận của bạn. Trong kinh doanh này, điều duy nhất không đổi là thay đổi.

Việc làm tester

3. Nền tảng và công nghệ mới và mới nổi

Khả năng phát triển các chương trình trên nền tảng mới, chẳng hạn như trên web, điện thoại hoặc máy tính bảng (hoặc plugin như Flash hoặc Silverlight), thường được tạo ra trước công nghệ để kiểm tra các nền tảng đó. Ví dụ: khi Google tạo ra hệ điều hành Android, không có công cụ nào để lái bất kỳ ứng dụng Android gốc nào và chắc chắn không có bất kỳ ứng dụng nào cho chính hệ điều hành. Bởi lẽ những người ở Google đang thử nghiệm là con người. Có lẽ con người thông minh, có lẽ sử dụng các công cụ. Ở cấp độ mã, Android có thể đã có các bài kiểm tra đơn vị và kiểm tra theo mô hình và tất cả các loại kiểm tra, nhưng ở cấp hệ thống, Android đã sử dụng chiến lược Manual testing. Làm thế nào chúng ta có thể áp dụng được những thành quả trên?

Xem thêm: Aptech là gì? Có hay không việc lập nghiệp từ Aptech

3.1. Giao diện người dùng thay đổi

Đối với giao diện người dùng trưởng thành, thay đổi là một điều tốt - nhưng hãy đảm bảo những thay đổi bạn thực hiện ngày hôm nay chỉ tác động đến một hệ thống phụ, để bạn có thể xem các thử nghiệm thất bại, sửa đổi chúng và xem chúng vượt qua. Giống như cắt gỗ, bạn đo hai lần và cắt một lần. Các bài kiểm tra thất bại cần phải có màu xanh lá cây là một biện pháp thứ hai.

Khi một ứng dụng mới, giao diện người dùng của nó liên tục thay đổi. Điều đó có nghĩa là rất nhiều lỗi sai; quá nhiều lần chạy thử chậm bị treo trong khi chờ dữ liệu không có, chạy lại quá nhiều và mất nhiều thời gian hơn dự kiến ​​chờ đợi và sửa chữa. Một vài tổ chức đã nhận được sự tích cực của việc thay đổi các kiểm tra tự động trước khi GUI mới được tạo, nhưng chúng là một thiểu số nhỏ, với một bộ công cụ rất cụ thể.

Các nhóm thử nghiệm một ứng dụng mới, nhỏ liên tục thay đổi có thể tốt hơn là thử nghiệm nó bằng tay. Nếu tất cả các nhóm làm là tạo ra các ứng dụng mới, nhỏ không có nhiều bảo trì liên tục, thì việc kiểm tra ở cấp GUI có thể không đáng để tìm lỗi. Nó có thể cung cấp nhiều giá trị hơn như bản demo làm việc! Điều này đặc biệt đúng đối với các ứng dụng chưa tồn tại. Các mẫu thử nghiệm giấy và bảng trắng có thể thay thế ngày hoặc tháng làm việc chỉ trong vài phút, nhưng vẫn không có một máy tính trên thế giới có thể làm công việc đó (ít nhất là chưa).

3.2. Thiết kế đồ họa và truyền thông

Các giao diện người dùng không ổn định cuối cùng thường là các giao diện người dùng phổ biến nhất, như các trang web thương mại điện tử và trò chơi video. Một dự án thương mại điện tử đã thuê tôi làm người thử nghiệm (người Manual testing) để đảm bảo mọi thứ đều chính xác. Dự án cũng có các bài kiểm tra GUI tự động chạy qua đêm. Một thử nghiệm điển hình sẽ là thử di chuyển logo giỏ hàng mini, ở bên cạnh màn hình, giảm hai mươi pixel. Khi tôi kiểm tra nó, nút Gửi ứng dụng trên mạng bây giờ thấp hơn hai mươi pixel, với mười điểm dưới cùng hiện ra khỏi màn hình và chỉ có nửa trên của các chữ cái hiển thị. Công cụ vẫn có thể nhấp vào nút, nhưng tôi đã thấy vấn đề ngay lập tức vì tôi là một con người.

Có một số công cụ hiện đại có thể tìm kiếm sự khác biệt trực quan giữa các lần chạy thử, đưa chúng đến sự chú ý của người kiểm tra, nhưng một ứng dụng phương tiện như ứng dụng tôi đang làm việc sẽ chỉ đưa ra lỗi với mỗi thay đổi. Mặc dù có nhiều tự động hóa hơn trong các trò chơi video và ứng dụng đa phương tiện, (ví dụ, các bot bot, để mô phỏng các đội trong trò chơi bóng đá trực tuyến), con người cần tiếp tục đóng vai trò thử nghiệm các ứng dụng cường độ đồ họa trong nhiều năm tới.

3.3. Phần mềm quy định

Một số công ty đã thiết lập các quy trình kinh doanh bằng văn bản cho cách họ kiểm tra phần mềm. Những trường hợp này có thể bao gồm các trường hợp thử nghiệm bằng văn bản có chữ ký vật lý trên tài liệu và ngày tháng khi thử nghiệm đó chạy. Các hệ thống thông tin này đã lỗi thời, lỗi thời và cực kỳ khó thay đổi. Họ có thể kiểm soát hệ thống điện tử hàng không, các thiết bị y tế được nhúng trong cơ thể người hoặc thuốc đó hoặc các giao dịch tài chính.

Nhiều người kiểm thử phần mềm có thể là một chút ung dung. Họ nói rằng phần mềm tự động hóa thử nghiệm của họ sẽ tạo ra các ảnh chụp màn hình, thậm chí cả video khi nó chạy và tự động đặt nó vào ổ đĩa mạng. Các video sẽ được đóng dấu với dấu vết quay lại ý tưởng thử nghiệm, cộng với dấu thời gian, cộng với bản dựng chính xác của phần mềm mà thử nghiệm đã chạy. Đối với vấn đề đó, chúng có thể bao gồm ID hình ảnh Docker, giúp tái tạo toàn bộ máy chủ web.

Việc làm nhân viên phát triển phần mềm

Tuy nhiên, vì một số lý do, các kiểm toán viên và giám đốc điều hành chịu trách nhiệm hiếm khi thoải mái với những người thử nghiệm sử dụng phong cách này. Trong tương lai gần, các hệ thống đã giết chết hoặc phá sản bất cứ ai có Manual testing (nhưng có thể) có thể sẽ tiếp tục được thử nghiệm theo cách đó. Có, một vài trong số họ sẽ chuyển sang sử dụng một cách tiếp cận tập trung vào công cụ hơn. Việc chuyển đổi sẽ chậm, với nhiều thông báo.

Hy vọng rằng với những thông tin trên đã các bạn hiểu hơn về Manual testing. Đây là một trong những bước không thể thiếu trong bất kỳ doanh nghiệp và lĩnh vực nào. Nó có thể áp dụng đối với mọi chiến lược lẫn sản phẩm và là phương pháp tiên phong của các thử nghiệm. Hãy tiếp tục theo dõi các bài viết khác trên timviec365.vn, và thông qua website để tìm được cho mình những việc làm phù hợp nhé! 

Bài viết tham khảo: Thắc mắc ASP là gì và ASP.NET là gì cho chuyên viên lập trình!

Tìm việc làm