station d

Bài viết được sự cho phép của vntesters.com

Trong hầu hết các dự án, vấn đề chất lượng là yêu cầu đầu tiên. Nếu bạn ở trong một dự án như vậy, và chưa có bất kỳ một hệ thống kiểm thử tự động chính thống nào được thiết lập, vậy bạn có thể là người đầu tiên triển khai nó. Nó sẽ giúp đỡ dự án của bạn trong việc xây dựng những sản phẩm chất lượng trong thời gian ngắn, và thúc đẩy việc thương mại hóa sản phẩm sớm hơn.

Automation skills cho tester già mà lười

Tản mạn về Testing

Trong phần ba của loạt bài này, chúng ta sẽ thảo luận về làm cách nào để áp dụng kiểm thử tự động trong dự án, hiểu rõ bước nào cần làm trước và các lý do.

Đi theo những bước này sẽ giúp chúng ta áp dụng kiểm thử tự động một cách liền mạch và cho phép ngăn chặn những cái bẫy mà có thể làm thất bại việc tự động hóa của chúng ta.

Những bước để áp dụng kiểm thử tự động vào dự án

Bước 1 – Thuyết phục ban lãnh đạo

Bất chấp chúng ta đã tìm hiểu và thiết lập kiểm thử tự động để áp dụng vào dự án như thế nào, bạn không thể làm gì được nếu ban lãnh đạo không bị thuyết phục về lợi ích mà kiểm thử tự động mang lại. Một sự thật hiển nhiên: kiểm thử tự động là tốn kém. Các công cụ mắc tiền (chi phí giấy phép cho HP QTP/UFT vào khoảng 8000$ cho một máy). Những chi phí cho kiến trúc sư kiểm thử tự động hay kỹ sư (theo một cách nhìn khác, cũng khá tốn kém). Sau cùng, lợi ích của kiểm thử tự động là không thể thấy ngay lặp tức. Chúng ta cần phải đợi 2-3 tháng trước khi mã kiểm thử được chuẩn bị, kiểm tra và có thể thực thi một cách chắc chắn để ứng dụng vào thực tế.

Vậy làm sao có thể thuyết phục được họ – ban lãnh đạo? Chúng ta cần nói về phân tích chi phí-lợi ích. Như chúng ta có thể hỏi về thời gian chúng ta đã bỏ ra để làm BAT (Build Acceptance Testing) cho ứng dụng? Và, chúng ta có thể nói, nếu làm thủ công mất một ngày, và với kiểm thử tự động, chúng ta có thể kiểm thử trong vòng 2 giờ đồng hồ. Chi phí là mua công cụ, đào tạo nhân sự và chờ đợi kết quả trong 2 tháng. Sau 2 tháng, chúng ta có thể thực thi kiểm thử BAT trong 2 giờ, và nó sẽ tiết kiệm 6 giờ kiểm thử thủ công bất kỳ khi nào ứng dụng có phiên bản mới. Nếu có 4 phiên bản trong một tháng, chúng ta sẽ tiết kiệm được 24 giờ, hay 3 ngày kiểm thử thủ công.

Nó không có nghĩa là kỹ sư kiểm thử thủ công không làm gì, họ sẽ dùng 6 giờ kiểm thử đó để tập trung vào các chức năng mới và quan trọng của ứng dụng, trong khi kiểm thử tự động sẽ làm những vấn đề qui hồi. Sự thiết lập này sẽ nâng cao chất lượng chung của sản phẩm lên nhiều lần.

Nếu quản lý không sẵn sàng trả giá cho chất lượng của sản phẩm, thì không ai có thể ép họ làm vậy. Họ sẽ học một cách tự động khi khách hàng than phiền về sản phẩm. Chất lượng ảnh hưởng lên mọi thứ. Nó ảnh hưởng đến bán hàng, ảnh hưởng mối quan hệ với khách hàng, ảnh hưởng nhận thức về chúng ta trong mắt khách hàng. Vậy nên, ban lãnh đạo thông minh luôn luôn đầu tư vào trong chất lượng của sản phẩm.

Năm bước cần nhớ để thuyết phục quản lý

Nói về lợi ích của kiểm thử tự động một cách chi tiết
Nói rõ kiểm thử tự động là tốn kém và nó tốn chi phí ban đầu, nhưng chi phí sẽ giảm dần khi mã kiểm thử được chuẩn bị và sẵn sàng thực thi
Nói về thời gian 3 tháng chờ đợi trước khi mong muốn bất kỷ kết quả nào từ kiểm thử tự động
Nói rõ kiểm thử tự động không thay thế kiểm thử thủ công, nhưng có thể hỗ trợ kỹ sư kiểm thử thủ công bằng cách kiểm thử nhiều hơn trong cùng một thời gian
Kiểm thử tự động không có nghĩa là kiểm thử với thời gian ít hơn; nó có nghĩa kiểm thử nhiều hơn với cùng thời gian (nếu kỹ sư kiểm thử thủ công thường dùng 8 giờ để kiểm thử BAT, họ sẽ có thể vừa làm BAT cộng với kiểm thử chức năng mới, đồng thời những thứ khác trong cùng 8 giờ với sự trợ giúp của kiểm thử tự động)

Hãy nhớ, thuyết phục quản lý là bước đầu tiên và quan trọng nhất để áp dụng kiểm thử tự động vào dự án/công ty. Nếu họ không bị thuyết phục, hãy quên kiểm thử tự động đi (hoặc tìm một dự án/công ty khác :-))

Bước 2 – Tìm những chuyên gia về kiểm thử tự động

Có hai dạng chuyên gia về kiểm thử tự động

Kiến trúc sư kiểm thử tự động
Kỹ sư kiểm thử tự động

Kiến trúc sư kiểm thử tự động là rất hiếm. Họ khó tìm, cực kỳ mắc và cũng cực kỳ cần thiết cho sự thành công của dự án kiểm thử tự động. Những người này thường chịu trách nhiệm xây dựng mô hình kiểm thử tự động. (Chúng ta sẽ thảo luận về mô hình kiểm thử tự động một cách chi tiết ở một bài khác).

Kiến trúc sư kiểm thử tự động có kinh nghiệm với các loại công cụ khác nhau và họ biết điểm mạnh cũng như điểm yếu của từng công cụ. Họ sẽ giúp ban quản lý tìm công cụ thích hợp cho kiểm thử tự động với các phân tích ứng dụng và công nghệ dùng trong ứng dụng một cách cẩn thận. Họ cũng sẽ giúp xây dựng mô hình, thiết kế các quy ước đặt tên và tạo ra các qui định cho việc viết mã. Họ cũng hỗ trợ trong việc lựa chọn kịch bản kiểm thử nào nên được tự động hóa trước.

Nếu bạn có thể tìm nhân sự chính xác cho vị trí kiến trúc sư kiểm thử tự động, một nữa công việc của bạn đã hoàn thành.

Kỹ sư kiểm thử tự động, mặt khác, là những người sẽ chuyển hóa kịch bản kiểm thử thủ công thành mã kiểm thử tự động. Họ sẽ làm việc dưới quyền kiến trúc sư kiểm thử tự động và sẽ chịu trách nhiệm tạo và thực thi mã kiểm thử.

Vài công ty tuyển dụng kỹ sư kiểm thử tự động từ bên ngoài, và vài công ty làm tuyển dụng nội bộ với việc đào tạo từ những kỹ sư thủ công đang có sẵn. Dù với trường hợp nào, nhân sự cũng phải có khả năng lập trình, đặc biệt là lập trình hướng đối tượng. Một kết hợp của một kiến trúc sư kiểm thử tự động và các kỹ sư kiểm thử tự động là tuyệt vời cho hầu hết các dự án/sản phẩm.

Bước 3 – Dùng công cụ chính xác cho tự động hóa

Vần đề này xứng đáng có một bài viết riêng, (và sẽ có). Nó là một bước khó khăn trong toàn quá trình bắt đầu kiểm thử tự động. Có rất nhiều công cụ tự động trên thị trường, nhưng chúng ta phải lựa chọn những công cụ tốt nhất cho ứng dụng/dự án của chúng ta.

Nói ngắn gọn, ở đây chỉ liệt kê ra những điểm cần xem xét khi lựa chọn công cụ. Phần giải thích chi tiết sẽ được nói trong một bài riêng.

Những điểm quan trọng cần xem cét khi lựa chọn công cụ chính xác:

Công cụ phải hợp với ngân sách. Những công cụ kiểm thử tự động thật sự rất tốn kém. Vậy nên công ty nên có một ngân sách để mua công cụ.
Công cụ phải hỗ trợ cho công nghệ đang dùng trong ứng dụng/dự án của chúng ta. Nếu ứng dụng sử dụng Flash hay Silverlight, công cụ phải hỗ trợ nó. Nếu ứng dụng là thực thi trên di động, công cụ phải có khả năng thực thi kiểm thử di động. Chúng ta có thể mua một công cụ mà hỗ trợ toàn bộ công nghệ dùng trong ứng dụng, hoặc chúng ta có thể mua nhiều công cụ khác nhau cho từng công nghệ. Ví dụ, chúng ta dùng Selenium cho ứng dụng Web, Robotium cho ứng dụng Android và MS Coded UI cho ứng dụng Windows. Bất kể quyết định là như thế nào, nó phải nằm trong ngân sách của công ty.
Chúng ta phải có nhân sự với kỹ năng cần thiết, những người sẽ sử dụng công cụ hay học dùng công cụ trong thời gian ngắn. Ví dụ, chúng ta đã thuê một kiến trúc sư kiểm thử với kinh nghiệm làm QTP nhưng lại mua giấy phép sử dụng MS Coded UI. Công cụ chỉ như một chiếc xe tốt, và chúng ta cần phải có một tài xế tốt để lại những chiếc xe đó.
Công cụ phải một cơ chế báo cáo tốt để hiển thị kết quả cho các bên liên quan sau mỗi lần thực thi.

Có có những nhân tố khác ảnh hưởng đến việc lựa chọn công cụ, và chúng ta sẽ thảo luận chi tiết ở một bài khác.

Bước 4 – Phân tích ứng dụng khác nhau để xác định những gì phù hợp nhất cho tự động hóa

Nếu công ty đang làm với 5 ứng dụng, không cần thiết toàn bộ sẽ được tự động hóa. Chúng ta cần xem xét những nhân tố khác nhau để lựa chọn ứng dụng nên tự động hóa kiểm thử.

Ứng dụng nên tự động hóa kiểm thử cần có những yếu tố:

Ứng dụng không nên ở giai đoạn đầu của chu trình phát triển (Ứng dụng nên có toàn bộ hay vài chức năng mà đã ổn định và đã kiểm thử bởi kỹ sư kiểm thử thủ công)
Giao diện của ứng dụng cần ổn định (Giao diện không được thay đổi một cách thường xuyên)
Kịch bản kiểm thử thủ công đã được viết ra

Mục tiêu chính của kiểm thử tự động là đảm bảo nếu ứng dụng không có lỗi ở một phiên bản, nó sẽ không có lỗi ỡ phiên bản kế tiếp. Kỹ sư kiểm thử thủ công không nên tốn thời gian của họ để tìm lỗi qui hồi, những vấn đề đó nên được phát hiện bởi kiểm thử tự động.

Vậy nên, để tìm lỗi qui hồi, chúng ta cần một ứng dụng mà đã ổn định và đã có kịch bản kiểm thử cho nó. Nhóm kiểm thử tự động sẽ chuyển hóa những kịch bản kiểm thử thành mã và sẽ thực thi những mã này trên những phiên bản để đảm bảo lỗi qui hồi không xuất hiện.

Bài viết gốc được đăng tải tại vntesters.com

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên Station D