Chuyện Nghề: Một Dự Án Nọ (2)

Hôm nay, mình kể mọi người về dự án cuối cùng mà mình tham gia, trước khi nghỉ Grab. Đó là E2E testing. Sorry mọi người, mình quên mất các mốc thời gian cụ thể, nên giờ nhớ gì kể nấy.

Mục tiêu của dự án là làm thế nào để cắt giảm thời gian regression tests của QA. Mình giải thích sơ về quy trình phần mềm cho mọi người cùng hiểu rõ. Ở Grab, mỗi tuần sẽ release Driver app một lần. Ở mỗi lần release, QA có thời gian là 3 ngày (quy ra thành 24h làm việc) để test app. Test ở đây là test thủ công theo những kịch bản test đã được thiết kế.

Ở thời điểm đó, thời gian test thực tế trung bình tầm khoảng 12h. Câu hỏi là làm thế nào để giảm thời gian test này xuống? Đây là động lực cho ra đời dự án E2E testing.

Mình sẽ có một bài viết kỹ thuật khác nói về E2E testing. Trong bài viết này, mình sẽ tập trung vào những khía cạnh về con người và quy trình của dự án.

Trước khi mình tiếp quản, dự án này cũng được sang tay qua 1-2 người. Nhưng cách tiếp cận trước đó có rất nhiều bất cập. Cho nên khi bắt tay vào làm thì, như mọi người có thể đoán được, mình đã đập hết xây lại từ đầu 😅, theo cách tiếp cận khác. Và dĩ nhiên mình đã làm 1 cái POC (proof of concept), chứng tỏ tính khả thi của giải pháp, để thuyết phục các bên liên quan.

Manual QA vs. automation QA, hay vấn đề về sự cam kết

Có một điểm mình thấy khá khập khiểng khi chạy dự án, đó là ownership. Trên danh nghĩa, dự án này gọi là “driven by QA, supported by dev”.

Thật ra, hết 80% khối lượng công việc là do dev làm rồi. Về mặt trách nhiệm, team dev phụ trách cung cấp giải pháp, set up phần core. Còn QA là người viết tests và bảo trì những tests đó. Nhưng trên thật tế thì không phải vậy…

Để mị kể cho mà nghe…

Đúng ra team QA phụ trách E2E testing phải là những người có background về automation. Nhưng team QA này đều là manual tester và không có background về automation. Vì vậy, ngoài việc thiết kế giải pháp, viết nhiều tests giùm, mình còn làm một việc ngoài lề khác là train cho QA về automation.

Các bạn cứ hình dung mình là thầy cô ở đại học, dạy cho tân sinh viên môn “lập trình với Python” khi các bạn này chưa học qua các môn tiên quyết như “nhập môn lập trình”. Có rất nhiều lỗ hổng mà chỉ có bản thân họ tự thân nỗ lực mới có thể vá lại được. Tháng đó mình cứ phải zoom meeting để hỗ trợ QA khi có issue mà không biết cách giải quyết.

Có một điều khác khiến mình mệt mỏi là khi QA hỏi những câu hỏi cơ bản về git, chẳng hạn như:

Để sync với remote thì chạy git pull đúng hok?

Đối với những câu hỏi về git như thế này thì câu trả lời luôn là “it depends”. Còn tuỳ thuộc vào branch bạn đang làm việc là branch nào, có clean hay không nữa. Vì đã từng trải qua cảm giác lúng túng với git hay svn (đọc thêm ở post nọ) nên mình rất thông cảm cho các bạn. Do đó, mình hay nhấn mạnh là git rất quan trọng, nên kiếm 1 cái crash course nào đó học cho nó bài bản, không thì thấy nó rất đáng sợ và chắc chắn sẽ đau khổ vì nó. Mình còn kiếm link gửi cho các bạn. Nhưng chao ôi, lời nói của một thằng dev quèn nặng được bao nhiêu kí lô?!

Ban đầu mình có chuẩn bị tinh thần trước và cam kết sẽ đồng hành cùng QA trong việc onboard cho các bạn ấy. Nhưng đôi lúc mình cũng thấy lung lay thật sự. Cảm giác thất vọng không phải từ việc các bạn không có tiến bộ như kỳ vọng, mà từ việc không có cam kết, nỗ lực như mong đợi.

Lúc bấy giờ, công ty mình không còn tuyển manual QA nữa với định hướng chuyển dịch sang automation. Và phần đông QA tham gia dự án này đều còn rất xa so với vai trò automation QA. Mình không thể move fast được trong khi đồng đội của mình lại move (fricking) slow. Trong nhiều lần sync-up, mình rất hay đánh tiếng là “mấy bạn có viết thêm test nữa hok mà dạo nào không thấy có update gì vậy?” để nhắc nhở. Một số thì kêu đang bận dự án nọ nên tuần này chỉ có thể dành ra khoảng x% capacity cho E2E testing thôi. Vấn đề về cam kết (commitment), mình than hoài với sếp, nhờ sếp tác động lên QA để có tiến độ phù hợp. Và bạn biết không, việc theo dõi, đốc thúc tiến độ như thế này vốn dĩ là trách nhiệm của EO (engineering owner) chứ không phải mình.

Staging testing vs. production testing

Có một vấn đề nổi cộm trong các cuộc thảo luận đôi bên giữa dev và QA là production testing. QA thì luôn muốn thúc đẩy production testing, còn dev - tức là mình - luôn muốn gác production testing qua một bên và tập trung vào staging testing.

Nói sơ về các bước chạy cơ bản của một test trong dự án:

Với một test cơ bản, khi chạy, hệ thống sẽ tạo resources tương ứng gồm bao nhiêu tài xế, bao nhiêu hành khách. Rồi tiến hành đăng nhập cho tài xế và hành khách này. Test nào liên quan tới booking thì test chạy giả lập việc hành khách đặt booking. Tài xế nhận được booking, rồi hoàn thành cuốc.

Ở môi trường staging, mọi thứ đều rất đơn giản. Mọi sai sót, nếu có, đều không phải là vấn đề lớn. Nhưng khi chạy trên production, bức tranh trở nên khác hẳn. Câu hỏi lúc này không phải là “How to make it work?” mà là:

How to make it work safely?

Như vậy, nếu nỗ lực để chạy được một test trên staging là x thì nỗ lực cần thiết chạy được nó trên production phải cỡ 20x. Vì vậy, mình luôn nêu rõ quan điểm “đây chưa phải là thời điểm chín muồi cho production testing”. Thay vào đó, hãy dành nỗ lực để tối đa hoá kết quả từ staging testing. Và mình thấy rất mệt khi mấy buổi họp cứ đem chủ đề này ra bàn lại.

Một phần lý do khác khiến mình cho rằng đầu tư vào production testing ở thời điểm đó là không hợp lý, chính là QA chưa đủ giỏi để sử dụng giải pháp một cách có trách nhiệm. Như đã đề cập, test bất cứ thứ gì trên production đều phải thận trọng. Giả sử khi giả lập việc hành khách đặt cuốc xe, hệ thống gán cuốc xe này cho tài xế thiệt thì sẽ như thế nào? Một nguyên tắc tiên quyết của mình là, khi giới thiệu một giải pháp để cải thiện vấn đề, ít nhất không được làm mọi thứ tệ thêm. Cho dù dùng nhiều biện pháp phòng ngừa, sai sót vẫn không thể tránh khỏi. Và giải pháp đưa ra cần phải nêu rõ một cách thuyết phục rằng có những sai sót nào xảy ra, phương án giải quyết như thế nào… Với tiềm lực mỏng manh của team ở thời điểm bấy giờ, việc đầu tư vào production testing là quá xa xỉ, chẳng khác nào lấy trứng chọi đá.

Về production testing, mình với sếp không cùng quan điểm cho lắm. Mình thì không muốn nỗ lực trở nên vô ích, còn sếp mình thì muốn thử hướng này. Lần cuối trước khi mình rời Grab, người tiếp quản dự án này tự mình sẽ lo luôn phần production testing. Không biết bây giờ ra sao rồi 😅!? Nói nghe hơi mất dạy chớ đôi lúc mình cũng muốn hát câu này trong bài “Sáng Mắt Chưa” của Trúc Nhân:

Phí quá chời luôn á!
Hình như anh cần vitamin A để cho mình sáng mắt ra.

(Mấy anh ơi, nếu có đọc tới đây, em hy vọng mấy anh cười chứ đừng có nổi đoá với em 😂)

…

p/s: Đánh giá một cách công tâm thì đây là một dự án thú vị, tạo ra impacts lớn.