Bài viết được sự cho phép của vntesters.com
Đây là bài cuối trong loạt các bài về kiểm thử tự động. Bài này sẽ tổng hợp lại một số cách làm tốt nhất và các chiến lược để làm kiểm thử tự động.
Mặc dù những bài trước đã có đề cập đến vài cách làm hay (và vài điều sẽ được nhắc lại ở đây), bài này chỉ liệt kê vài điều, nhưng quan trọng nhất, để làm kiểm thử tự động.
Những chiến lược này không chỉ là từ kinh nghiệm bản thân mà còn từ những chuyên gia kiểm thử như Micheal Bolton, James Back và Cem Kaner. Những cách làm việc này nên được áp dụng trong mọi dự án kiểm thử tự động.
Thuê một đội ngũ hay kỹ sư kiểm thử chuyên trách
Đây là một điều cơ bản. Đừng đòi hỏi kỹ sư kiểm thử thủ công trong dự án tham gia vào kiểm thử tự động. Nếu chúng ta muốn họ phải làm được kiểm thử tự động, hãy giải phóng họ khỏi các công việc kiểm thử thủ công. Kiểm thử tự động là một công việc toàn thời gian. Để đạt được điều đó, chúng ta cần những nhân sự chuyên trách.
Một công cụ kiểm thử tự động là quan trọng, nhưng nó không phải là giải pháp cho tất cả
Chúng ta đã nói về cách lựa chọn một công cụ kiểm thử. Nhưng lựa chọn được một công cụ đúng chỉ là bước khởi đầu. Vài người quản lý có hiểu lầm rằng, nếu có một công cụ đúng, mọi chuyện về kiểm thử tự động sẽ dễ dàng. Hãy cẩn thận, công cụ kiểm thử tự động không cho chúng ta mọi thứ. Chúng chỉ làm cho quá trình tự động hóa dễ dàng hơn. Và chúng ta cần những nhân sự có kỹ năng để hoàn thành quá trình đó.
Thông thường, những công cụ kiểm thử tự động cũng có lỗi của nó và chúng gặp vấn đề khi xác định những đối tượng UI phức tạp của ứng dụng. Nhân sự mà chúng ta có, nếu họ có kỹ năng, sẽ đưa ra những giải pháp để đẩy nhanh quá trình làm việc. Ngược lại, nếu nhân sự không tốt, chỉ với công cụ không thể đảm bảo cho một dự án kiểm thử tự động thành công.
Lựa chọn công cụ kiểm thử quen thuộc với nhân sự đang có
Nếu nhân sự của chúng ta quen thuộc với C# và ứng dụng cần kiểm thử cũng phát triển bằng C#, vậy thì không có lý do nào để chúng ta lựa chọn một công cụ kiểm thử không hỗ trợ viết mã bằng C#.
Học ngôn ngữ lập trình là một quá trình tốn kém thời gian. Bỏ qua được bước này bằng cách sử dụng một công cụ hợp lý sẽ tối thiểu hóa thời gian làm quen với công cụ.
Hiểu biết về ứng dụng cần kiểm thử
Lựa chọn công cụ kiểm thử tự động phụ thuộc vào độ nặng của công nghệ được dùng trong ứng dụng. Hiểu biết về ứng dụng từ trong ra ngoài trước khi bắt đầu việc kiểm thử tự động.
Nếu là một ứng dụng web, biết về những trình duyệt mà nó sẽ hỗ trợ. Biết về những công nghệ được sử dụng trong nó. Nếu là một ứng dụng Desktop, biết về ngôn ngữ để xây dựng nó. Những đối tượng của bên thứ ba được dùng trong ứng dụng. Những điều này sẽ giúp chúng ta lựa chọn công cụ chính xác và kiểm thử tự động trong tương lai sẽ dễ dàng hơn.
Kiểm thử tự động tốt nghĩa là các kịch bản kiểm thử thủ công tốt
Những kịch bản kiểm thử thủ công tốt sẽ tiết kiệm công sức tự động hóa những kịch bản dễ được làm tự động nhưng không đủ mạnh để tìm lỗi.
Đây là một câu nói trong quyển sách “Lessons Learned in Software Testing“:
Kết quả của việc tự động hóa mà không dựa vào thiết kế kiểm thử tốt là có quá nhiều việc để làm nhưng giá trị mang đến lại chẳng bao nhiêu.
Luôn luôn nên viết kịch bản kiểm thử ở định dạng dành cho kiểm thử thủ công. Xác định tất cả các điều kiện quyết định và dữ liệu kiểm thử. Viết các bước rõ ràng và viết các kết quả mong muốn cho các bước. Mục tiêu của từng kịch bản nên rõ ràng và nó nên độc lập với những kịch bản kiểm thử khác. Kỹ sư kiểm thử tự động nên thực thi kịch bản kiểm thử một cách thủ công, ít nhất một lần, để quyết định các đối tượng nào cần xác định và luồng làm việc. Nên tham khảo thêm từ những kỹ sư kiểm thử thủ công.
Hoạt động này, đôi khi, giúp xác định lỗi ngay cả trước khi bắt đầu viết mã kiểm thử. Những chuyên gia cho rằng, đa số các lỗi được xác định trong giai đoạn phát triển mã kiểm thử hơn là giai đoạn thực thi các mã đó.
Xác định mọi cơ hội với tự động hóa
Nếu chúng ta được giao kịch bản kiểm thử để tự động hóa, đừng chỉ tự động hóa bản thân kịch bản đó. Thay vào đó, hãy tìm kiếm những cơ hội trong việc tự động hóa đó, mở rộng giới hạn của kịch bản kiểm thử đó.
Ví dụ, nếu kịch bản kiểm thử yêu cầu chúng ta đăng nhập vào một hệ thống. Chúng ta có thể mở rộng kịch bản này bằng cách sử dụng hướng-dữ-liệu. Liệt kê toàn bộ nhựng kịch bản khả thi của việc đăng nhập như mật khẩu không hợp lệ, mật khẩu rỗng, tên đăng nhập rỗng, tên đăng nhập không hợp lệ, v.v… liệt kê nhưng kịch bản khả thi này vào trong một tập tin Excel và xem tập tin đó như một nguồn dữ liệu cho kịch bản kiểm thử. Và giờ, với một kịch bản kiểm thử ban đầu, với tự động hóa, chúng ta có thể kiểm thử toàn bộ kịch bản khả thi với một lần thực thi.
Luôn luôn tìm kiếm những cơ hội có thể làm với tự động hóa, những việc khó làm với cách làm thủ công. Như kịch bản kiểm thử sức tải, kiểm thử hiệu suất, cùng một kịch bản trên nhiều môi trường khác nhau, cấu hình khác nhau, v.v… đó là những kịch bản khó có thể làm với kiểm thử thủ công.
Chúng ta không thể tự động hóa mọi thứ
Kiểm thử tự động chỉ thực thi những kịch bản nào mà yêu cầu phài thực thi thường xuyên. Chúng ta bắt đầu với bộ kịch bản Smoke trước. Sau đó, đến bộ kịch bản cho kiểm thử chấp nhận. Rồi đến những kịch bản phải sử dụng thường xuyên, và những kịch bản mà tốn nhiều thời gian. Nhưng phải đảm bảo rằng mỗi kịch bản mà chúng ta đã tự động hóa, nó phải tiết kiệm thời gian cho kỹ sư kiểm thử thủ công để tập trung vào những thứ quan trọng khác.
Tự động hóa ở đây không phải để thay thế kỹ sư kiểm thử thủ công. Nó không thể. Tự động hóa có mặt để làm những công việc lặp đi lặp lại thay cho kỹ sư kiểm thử thủ công để họ dành sự tập trung và sức lực cho việc tìm kiếm những kịch bản kiểm thử mới và lỗi mới.
Tự động hóa những kịch bản giá trị và tiết kiệm thời gian hay khó để làm với kiểm thử thủ công. Nếu chúng ta làm được điều đó, công việc của kiểm thử tự động đã hoàn thành.
Bỏ qua kiểm thử tự động GUI khi có những giải pháp thay thế
Kiểm thử tự động GUI luôn là phần khó khăn hơn những kiểu kiểm thử tự động khác. Vậy nên, nếu có những tình huống mà chúng ta có thể đạt được mục tiêu mà không cần đụng đến GUI, bằng cách dùng các phương pháp khác như câu lệnh, thì chiến lược chính xác là bỏ qua phần kiểm thử tự động trên GUI.
Ví dụ, chúng ta cần kiểm thử sự cài đặt của một ứng dụng. Mục tiêu là kiểm tra ứng dụng có được cài đặt hay không trên một môi trường cụ thể. Một cách tiếp cận là khởi động chương trình cài đặt và nhấn vào “Next” liên tục thông qua công cụ kiểm thử tự động. Cách này khá khó để áp dụng, tốn kém thời gian và nó là một vấn đề khi bảo trì khi mà UI thay đổi. Một cách tiếp cận khác là khởi động quá trình cài đặt bằng câu lệnh với một tham số “silent”. Ứng dụng sẽ được cài đặt mà không có một GUI nào. Mục tiêu của kiểm thử sẽ đạt được với thời gian ít hơn và đáng tin cậy hơn.
Tự động hóa
Dùng tự động hóa cho những mục đích hữu ích khác
là một thứ tuyệt với. Chúng ta có thể đạt được nhiều thứ từ nó mà có thể chúng ta chưa từng nghĩ đến. Tự động hóa không chỉ là viết mã cho một kịch bản kiểm thử thủ công. Hơn thế, chúng ta có thể dùng tự động hóa để làm nhanh những hoạt động khác trong dự án.
Ví dụ, chúng ta có thể dùng tự động hóa để tạo những dữ liệu chính và thiết lập cấu hình môi trường một cách tự động cho kỹ sư kiểm thử thủ công. Sau đó, họ có thể bắt đầu việc kiểm thử của họ sớm nhất có thể.
Tôi có thể đưa cho các bạn một ví dụ từ công ty của tôi. Chúng tôi muốn thay đổi công cụ quản lý kiểm thử. Chúng ta đã dùng “Test Director” (HP ALM) và muốn chuyển sang dùng TFS (Team Foundation Server). Chúng ta có khoảng 4000 kịch bản kiểm thử và báo cáo lỗi trong Test Director. Chuyển toàn bộ dự liệu này sang TFS có thể mất cả tháng nếu làm thủ công. Do đó, quản lý của tôi yêu cầu tôi thử vài cách tự động hóa.
Tôi tìm hiểu vài công cụ và thấy rằng, Test Director sử dụng SQL Server làm cơ sở dữ liệu. Với TFS, tôi tìm ra một công cụ cho phép đọc kịch bản kiểm thử và báo cáo lỗi từ tập tin Excel, nếu nó có một định dạng cụ thể, và có thể ghi vào TFS. Phần còn lại của câu chuyện thật đơn giản. Tôi viết một đoạn SQL để lấy toàn bộ kịch bản kiểm thử và báo cáo lỗi, và ghi nó ra một tập tin Excel với một định dạng xác định. Sau đó, tôi dùng công cụ để đọc những dữ liệu này và ghi vào TFS. Toàn bộ quá trình chỉ mất khoảng 3 giờ. Quản lý của tôi rất hài lòng. Tôi hy vọng bạn thấy được vấn đề tôi đang nói ở đây.
Kiểm thử tự động là phát triển phần mềm
Nếu chúng ta phát triển một ứng dụng chất lượng, nó cần những bài thực hành tốt. Nó cần xem xét mã nguồn để viết mã có chất lượng. Nó cần một khuôn khổ để đi theo. Nó cần bảo trì liên tục.
Kiểm thử tự động về cơ bản là việc phát triển phần mềm. Do đó, những bài thực hành tốt nhất mà chúng ta đi theo khi phát triển ứng dụng cũng nên được áp dụng khi làm kiểm thử tự động. Khuôn khổ kiểm thử tự động nên có. Xem xét mã nên được tiến hành. Lỗi của kiểm thử tự động nên được báo cáo trong kho lỗi. Mã nguồn của kiểm thử tự động nên được để trong một hệ quản lý mã nguồn, v.v… chúng ta càng xem việc kiểm thử tự động giống phát triển ứng dụng, kiểm thử tự động càng thành công.
Kết luận
Đây là kết thúc bài này cũng như toàn chuỗi bài về kiểm thử tự động. Tôi đã học được nhiều thứ khi viết chuỗi bài này và tôi hy vọng bạn cũng học được khi đọc chúng. Kiểm thử tự động là một sự nghiệp đầy hứng khởi và xứng đáng. Làm nó đúng không chỉ mang lại lợi ích cho chúng mà còn cả cho công ty/dự án.
Mỗi ngày làm việc với kiểm thử tự động và những kỹ thuật của nó, tôi tìm thấy nhiều thách thức mới và hấp dẫn cần giải quyết. Chuỗi bài này chỉ đánh dấu vài thứ trên con đường kiểm thử tự động. Tôi hy vọng tôi chuyển tải nó đến các bạn một cách chính xác và rõ ràng.
Bài viết gốc được đăng tải tại vntesters.com
Có thể bạn quan tâm:
- Từ lập trình viên Junior, cùng mình trở thành 1 lập trình viên mid-level nhé
- 9 cách thể hiện cảm xúc khôn ngoan trong công việc
- Lộ trình trở thành lập trình viên sau 9 tháng tự học (Phần hai)
Xem thêm Việc làm Developer hấp dẫn trên TopDev
