Automation Tech Lead Cybozu: "Automation Testing sẽ là kỹ năng bắt buộc trong tuyển dụng dù là Tester hay QA!"

Tốt nghiệp đại học Tự Nhiên về mảng Trí tuệ Nhân tạo, kinh qua nhiều vai trò khác nhau và phụ trách Automation tech lead dự án Garoon Automation, anh Viễn Trần hiện đang là Full-stack Developer tại Cybozu Việt Nam, đồng thời cũng đảm nhận vị trí Tech Lead dự án BICO Pass trên nền tảng .Net Core và Angular.

Trong mục “Chuyên gia nói” tuần này, hãy cùng TopDev tìm hiểu để đạt được thành tựu như ngày hôm nay, hành trình học hỏi và cơ duyên giữa anh Viễn và ngành Automation Test.

Full-Stack Developer – Trưởng thành từ chính gian nan

* Anh hãy chia sẻ một chút về bản thân và con đường sự nghiệp của mình?

Tôi tốt nghiệp đại học Khoa học Tự nhiên, ở phòng thí nghiệm nhân tạo và có 1 dự án về thương mại điện tử, rất tiếc dự án này chưa thành công. Vì vậy tôi quyết định đầu quân cho Cybozu Việt Nam, đến nay đã được hơn 8 năm rồi. Trong suốt khoảng thời gian này, tôi đã trải qua nhiều vị trí và vai trò khác nhau và học hỏi rất nhiều từ đồng nghiệp của mình. Gần đây tôi cũng tích cực tham gia và chia sẻ một số kiến thức và hiểu biết với cộng đồng thông qua cách tech events, nếu các bạn có tham dự các sự kiện do TopDev tổ chức thì có thể sẽ biết đến tôi.

* Lựa chọn trở thành Full-stack Developer có ảnh hưởng tích cực như thế nào đến sự nghiệp của anh?

Tôi có một ví dụ khá đời thường để bạn có thể hiểu rõ hơn. Ví dụ như bạn đi từ nhà đến công ty, bạn chỉ biết một con đường, dù trời nắng trời mưa hay kẹt xe, hoặc ở trạng thái cảm xúc như thế nào cũng chỉ đi con đường đó. Ví dụ này giúp ta liên tưởng đến Full-stack Developer. Full-stack Developer là cơ hội giúp cho mọi người có những hiểu biết khác nhau ở những vai trò khác nhau, từ đó các bạn có thể đưa ra những giải pháp, những công nghệ phù hợp với một bài toán cụ thể mà công ty hay project của mình đang gặp phải. Tôi nghĩ rằng Full-stack Developer là cơ hội giúp cho Developer hoàn thiện bản thân mình hơn.

Về cơ bản, Full-stack Developer khá là rộng nên về khó khăn nói chung thì mình có thể nói như sau:

Khó khăn thứ nhất là người làm Full-stack Developer phải làm việc với những task khác nhau như server-side, client-side và những task liên quan đến network, do đó chúng ta phải research và nâng cấp bản thân mình liên tục. Thứ hai, chúng ta phải làm việc ở nhiều bộ phận khác nhau. Chúng ta phải hiểu được văn hóa và phong cách của từng bộ phận để làm việc hiệu quả. Đó là 2 khó khăn lớn nhất đối với Full-stack Developer.

Chia sẻ kỹ hơn về khó khăn thứ hai, đó là kỹ năng cần có của một Full-stack Developer. Kỹ năng đầu tiên là research một cách độc lập, cái thứ hai là chịu được áp lực, và thứ 3 là kỹ năng giải quyết vấn đề và cuối cùng là kỹ năng trình bày. Full-stack Developer giúp cho họ làm việc với nhiều vai trò, nhiều bộ phận khác nhau để từ đó có thể học hỏi và trưởng thành hơn từ các đàn anh đi trước. Giúp họ nâng cao kỹ năng trình bày và thuyết phục, kỹ năng trao đổi và kỹ năng làm việc cộng tác. Khi đi theo hướng Full-stack cũng giúp họ tìm ra lĩnh vực để nghiên cứu chuyên sâu về nó, từ đó họ trở có thể trở thành chuyên gia, PM hay giám đốc kỹ thuật có tâm và có tầm hơn.

* Vậy theo anh Full-stack Developer sẽ có những thuận lợi nào so với các vị trí khác?

Full-stack có con đường tìm việc rất rộng mở, vì họ có thể làm nhiều vai trò khác nhau trong một team. Thời gian gần đây lập trình có sự thay đổi theo dạng DevOps, hay là mô hình Scrum. Từ đó vai trò của một người trong team không chỉ là viết code, cũng không chỉ là người đi giải quyết vấn đề hay fix bug.

* Với vai trò là người đi trước, anh có lời khuyên nào dành cho các bạn hiện tại đang là Junior Developer?

Tôi sẽ chia sẻ một ý thế này, khi bác sĩ chữa trị cho bệnh nhân, một phác đồ chỉ điều trị cho một người hay một vài người nào đó thôi. Nhưng nếu cố gắng để nêu quan điểm cá nhân thì các bạn nên:

• Học một ngôn ngữ lập trình thật chuyên sâu để nắm nguyên lý căn cơ trước khi bay cao, sang frameworks hoặc một tech nào khác.
• Sử dụng và khai thác một công nghệ, framework tối đa để học hỏi và trải nghiệm cách giải quyết vấn đề từ framework mang lại. Theo tôi các frameworks tổ chức nghiệp vụ và source-code rất tốt, do đó chúng ta sẽ học được thật nhiều.
• Chủ động không ngại khó làm các công việc trong team. Có trách nhiệm đặt câu hỏi trong đội nhóm hoặc cho mọi người (đôi khi thật khó ở một vài môi trường kém thân thiện). Khi gia nhập team phải chủ động để nhận task hay trao đổi để học hỏi kỹ năng từ nhiều người, từ đó rút ngắn con đường để trở thành một Full-stack thực chất.

* Như anh chia sẻ, Full-stack Developer cần chọn một ngôn ngữ để phát triển lên, anh có thể chia sẻ nguồn tài liệu mà anh thấy bổ ích?

Trong công ty tôi cũng có một số bạn hay hỏi, Em nên học ngôn ngữ gì? hay Nguồn tài liệu ở đâu? Quan điểm của tôi thì để học một server-side language (ví dụ như PHP), thì chúng ta nên vào trang gốc của nó, hay mình học selenium, về automation testing thì mình cũng follow chính trang gốc, documentation từ chính những trang này, chọn ra những best practice thì sẽ hay hơn đọc những trang trung gian. Sau đó mình có thể chọn những trang khác như W3School...

Bên cạnh đó, tôi thường xem tạp chí online để cập nhật công nghệ và xu thế chuyên ngành công nghệ thông tin.

Còn hai cuốn sách liên quan tới chuyên ngành mà tôi thường hay sử dụng hoặc đọc lại mỗi lần trước khi bắt đầu thiết kế project mới hay module quan trọng hay là tái cấu trúc một dự án cũ là: The Art of Readable Code và Code Complete của McConnell.

End-to-end testing system và những kinh nghiệm xương máu

* Được biết hiện nay anh đang triển khai hệ thống E2E system. Anh có thể chia sẻ thêm về hệ thống này không?

Tôi cũng đã từng chia sẻ về hệ thống End-to-End đang được triển khai tại Cybozu Việt nam tại một số sự kiện kỹ thuật. Trước đây nó được xây dựng trên nền tảng PHP Selenium, điều này dẫn đến khá nhiều khó khăn đối với những bạn là QA hay những bạn vừa gia nhập Automation Testing. Tôi nghĩ hệ thống hiện tại được triển khai giải quyết 2 vấn đề chính mà người build hệ thống tự động hóa cần lưu tâm: build hệ thống tự động hóa cho tất cả mọi người có thể sử dụng được (không phân biệt QA hay developer), thứ 2 là có thể mở rộng liên tục được, mình có thể phát triển thêm loại test. Tôi nghĩ hiện tại hệ thống hiện tại giải quyết rất tốt điều này.

Còn về cơ duyên đưa tôi đến với Testing, thực ra tôi từng làm việc ở nhiều nơi khác nhau và nhiều vai trò khác nhau và nhận thấy Developer Full-stack cần có kỹ năng test tự động hóa và hơn nữa phải build một hệ thống tự động. Từ đó tôi bắt tay vào hoàn thiện kỹ năng này.

• Một sản phẩm lớn và thành công thường được xây dựng qua nhiều năm, nhiều tính năng, và nhiều thành viên vào nhóm và ra đi. Do đó cần phải test và phải đảm bảo luôn đúng ở mọi thời điểm. Và đặt biệt là sản phẩm đó không được suy yếu trong quá trình maintain và thêm mới tính năng. Do đó lập trình viên dù giỏi cỡ nào cũng dễ mắc phải và tôi muốn mình làm chủ về công nghệ testing để có thể yên tâm vươn cao bay xa và tha hồ thử nghiệm công nghệ mới trên project hiện tại.
• Việc build hệ thống tự động hóa rất đơn giản nhưng để trở nên scable và bất kỳ ai cũng có thể làm việc thì không hề đơn giản. Do đó tôi thấy hơn ai hết, Full-stack Developer nên build hệ thống trước rồi QA, và developer cùng mở rộng bộ test-case tự động dễ dàng nhất.
• Việc build hệ thống tự động hóa cũng đòi hỏi rất nhiều kỹ năng bao gồm: tầng hệ thống, giao thức mạng và kiến trúc phần mềm, CI/CD…

Nên tôi thường hay có một câu nói với các bạn khi đề cập tới testing mindset là: Testing code is real code.

* Anh có thể chia sẻ thêm khi nào mình nên dùng End-to-End testing và khi nào cần dùng Functional testing? Đặc điểm và ưu nhược điểm của từng loại?

Tôi sẽ trả lời qua ba ý như sau:

• Manual Test dùng sức người - Automation testing dùng máy tính: đây là sự khác nhau rất cơ bản. Do đó hệ thống test tự động sẽ không bị chi phối bởi cảm tính con người. Tôi mệt, thì tôi có thể test sai nhưng automation test không bị chi phối bởi yếu tố này, về cơ bản tự động hóa dùng sức máy và tránh lỗi của con người.
• Tự động hóa có thể chạy song song: tại một thời điểm có thể chạy nhiều test case để giảm thời gian test xuống. Còn nếu về manual thì hầu như không làm được việc này. Tôi lấy ví dụ, giả sử chúng ta có 1000 test case thuộc bộ regression test, nếu dùng manual thì chúng ta tốn 10 ngày, nếu dùng tự động chạy dưới chế độ song song thì chúng ta mất 1 giờ. Ví dụ này cũng đưa ra sự khác nhau khá rõ ràng.
• Đây là điều thú vị mà QA làm manual rất muốn biết: tự động hóa sẽ không phát hiện được bug mà manual phát hiện được. Ví dụ như một ngày đẹp trời trang login có UI bị vỡ, nhưng vẫn còn username và password để nhập. Về cơ bản manual sẽ phát hiện UI đang bị lỗi nhưng tự động hóa thì không. Đây là yếu tố khá là quan trọng mà người làm manual tự tin mình vẫn còn giá trị trong công việc.

Tự động hóa cho dù đạt được mức độ nào thì vẫn không thể thay thế được manual test.

* Trong quá trình làm việc ở mảng System Testing, anh có kỷ niệm vui nào có thể chia sẻ?

Gần đây nhất thì tôi có giải quyết được 1 cái bug làm cho chương trình test không ổn định. Bên Nhật có nhờ tìm hiểu nguyên nhân và tôi đã giải quyết được cái bug này trong vòng 1 buổi sáng, mà tôi đã dự định phải mất 3 ngày. Tôi thấy khá vui khi giải quyết được bug từ hệ thống được xây dựng bên Tokyo.

Còn kỷ niệm buồn mà tôi nhớ nhất là, sau khi đội tự động hóa ở Việt Nam đã chọn kỹ thuật PHP Selenium, Facebook Webdriver để build hệ thống tự động, mọi người rất vất vả, sau một năm thì build hệ thống thành công, Nhưng vào một ngày không xa sau đó, đội automation testing bên Nhật đã họp bàn và chốt lại là kỹ thuật đó pending và không làm nữa. Từ đó chuyển toàn bộ sang kỹ thuật mới, kỹ thuật mới này được ứng dụng tới bây giờ.

Như tôi chia sẻ, mình phải giải quyết được 2 yêu cầu: một là mọi người đều viết được và maintain được hệ thống đó, thứ 2 nữa là có thể mở rộng liên tục. Ngoài ra, một lý do cho câu chuyện chuyển sang kỹ thuật mới đó là: mình phải cập nhật xu hướng công nghệ. Công nghệ PHP Selenium đã ra đời cách đây hơn chục năm, còn Web Driver Node thì có khoảng 4 năm, và tôi nghĩ nó sẽ bùng nổ trong những năm tiếp theo, đặc biệt ở thị trường automation testing thì dù muốn hay không, đã là xu thế thì mình phải cập nhật thôi.

* Quan điểm của anh về xu hướng phát triển của ngành Testing trong hiện tại và tương lai?

Thực ra để có câu trả lời chính xác thì chúng ta nên dựa trên số liệu hay những công bố, tuy nhiên để trả lời câu hỏi này thì tôi nghĩ là đối với tương lai, một bạn làm Tester hay lĩnh vực QA dù muốn hay không, cũng nên trang bị những kỹ năng automation testing. Dù không đam mê đến mức build một hệ thống automation testing hoàn chỉnh, bạn cũng có thể maintain mở rộng hệ thống của công ty, tổ chức mà bạn đang hoặc sẽ tham gia trong tương lai. Thứ 2, đối với người tuyển dụng, yêu cầu về automation testing bây giờ là optional, nhưng tương lai nó sẽ là một requirement (bắt buộc). Từ 2 nhận định này, trong tương lai thị trường về automation testing hầu như chiếm xu thế, và những doanh nghiệp đang có sản phẩm CNTT là chủ lực, họ sẽ chuyển dần từ manual sang automation.

* Anh hãy chia sẻ về công việc hàng ngày của anh cũng như team tại Cybozu nhé?

Công ty tôi, đặc biệt là team tôi thì chủ động phần lớn các công việc, từ lý tưởng chung của công ty đến lý tưởng của team thì mọi người tự động nhận task team đã tạo ra trước đó. Công việc của tôi thường ngày xoay quanh những task như: training bạn mới đội Cybozu dev ở Việt Nam, và team Nhật nếu có yêu cầu, thứ hai là support team khác viết những tự động hóa, thứ 3 là cùng mọi người trong team viết những test case mà trước đây dùng manual, điều quan trọng nhất đối với tôi là improve hệ thống hiện tại.

Nếu bạn nào làm ở lĩnh vực CNTT thì cũng biết là, khi xây dựng hệ thống, sẽ không có gì đúng mãi mãi, nên mình sẽ improve dần dần, bằng cách viết test case mới cho nó phù hợp hơn. Điều cuối cùng, cũng như là điều tôi luôn làm hàng ngày, đó là research công nghệ mới. Nếu trước đây tôi quan điểm tự động hóa là lĩnh vực khá là nhỏ, nhưng khi bước chân vào tự động hóa được 4 năm, tôi lại thấy rất rộng, và có nhiều thứ để học hỏi.

Về công việc của tôi thì có thể kể đến như sau:

1. Training automation testing cho đội Dev (hiện tại cũng đã vừa xong).
2. Build Automation system cùng với đội Automation.
3. Viết tự động hóa cho những test-case đang test bằng manual, viết lại tự động hóa cho những test code đã viết bằng công nghệ cũ là Java sang nền tảng mới.
4. Viết tài liệu của hệ thống tự động.
5. Tech solutions cho các bạn trong team (hoặc ai đó cần).
6. Research những kỹ thuật công nghệ để có thể nâng cao hiệu suất của tự động hóa (docker, circleci, scable, headless, isolation design pattern...).
7. Review source-code của Developer viết để đảm bảo source code có tính đồng nhất và chặt chẽ.
8. Speaker về tự động hóa cho những nơi cần nó.

Bài toán cung - cầu nhân lực IT và lời khuyên từ chính người trong nghề

* Hiện tại có vài doanh nghiệp gặp khó khăn trong việc tuyển dụng. Team của anh có gặp khó khăn trong vấn đề này không?

Tôi cũng thuộc bộ phận tuyển dụng 5 năm, nên có thể chia sẻ trải nghiệm của mình như sau. Về cơ bản tôi thấy công ty mình cũng gặp khó khăn trong tuyển dụng, và có thể nêu 3 góc độ nhìn.

Góc độ đầu tiên, người tuyển dụng, tôi thấy một số bạn thường trang bị những kỹ năng khá khô cứng. Họ chỉ biết những gì họ làm, chứ không research thêm tổng thể để biết được những thứ cốt lõi, khi đưa ra tình huống và bài toán khác, thì họ không trả lời hay giải quyết được. Tôi cũng có lời khuyên với các bạn, trước khi làm được ứng dụng hoàn hảo thì mình hãy trang bị cho mình những kiến thức mang tính chất buộc bạn phải biết khi bước chân vào ngành lập trình.

Khó khăn thứ 2 đứng dưới góc độ một doanh nghiệp, tôi thấy hiện giờ ở Việt Nam có rất nhiều doanh nghiệp ngoại đổ bộ vào nên việc cạnh tranh về nguồn nhân lực chất lượng cao là hiển nhiên. Điều cuối cùng, các doanh nghiệp nên có chính sách hay văn hóa phù hợp hơn với xu thế của các bạn trẻ. Các bạn trẻ cần sự năng động, chính sách nên phù hợp để làm sao các bạn thấy thoải mái để làm việc và giới thiệu cho bạn bè khác, cũng như có chính sách lương và benefits sao cho phù hợp, điều này cũng phần nào cải thiện tình hình tuyển dụng của doanh nghiệp.

* Anh hãy chia sẻ nhiều hơn về văn hóa của công ty cũng như ở team anh?

Tôi thấy có sự thú vị với tiêu chí đầu tiên là Tôn trọng sự khác biệt. Khi bước chân vào Cybozu, các bạn sẽ không có cảm giác là, Sao tôi khác biệt với mọi người quá?, từ đó trở nên ngại và tách biệt với tập thể. Ở đây, bạn có quyền nói lên tiếng nói của bạn, bạn có quyền mặc bộ đồ khác với xu hướng mọi người. Thứ 2, mọi người đều có cơ hội như nhau: có quyền tranh luận, đưa ra ý kiến cá nhân và đề xuất những giải pháp mà giải pháp đó không chịu sự chi phối của tuổi tác. Ở đây không có sự cả nể, không phải như “Ở đây tôi lớn tuổi là tôi nói các bạn phải nghe”. Mọi thứ được quyết định dựa trên các lập luận thuyết phục. Theo tôi đây cũng là 2 yếu tố rất quan trọng đối với các doanh nghiệp.

* Anh có thể chia sẻ về công cụ mà team anh dùng để quản lý công việc và có thể đo lường hiệu suất của mọi người trong team không?

Với câu hỏi này thì tôi xin phép không trả lời vì đặc tính công việc. Trong team tôi cũng như trong công ty là trên tinh thần của sự khích lệ. Tức là nếu bạn không nhận task thì bạn sẽ không có cơ hội để làm việc, nếu không chủ động thì bạn sẽ khó trưởng thành và phát triển tốt hơn.

* Quá trình tuyển dụng của Cybozu hiện nay như thế nào?

Tôi xin chia sẻ về quan điểm của mình. Cơ bản thì là lọc CV, không phải để tìm ra người giỏi nhất, mà để tìm ra người phù hợp, những người mà có thể đáp ứng sự kỳ vọng của doanh nghiệp. Tiếp đến sẽ có những buổi nói chuyện face-to-face về chuyên môn, không hẳn là phỏng vấn mà chỉ để xem 2 bên có cùng lý tưởng hay không, nếu các bạn phù hợp và có kỹ năng thì các bạn sẽ được công ty mời vào vòng nói chuyện với manager. Còn nếu chưa phù hợp thì có thể hẹn bạn vào thời điểm khác. Đó là quy trình chung ở Cybozu.

* Hiện nay có một số doanh nghiệp thường đặt nặng phần thuật toán. Suy nghĩ của anh như thế nào?

Về cơ bản mỗi công ty có một chiến lược khác nhau để chọn ra ứng viên cho phù hợp. Cá nhân tôi khi phỏng vấn cũng không quá đặt nặng về thuật toán mà thường hay tìm những ứng viên có thể cộng tác với nhau, có tinh thần trách nhiệm, có khả năng research, làm việc độc lập hay chịu được áp lực. Tôi nghĩ đây là những ứng viên chính tôi hoặc công ty mong đợi chứ không phải ứng viên số 1 hay xuất chúng.

* Xin phép được cám ơn anh đã đến với buổi phỏng vấn của TopDev.

* Nguồn: TopDev Blog

Có thể bạn quan tâm:
Gặp gỡ Nguyễn Sơn Tùng CTO Viec.co – Quán quân StartupViet 2019