12/08/2018, 15:05

Tích hợp Manual và Automated Testing trong Test Plan

Các cuộc tranh luận luôn luôn xảy ra trong cộng đồng kiểm thử phần mềm về cách sử dụng kiểm tra thủ công hoặc tự động. Trong bài viết này, tôi sẽ giải thích rằng cả hai đều có giá trị của nó. Ngoài hướng dẫn bạn làm thế nào để lựa chọn các hạng mục kiểm tra để tự động hóa và đề xuất một cách tiếp ...

Các cuộc tranh luận luôn luôn xảy ra trong cộng đồng kiểm thử phần mềm về cách sử dụng kiểm tra thủ công hoặc tự động. Trong bài viết này, tôi sẽ giải thích rằng cả hai đều có giá trị của nó. Ngoài hướng dẫn bạn làm thế nào để lựa chọn các hạng mục kiểm tra để tự động hóa và đề xuất một cách tiếp cận tích hợp kiểm thử tự động thông suốt trong kế hoạch kiểm tra của bạn.

Kế hoạch kiểm tra trung bình cho một ứng dụng thương mại sẽ có từ 2.000 đến 10.000 trường hợp thử nghiệm. Nhóm thử nghiệm của bạn phải tự thực hiện và kết quả tài liệu cho từ 400 đến 2.000 trường hợp thử nghiệm. Và ngày phát hành dự kiến của sản phẩm của bạn đang đến rất nhanh. Như đồ thị minh họa ở dưới, có một chi phí trả trước để kiểm tra tự động (trái ngược với thử nghiệm hoàn toàn bằng tay), nhưng khi số lượng các trường hợp thử nghiệm và xây dựng tăng, chi phí cho mỗi thử nghiệm sẽ giảm.

Song hành - Manual and Automated Testing trong Test Plan

Đây có thể là một thời điểm tốt để thêm kiểm tra tự động vào test plan của bạn. Bạn sẽ nhận ra rằng không có kế hoạch test có thể được thực hiện hoàn toàn bằng phương pháp tự động. Thách thức là quyết định Manual và Automated Testing sẽ dùng cái nào là trọng điểm.

Đây là về việc thiết lập những kỳ vọng thực tế. Tôi tin chắc rằng tự động hóa không thể làm tất cả. Bạn không nên tự động tất cả mọi thứ. Hãy bắt đầu bằng cách thiết lập những kỳ vọng ở mức hợp lý. Tôi nghĩ sẽ tự động hóa 20% các trường hợp thử nghiệm.

Làm thế nào để chọn các yếu tố của kế hoạch automation test

Trên giả thuyết, chúng ta đã quyết định để tự động hóa 20% total các case. Một câu hỏi là " 20% này bao gồm các case nào?". Thường chúng ta sẽ chọn những case thường xuyên xảy ra và chúng lặp đi lặp lại trong những bản build. Trong 20% các trường hợp kiểm tra đó sẽ làm giảm thời gian kiểm tra toàn bộ các yếu tố , giải phóng các nhóm làm việc khác. Đó có thể là một ý tưởng tốt để bắt đầu.

Đây là những trường hợp thử nghiệm mà bạn dành nhiều giờ thực hiện, mỗi ngày, mỗi bản phát hành, và mỗi khi xây dựng. Chúng ta sẽ cảm thấy đơn điệu, nhàm chán, nhưng nó là rất cần thiết. Những trường hợp thử nghiệm là rất quan trọng bởi vì hầu hết các khách hàng của bạn sử dụng các checklist để chắc chắn cái chúng ta xây dựng là đúng. Do đó đây là những công việc mà sẽ giúp cho công ty và các nhóm thử nghiệm để tồn tại.

20% Số case automation test

Tôi muốn tinh chỉnh khái niệm "tự động hóa 20% các trường hợp thử nghiệm" . Hãy xem xét 20% đại diện liên quan đến hai vấn đề: chi phí kiểm tra (chủ yếu là nhân viên) và khả năng đáp ứng lịch trình thử nghiệm được xác định trước.

Điều gì có thể nhóm thử nghiệm của bạn thực hiện trong một tuần làm việc 40 giờ ? Với chi tiết ngay cả lớn hơn, những gì có thể nhóm thử nghiệm của bạn hoàn thành trong một ngày làm việc 8 giờ? tác động thực hiện bằng cách tự động hóa một tập hợp các trường hợp kiểm tra, làm giảm thời gian kiểm tra là gì: hoàn thành này tập hợp các trường hợp thử nghiệm trong 4 ngày làm việc thay vì 5 (từ 20% các trường hợp thử nghiệm của bạn bây giờ là tự động).

Nếu lương trung bình là 60,000 mỗi năm, chi phí của một ngày 8 giờ là khoảng 230. Sử dụng một công cụ tự động hóa hơn một năm có thể tiết kiệm 52 ngày cho một thử nghiệm - tương đương 11.960 tiền lương. Một nhóm xuất phát với 5 member và với tốc độ này sẽ giúp tiết kiệm 59.800 mỗi năm. Bằng cách tự động ở mức tối thiểu này, bạn đang đạt được những kết quả tương tự như bạn bằng cách thêm thêm 1 tester cho nhân viên của bạn.

Điều này không có nghĩa là bạn sẽ giảm đi số lượng test member. Nó có nghĩa rằng bây giờ bạn có các nguồn lực tương đương của 1 thành viên trong nhóm phụ để kiểm tra sâu hơn - và thường xuyên hơn - những trường hợp thử nghiệm mà không thể được thử nghiệm với tự động hóa. Ví dụ, một quá trình ứng dụng có thể yêu cầu sự can thiệp trực tiếp bằng tay chẳng hạn như xác nhận rằng các hóa đơn đã in là chính xác hay rằng một quá trình vật lý (như làm đầy bình xăng của xe) đã hoàn thành. Ngoài ra còn có các ứng dụng phần mềm có khả năng kháng tự động hóa.

Bây giờ bạn có thêm nguồn lực để tìm lỗi hay khiếm khuyết mà bình thường được tìm thấy bởi các khách hàng của bạn sau khi triển khai, khi chi phí để sửa chữa thiếu sót ứng dụng là cao nhất và thiệt hại cho sự hài lòng của khách hàng và hình ảnh thương hiệu của bạn là lớn nhất.

Bạn cũng có thể bắt kịp với lặp đi lặp lại được xây dựng như là kết quả của bất kỳ phần mềm cải tiến phương pháp phát triển liên tục được sử dụng, chẳng hạn như Agile, Kanban hoặc Scrum. Vấn đề là làm thế nào để lên kế hoạch phát triển ứng dụng với thời gian thử nghiệm luôn luôn thay đổi. Mục tiêu kiểm tra là quan trọng nhất: thực hiện lặp đi lặp lại và sẽ tốn khá nhiều thời gian để hoàn thành thời hạn cuối cùng là thời gian để thị trường một cách dễ dàng.

Sử dụng các Tool support nào ?

Rõ ràng câu trả lời đầu tiên là chọn một công cụ có thể tự động hoá các công nghệ cụ thể mà bạn đang thử nghiệm, nếu không tự động hóa của bạn sẽ bị thất bại. Thứ hai, bạn nên chọn một công cụ mà có một số đặc điểm sau:

  • Tool IDE là 1 tool rất dễ dàng cho các kỹ sư tự động hóa của bạn để viết bài kiểm tra, thực hiện thay đổi, tìm các vấn đề và có thể triển khai các thử nghiệm trên tất cả các môi trường mà bạn cần phải kiểm tra.
  • Một công cụ cũng được hỗ trợ bởi các nhà sản xuất và được support cho các trình duyệt web mới nhất, hệ điều hành và các công nghệ mà bạn sẽ cần phải kiểm tra trong tương lai.
  • Cách sử dụng đơn giản, một khi có những phần nhỏ phải thay đổi sẽ không cần phai thay đổi cấu trúc lớn.
  • Hỗ trợ cho các thử nghiệm dựa trên dữ liệu có sẵn và thống nhất có khả năng chạy hàng ngàn thử nghiệm cùng một lần với các bộ dữ liệu khác nhau. Cho dù các bạn chọn tool nào để sử dụng hãy đảm bảo rằng có thể cho chúng ta sử dụng ít nhất 30 ngày trên một dự án thực tế.

Thay đổi là tốt!

Các luận cứ để giải quyết những thách thức để tự động hóa trong kế hoạch thử nghiệm của bạn bằng cách sử dụng manual test như sau:

  • Các công cụ tự động hóa không thể thông minh như đội của bạn. Sử dụng manual test để đào sâu hơn vào khu vực bạn có thể không thường xuyên kiểm tra. Cung cấp một ứng dụng hiệu suất cao ổn định là cách tốt nhất để duy trì sự hài lòng của khách hàng và thị phần.
  • Các công cụ tự động hóa không thể đối phó với sự phức tạp của các ứng dụng . Nhưng tự động hóa có thể đối phó với các case lặp đi lặp lại của các ứng dụng, giải phóng nhóm thử nghiệm của mình để tập trung vào các vấn đề phức tạp, trong đó họ là những chuyên gia.

Thực hiện manual test bao nhiêu là hợp lý?

Đối với phần còn lại 70-80% các case sẽ cần phải thực hiện bằng tay, làm thế nào bạn có thể làm giảm thời gian cần để viết và thực hiện các xét nghiệm này? Cũng có một số tùy chọn mà có thể làm cho dễ dàng hơn này. Trước hết thay vì phải tự viết các trường hợp thử nghiệm trong MS-Excel hoặc MS-Word từng bước, bạn có thể sử dụng công nghệ và sức mạnh của tự động hóa để giúp bạn. Tất nhiên một công cụ sẽ không bao giờ viết một trường hợp thử nghiệm hoàn hảo, vì vậy bạn sẽ cần phải thực hiện một số chỉnh sửa và điều chỉnh, nhưng nó sẽ tiết kiệm được 95% thời gian thực hiện để viết một trường hợp thử nghiệm.

Không bao giờ là quá sớm để bắt đầu

Bạn đã thiết lập một mục tiêu và cố gắng để có thể đạt được, một mục tiêu với tác động đáng kể đến ứng dụng của bạn. Các bạn hãy thử thay đổi cách thức làm việc để có thể thấy lợi ích của nó. Khi áp dụng có thể không phải là 20% mà là 30% 40% các case được automation hóa tùy theo bài toán ma các bạn áp dụng.

Tham khảo: http://www.softwaretestingmagazine.com/knowledge/integrate-manual-and-automated-testing-in-a-test-plan/

0