Cucumber cho UI Testing Automation
Trong Agile mục đích của việc chia toàn bộ quá trình thành iterations nhỏ là để nhận được phản hồi nhanh và tự động hóa là cách để lấy được feedback nhanh nhất. Nên giá trị thực sự mà tự động hóa mang lại nằm trong giai đoạn phát triển của Dev, người ta gọi là Developer Testing nhưng có điều đáng buồn là các công ty không có ai triển khai nổi được cái này nên vẫn theo cách làm cũ. Tất cả xong rồi mới Test. I Test chứ không phải là I have test.
Việc triển khai test trong quá trình phát triển của Dev có thể cover tới hơn 80% hoặc 90% hoặc 100% các lỗi có thể tìm ra như Apple chẳng hạn. Họ hoàn toàn không có đội test chuyên biệt. Vấn đề chất lượng là bài toán chung chứ không phải riêng của một đội nào cả và chỉ có ai làm ra cái gì mới có đủ khả năng đảm bảo được chất lượng của cái đó.
Chất lượng trải dài cả 3 giai đoạn
- Giai đoạn đầu vào là yêu cầu: Cũng phải phân tích nghiệp vụ xem đúng,sai, thừa, thiếu… và họ sẽ dùng User Story để giải quyết vấn đề này. Nếu họ không có khả năng phân tích và viết được cái US cũng như không trình bày một cách rõ ràng các mong muốn của khách hàng thông qua các Acceptance Criteria thì có thể toàn bộ công sức phía sau sẽ phải trả một cái giá đắt. Giả sử rằng chúng ta đã có được bộ AC tốt và giai đoạn thứ 2 đó là quá trình “sản xuất”.
- Giai đoạn phát triển là việc coding: Có Unit Testing… nên dùng TDD ( đây chính là tự động hóa trong giai đoạn sản xuất, Developer Testing. Mọi thứ được test liên tục và fix lỗi trước khi sản phẩm được build và release đến tay người dùng.
- Giai đoạn đầu ra đến tay người dùng: Chạy thử nghiệm người dùng ( Nếu làm giai đoạn 2 tốt thì không cần đội test như đã nói ở trên mà Apple hoặc Facebook là những ví dụ điển hình). Đó có thể tạo ra bản Alpha hoặc Beta Test. Họ có những hệ thống để track được luôn lỗi xảy ra trong quá trình người dùng tương tác với sản phẩm như Sentry, Firebase….
Trên thực tế diễn ra ở nước ta, vấn đề chất lượng được đặt lên vai người gác cổng QA/QC/Tester…. và chúng ta sẽ chấp nhận thực tế này. Ngay cả việc tự động hóa cũng được đẩy sang giai đoạn này và một loạt các công cụ hỗ trợ tự động hóa UI được phát triển.
Vấn đề xảy ra ở chỗ là họ lại dùng các công cụ automation của các giai đoạn 1 và 2 ( giai đoạn phân tích nghiệp vụ và giai đoạn Developer Testing) như Cucumber là ví dụ.
Cucumber có 2 phần chính là phần sử dụng:
- Ngôn ngữ Gherkins viết trên feature file để define các acceptance criteria ( phần này mục đích chính là để share understanding với mọi người trong team trước khi đi vào sản xuất
- CLI: phần này giúp cho đội Dev có thể thực thi feature (EXECUTABLE SPECIFICATIONS) nhằm mapping các nội dung được trình bày trên feature file với các đoạn code thực thi của chương trình.
Trong phần thứ 2 họ sẽ không viết code app một cách trực tiếp luôn và ngay mà sẽ viết code “ảo” với TDD, sau khi pass xong các Test họ mới refactor code để ra được real code cho application.
Đây là 3 bước cơ bản
Có thể là sẽ nhiều hơn.
Illustrate:
Các US sẽ có các example. Examples is heart of User Story. Nó là cái để chứng minh sự đúng đắn trong các giả định của câu chuyện người dùng. Giai đoạn này Dev sẽ viết code “ảo” để pass được cái test (yêu cầu). Sau khi pass xong thì sẽ chuyển qua bước tìm kiếm công thức cho vấn đề.
Formulate:
Công thức là cái để xác định được vấn đề tổng quan cả bài toán. Nó chính là Rule.
Ví dụ:
- 1+2=3,
- 1+2+3=6
- 1+2+3+4=10 Đây là các example.
Chúng ta sẽ tìm ra được rule là total = n(n+1)/2.
Sau khi tìm được rule họ sẽ clean up the code by refactoring code, chỉnh sửa code để nó thành SOLID và các principles khác. Đây chính là quá trình viết Unit Test.
Nếu nếu ai đó nghĩ:
- QA/ QC có thể làm được unit test ngay cả khi họ có kỹ năng của developer.
- Unit Test là Dev tự viết các kiểm tra cho code của họ. Có ý là sau khi Code app viết xong thì viết các bài kiểm tra test ở mức unit, từng method, từng class, từng module….
- Vừa viết code vừa nghĩ đến việc refactor
Thì chắc chắn một điều họ chẳng hiểu gì về Unit Test hoặc Refactor code cả. Mục đích của Unit Test không phải để Test, Nó chỉ là phản ứng phụ, một lợi ích có thêm.
Unit Test là hướng tới sự phát triển phần mềm một cách bền vững
What is the goal of unit testing, then? The goal is to enable sustainable growth of the software project. The term sustainable is key. It’s quite easy to grow a project, especially when you start from scratch. It’s much harder to sustain this growth over time.
Automate: … chẳng biết viết gì ở đây
Bạn thấy đó mọi thứ nhìn có vẻ liên quan đến Test nhưng thực tế nó không có liên quan như cách chúng ta tưởng.
Cucumber là collaboration tool ở mức nghiệp vụ. Còn phần CLI nó chạy qua TDD rồi.
Nên bạn sẽ nhìn thấy hình ảnh này
Bạn có nhìn thấy cái gì liên quan tới UI ở đây không ?
Trong khi Selenium hay Appium là các công cụ automation dựa trên ý tưởng tác với UI.
Khi nào mới có UI để mà tự động hóa, chỉ khi sản phẩm đã qua giai đoạn deployment.
Hỏi ngược lại là Cucumber có phục vụ cho việc kiểm tra các tính năng khi sản phẩm hoàn thành hay không ?
Hậu quả của việc sử dụng wrong tool sẽ khiến cho mọi cái trở nên phức tạp, thừa thãi và tốn nhiều công sức, kết quả là bằng 0 mà CỨ CỐ…. chăm chỉ thì nó thành phá hoại mà ko biết.
Lùi ra, không thấy bận à
Nếu bạn không tin tôi, nghĩ rằng tôi đang tự tưởng tượng ra những điều này thì ít nhất bạn cũng nên tin vào Aslak Hellesøy, một trong những người phát triển cucumber
“They write Cucumber scenarios after the software instead of the other way around. Doing BDD well leads to decoupled software, which again makes it easy to reduce the duration of tests. You DON’T get any of these BENEFITS WHEN you TREAT CUCUMBER as an afterthought.”
BDD is difficult. It requires collaboration, which is difficult in siloed organisations. It requires developers who understand TDD and decoupling techniques, which requires training and experience. IT REQUIRES TESTER WHO UNDERSTAND THAT TEST-AFTER HAS NOTHING TO DO WITH BDD. The best way developers and testers can contribute to the BDD process is to get involved in requirements specification (Discovery) and resist the urge to write UI-centric, slow, unreadable Cucumber tests.
