Jacobvu84
commented
3 years ago Framework
Mục đích ra đời của nó là để mọi thứ trở nên dễ dàng và nhanh hơn. Nói 2 từ "dễ dàng" nhưng sau sự dễ dàng mà framework mang lại nó là cả một đống các design và các nguyên tắc. Mà đôi khi bản thân các nhân vật "cao cấp" trong công ty bạn chưa chắc đã làm được. Đừng nói tới trình độ của các Automation Tester. Nó là hoang đường nhưng các bản mô tả công việc cho vị trí này để yêu cầu có thể tự build được một automation from scratch. Tôi đoán là trong toàn bộ mã code mà bạn đang gọi là automation framework ấy ko có một interface. Toàn bộ là các class. Mà class nó là những biểu hiện cụ thể rồi thì làm sao mà có thể "biến hoá" linh động. Rồi càng ngày cái framework đó sẽ "béo ú" với các đoạn mã trùng nhau hoặc dư thừa ko dùng tới.
Trên tất cả là những ngươì mới vào ko thể reuse lại được. Họ phải học lại mọi thứ từ những gì đang có hiện tại. Hoặc là "đập bỏ" để thay thế bằng mớ lộn xộn "quen thuộc" khác mà họ đã từng làm trước đó. Chi phí mà bạn đã bỏ ra trước đây gần như bay theo gió và cứ mỗi lần thay một nhân sự mới là một làn gió bay qua cuốn theo tiền của công ty bạn.
Ngay cả trường hợp lý tưởng, công ty bạn có thể xây dựng một framework bởi một đội dev tài năng thì vấn đề maintain, viết tài liệu và training. Tiền ở đâu để đầu tư (1) ? Không lẽ bất cứ một dịch vụ nào công ty bạn đều bỏ tiền để đầu tư luôn từ A-Z.
Bên cạnh việc công ty bạn đang phát triển sản phẩm chính thì bạn muốn công ty bạn phát triển luôn cả một sản phẩm phụ, Nó có đáng để đầu tư.
Bạn chỉ nên làm nó khi để giải quyết một vấn đề gì đó quá đặc biệt mà ko thể tìm thấy ở đâu đã từng giải quyết nó hoặc các công cụ hiện có không đủ tốt để cho bạn có thể thực hiện được điều bạn muốn.
Và ngay cả khi công ty bạn toàn những dev kỳ cựu, tài năng xuất chúng. Thì hãy quay lại vấn đề (1). Có thể tốn nhiều chi phí hơn để duy trì, đào tạo, lập tài liệu, hơn là sử dụng các tùy chọn ưa thích, sẵn có trên thị trường.
Quay về mặt đất với những automation tester hiện có trong công ty bạn. Tôi cá là nhiều trong số họ không biết đến ý nghĩa của design pattern và framework chứ ko nói tới họ có thể nghiên cứu thị trường và lựa chọn một giải pháp phù hợp.
truyenkv
Một vấn đề không khó để nhận thấy bởi kinh nghiệm dạy học và kinh nghiệm thực tế làm việc trong quá khứ cũng như hiện tại.
Có thể rất nhiều lý do dẫn tới điều này nhưng lý do chính yếu nhất là kỹ năng lập trình dưới mức cơ bản + kinh nghiệm coding chưa đủ nhiều.
Nếu chỉ nhìn họ "demo" công việc thì rõ ràng tất cả "người xem" đều thấy nó hoạt động nhưng
Trên thực tế automation test là áp dụng công nghệ cho nhiều mục đích như cung cấp các phản hồi nhanh cho toàn đội hay hơn nữa có thể là để test hồi quy ( Phần lớn là các công ty theo hướng này)... nhưng cho dù để theo đuổi mục đích gì thì đã áp dụng công nghệ thì giải pháp mới là quan trọng. Viết viết code chỉ là bước cuối cùng, là bản kế hoạch chi tiết. Bạn không dùng thư viện này thì dùng thư viện khác, không dùng framework này thì dùng framework khác. Ko phải lúc nào cũng Selenium cho web và Appium cho mobile. Nó cũng chỉ như bao thư viện lập trình khác...
Tham gia một vài khoá học ngắn ngày với nội dung rất "phong phú" và "đầy đủ" nhưng chỉ bao gồm các bài học luôn được "chuẩn bị" từ trước với những bối cảnh, trường hợp cụ thể + với nội dung khá là cơ bản nên đương nhiên nó rất "lý tưởng". Không có người hướng dẫn theo dõi khi tham gia làm việc thực tế. Vì thực tế ở mỗi công ty, mỗi dự án là khác nhau. Dẫn tới việc mọi thứ chỉ tuyệt vời trên "báo cáo".
Có rất nhiều lý do để họ chạy theo "báo cáo". Vì thành tích, vì muốn đảm bảo một công việc, vì tiếng tăm và sỹ diện, vì khoe khoang sự hiểu biết.... họ đã biến mình thành "nô lệ" cho automation test. Cố gắng làm sao để luôn có kết quả 100% passed trên các báo cáo test.
Testing thuộc loại non-tech. Nhưng automation-test thì không phải là non-tech chút nào. Nhưng nó vẫn thuộc Testing nên việc quản lý dành cho người non-tech ( thường là QA Lead, QA Manager) + Người làm ( automation Tester) cũng non-tech. Khiến cho mọi cái ko ai có thể kiểm soát được, thôi thì miễn làm sao để nó có thể chạy được và ra kết quả. Việc review code để học và nâng cao trình độ gần như ko bao giờ xảy ra. Vì mỗi đội có 1-2 người same same level với nhau. Lead thì cũng chỉ "động viên" tinh thần. Nên việc dùng automation trong testing, có cũng như không.
IT là phải tốc độ, phải "nước rút" nhưng với automation mà nói kể cả nước có rút đi rút lại mấy lần thì chưa chắc các kịch bản automation đã stable. Luôn luôn chạy theo sau mà sau dài dài. Thế là mục đích để tiết kiệm, thời gian và nhân lực trở thành gánh nặng cho toàn đội.