Mở đầu — vì sao bài này quan trọng
Trong nghề Automation Testing, kiến thức có "hạn sử dụng" ngắn đến mức đáng sợ. Selenium 3 và Selenium 4 khác nhau đáng kể ở cách quản lý driver. Cypress từ chỗ bị chê "không test được multi-tab" đã vá gần hết điểm yếu chỉ trong vài phiên bản. Playwright — công cụ mà năm 2020 gần như không ai ở Việt Nam nhắc tới — nay là lựa chọn mặc định của rất nhiều đội. AI đang viết test case, sinh locator, và tự sửa test hỏng. Nếu bạn ngừng học sáu tháng, thị trường sẽ vượt qua bạn.
Nhưng "học liên tục" không có nghĩa là chạy theo mọi thứ mới. Đó là cái bẫy ngược lại: bạn nhảy từ tool này sang tool khác, biết nông cạn nhiều thứ, không sâu thứ nào, và khi phỏng vấn thì trả lời được câu hỏi bề mặt nhưng đứng hình khi bị hỏi "vì sao". Bài này không phải là danh sách link để bạn bookmark rồi quên. Đây là một hệ thống học tập bền vững cho SDET (Software Development Engineer in Test) — cách chọn nguồn, cách phân bổ thời gian, cách biến kiến thức thành kỹ năng thực chiến, và cách tránh kiệt sức trong một nghề mà "chạy để đứng yên" là điều kiện tối thiểu.
Mục tiêu của bài: giúp bạn xây một lộ trình học liên tục (continuous learning roadmap) cá nhân hóa, dựa trên những nguồn đã được kiểm chứng, và duy trì được nó trong nhiều năm chứ không phải vài tuần hào hứng ban đầu.
Khái niệm cốt lõi
Ba tầng kiến thức: nền tảng, công cụ, xu hướng
Sai lầm phổ biến nhất là dồn hết thời gian vào tầng "công cụ" và "xu hướng" — vì chúng hào nhoáng — mà bỏ quên tầng "nền tảng". Hãy hình dung kiến thức của một SDET như một kim tự tháp:
- Tầng nền tảng (thay đổi rất chậm, ~10% mỗi năm): nguyên lý testing, thiết kế phần mềm hướng đối tượng, HTTP, mạng, hệ điều hành, cấu trúc dữ liệu cơ bản, tư duy về CI/CD và Continuous Delivery. Đây là phần đáng đầu tư nhất vì nó không lỗi thời. Một người hiểu sâu HTTP sẽ học API testing tool mới trong một buổi chiều.
- Tầng công cụ (thay đổi vừa, ~30% mỗi năm): Selenium, Playwright, Cypress, REST Assured, JMeter, Docker, Jenkins... Bạn cần thành thạo 1–2 tool chính và biết đọc hiểu phần còn lại.
- Tầng xu hướng (thay đổi nhanh, biến động lớn): AI-assisted testing, các framework mới nổi, thay đổi trong hệ sinh thái. Với tầng này, bạn chỉ cần "biết nó tồn tại và giải quyết vấn đề gì", chưa cần đào sâu.
Sách nền tảng phải đọc (must-read)
Sách là nguồn có mật độ kiến thức cao nhất và ít nhiễu nhất. Vài cuốn xứng đáng đọc đi đọc lại:
- "Continuous Delivery" — Jez Humble & David Farley. Đây là cuốn kinh điển định hình toàn bộ tư duy hiện đại về pipeline, deployment, và vai trò của test tự động trong dòng chảy đưa phần mềm ra production. Nếu bạn muốn hiểu vì sao automation testing tồn tại chứ không chỉ làm thế nào, hãy bắt đầu từ đây.
- "Growing Object-Oriented Software, Guided by Tests" (thường viết tắt GOOS) — Steve Freeman & Nat Pryce. Cuốn này dạy tư duy thiết kế phần mềm để dễ test, đi qua toàn bộ một dự án bằng test-driven development. Đọc xong bạn sẽ viết code test sạch hơn hẳn.
- "Agile Testing" — Lisa Crispin & Janet Gregory. Bức tranh toàn cảnh về vai trò của tester trong đội Agile, quadrants of testing, và cách phối hợp với dev.
- "The Art of Software Testing" — Glenford Myers. Cổ điển nhưng nguyên lý về thiết kế test case vẫn đúng nguyên vẹn.
Nguồn học có cấu trúc vs. nguồn học tình huống
Chia nguồn học thành hai loại giúp bạn dùng đúng lúc:
- Có cấu trúc (structured): sách, khóa học bài bản, tài liệu chính thức (official docs). Dùng khi bạn học một chủ đề mới từ đầu và cần nền vững. Ví dụ: đọc trọn bộ docs của Playwright khi bắt đầu chuyển sang nó.
- Tình huống (just-in-time): Stack Overflow, blog, GitHub issues, video ngắn. Dùng khi bạn đang gặp một vấn đề cụ thể cần giải ngay. Đừng học kiểu này khi mới bắt đầu vì bạn sẽ chỉ vá lỗ mà không hiểu bức tranh lớn.
Cộng đồng và người thật
Kiến thức ẩn (tacit knowledge) — kiểu "khi nào nên dùng cái này thay cái kia" — hiếm khi nằm trong sách. Nó nằm trong đầu người đi trước. Tham gia cộng đồng là cách rẻ nhất để tiếp cận. Ở Việt Nam có các nhóm như "Vietnam Software Testing Board" trên Facebook, các cộng đồng Ministry of Testing, các buổi meetup của Agile Vietnam, cộng đồng Test Automation trên LinkedIn. Đọc thôi cũng học được, nhưng đóng góp — trả lời câu hỏi, viết lại thứ mình học — mới là lúc kiến thức đóng đinh vào đầu bạn.
Học qua sản xuất, không chỉ tiêu thụ
Có một sự thật phũ phàng: xem 100 video tutorial không bằng tự build một framework nhỏ từ đầu. Não bộ củng cố kiến thức khi bạn tạo ra thứ gì đó — viết blog, làm project cá nhân, trả lời câu hỏi trên diễn đàn, thuyết trình nội bộ cho team. Tỷ lệ tôi khuyên: cứ mỗi 3 giờ tiêu thụ (đọc/xem), hãy dành ít nhất 1 giờ sản xuất.
Tình huống thực tế
Tình huống 1 — "Người biết mọi tool nhưng trượt phỏng vấn"
Minh, 26 tuổi, làm QA ở một công ty outsourcing tại Đà Nẵng. Trong hai năm, CV của bạn ấy liệt kê 11 công cụ: Selenium, Cypress, Playwright, Postman, JMeter, k6, Appium, Katalon, TestNG, Cucumber, và cả một dòng "AI testing". Nghe rất ấn tượng. Nhưng khi Minh phỏng vấn vào vị trí SDET ở một công ty product (lương gấp 1.8 lần), bạn ấy trượt.
Diễn giải: Người phỏng vấn không hỏi "bạn dùng tool nào" mà hỏi "vì sao explicit wait đáng tin hơn Thread.sleep, và cơ chế bên dưới là gì", "một flaky test do race condition thì bạn debug ra sao". Minh trả lời được phần "làm thế nào" ở mức bề mặt nhưng sụp đổ ở phần "vì sao". Bạn ấy đã dành 100% thời gian ở tầng công cụ, 0% ở tầng nền tảng.
Bài học: Chiều rộng gây ấn tượng trên giấy, chiều sâu quyết định trong phòng phỏng vấn và trong công việc thật. Sau lần trượt đó, Minh đọc "Continuous Delivery", đào lại HTTP và concurrency, tập trung sâu Playwright thay vì rải mành mành. Sáu tháng sau, bạn ấy đậu ở một fintech tại TP.HCM.
Tình huống 2 — Đội QA của một startup fintech và "ngân sách học tập"
Một startup fintech ở TP.HCM (khoảng 40 kỹ sư, làm ví điện tử) có đội QA 6 người. Trưởng nhóm QA áp dụng một quy tắc: mỗi thứ Sáu, 2 giờ cuối ngày là "learning time" bắt buộc, không họp, không làm ticket. Ngoài ra công ty cấp mỗi người 3 triệu đồng/năm để mua sách, khóa học, hoặc dự hội thảo.
Kết quả sau một năm: đội tự chuyển toàn bộ suite UI từ Selenium sang Playwright, giảm thời gian chạy regression từ 45 phút xuống 12 phút, và tỷ lệ nghỉ việc bằng 0 trong khi mặt bằng ngành khoảng 20%.
Diễn giải: Điều khiến việc này hiệu quả không phải là số tiền — 3 triệu là rất nhỏ — mà là việc bảo vệ thời gian học. Khi học tập được thể chế hóa thành lịch cố định, nó không còn bị công việc gấp nuốt mất. "Learning time" cũng tạo văn hóa: mọi người chia sẻ thứ mình học vào cuối buổi.
Bài học: Nếu bạn là cá nhân, hãy tự tạo "learning time" của riêng mình và bảo vệ nó như một cuộc họp không thể dời. Nếu bạn là lead, hãy đấu tranh để có nó cho đội — đây là khoản đầu tư ROI cao nhất mà một manager kỹ thuật có thể làm.
Tình huống 3 — Chạy theo AI mà quên nền
Cuối 2024, khi các công cụ AI sinh test bùng nổ, Hằng — một automation engineer ở Hà Nội — dành ba tháng thử hết công cụ AI testing này đến công cụ khác, tin rằng đây là "tương lai" và những thứ cũ sẽ lỗi thời. Nhưng khi công cụ AI sinh ra một locator sai và test fail hàng loạt, Hằng không biết vì sao — vì bạn ấy chưa bao giờ hiểu sâu về locator strategy và DOM.
Diễn giải: AI là công cụ khuếch đại (amplifier). Nó nhân đôi năng suất của người đã giỏi nền tảng, nhưng cũng nhân đôi sự bối rối của người không có nền. Khi output của AI sai — và nó sẽ sai — chỉ người hiểu nguyên lý mới sửa được.
Bài học: Đón nhận công cụ mới, nhưng đừng để nó thay thế việc học nền tảng. Sau đợt đó, Hằng quay lại đào sâu XPath, CSS selector và cách trình duyệt render DOM. Giờ bạn ấy dùng AI để tăng tốc, không phải để thay não.
Hướng dẫn từng bước
Đây là cách xây một lộ trình học liên tục và duy trì nó:
- Tự đánh giá (skill gap analysis). Vẽ ra 3 tầng kim tự tháp, liệt kê những gì bạn đã vững và những gì còn lỗ hổng. Hãy thành thật. Ví dụ: "Tôi dùng Selenium thành thạo nhưng không thực sự hiểu explicit wait hoạt động thế nào bên dưới" — đó là một lỗ hổng nền tảng cần ưu tiên.
- Chọn 1 mục tiêu lớn mỗi quý. Đừng đặt 10 mục tiêu. Một mục tiêu rõ ràng, ví dụ: "Quý này tôi làm chủ Playwright và viết được một framework POM hoàn chỉnh cho một website thật." Mục tiêu phải cụ thể và có sản phẩm đầu ra.
- Xây dựng "học liệu hỗn hợp". Với mỗi mục tiêu, gom: 1 nguồn có cấu trúc (docs chính thức hoặc một cuốn sách), 1 project thực hành, và 1 cộng đồng để hỏi khi kẹt. Ba chân này giữ cho việc học không đổ.
- Lịch cố định + theo dõi. Đặt 3–5 giờ/tuần, chia nhỏ thành các buổi 45–60 phút. Ghi lại (một Notion đơn giản hoặc file markdown) bạn đã học gì mỗi tuần. Việc nhìn lại tiến độ chính là nhiên liệu duy trì động lực.
- Áp dụng ngay vào việc thật. Sau khi học một kỹ thuật, tìm cách đưa nó vào dự án hiện tại trong vòng một tuần. Kiến thức không dùng trong 7 ngày gần như bay hơi hoàn toàn.
- Sản xuất để củng cố. Viết một bài blog ngắn, một README, hoặc trình bày 10 phút cho team về thứ vừa học. Dạy lại là cách kiểm tra xem bạn có thực sự hiểu không.
- Ôn lại theo chu kỳ. Mỗi quý, đọc lại ghi chú của quý trước. Nền tảng cần được củng cố định kỳ, không phải học một lần rồi thôi.
- Xây dựng "hồ sơ học tập công khai" (learning in public). Một tài khoản GitHub với các project cá nhân, một blog, một profile LinkedIn cập nhật. Đây vừa là động lực, vừa là bằng chứng năng lực khi bạn tìm việc — nhiều nhà tuyển dụng ở Việt Nam giờ xem GitHub trước cả CV.
Lỗi thường gặp & mẹo
Lỗi 1 — Hội chứng "tutorial hell". Xem hết video này đến video khác, luôn cảm thấy đang học nhưng không bao giờ tự làm được. Mẹo: Áp dụng quy tắc "1 xem, 1 làm" — cứ mỗi tutorial xem xong phải build lại từ đầu mà không nhìn theo, rồi biến tấu thêm một tính năng.
Lỗi 2 — Chạy theo mọi tool mới (shiny object syndrome). Mẹo: Với mỗi công cụ mới nổi, chỉ cần trả lời được 3 câu: nó giải quyết vấn đề gì, khác gì cái đang có, có đáng để đội tôi chuyển sang không. Nếu chưa cần chuyển, chỉ "biết nó tồn tại" là đủ.
Lỗi 3 — Bỏ bê nền tảng vì nó "chán". Mẹo: Ghép việc học nền tảng với vấn đề thực tế. Muốn học HTTP? Hãy đọc kỹ khi debug một API test fail. Nền tảng trở nên thú vị khi gắn với bài toán bạn đang phải giải.
Lỗi 4 — Học một mình, không bao giờ hỏi. Mẹo: Đặt câu hỏi công khai trên cộng đồng ít nhất một lần mỗi tuần. Việc diễn đạt câu hỏi cho rõ ràng đã giúp bạn hiểu vấn đề hơn một nửa.
Lỗi 5 — Burnout vì ép mình học quá nhiều. Mẹo: Học liên tục là chạy marathon, không phải chạy nước rút. 4 giờ/tuần đều đặn trong 3 năm đánh bại 40 giờ/tuần trong một tháng rồi bỏ. Chấp nhận có những tuần bận không học được, miễn là bạn quay lại.
Mẹo bonus — "Học theo T-shape". Đào sâu một chuyên môn (thanh dọc chữ T — ví dụ UI automation với Playwright) và có kiến thức rộng vừa phải ở các mảng liền kề (thanh ngang — API, CI/CD, performance). SDET giỏi nhất là những người T-shape, không phải chuyên gia một mảng cũng chẳng phải người biết mỗi thứ một chút.
Bài tập thực hành
- Vẽ kim tự tháp của bạn. Trên một trang giấy, vẽ 3 tầng (nền tảng / công cụ / xu hướng) và điền vào mỗi tầng những gì bạn đã vững (màu xanh) và những gì còn yếu (màu đỏ). Xác định 1 lỗ hổng nền tảng ưu tiên nhất.
- Lập roadmap một quý. Viết ra: 1 mục tiêu lớn, 1 sản phẩm đầu ra cụ thể, 1 nguồn có cấu trúc, 1 project thực hành, 1 cộng đồng bạn sẽ tham gia. Đặt lịch 3–5 giờ/tuần vào calendar thật.
- Chọn và bắt đầu một cuốn sách nền tảng. Từ danh sách must-read, chọn một cuốn (gợi ý bắt đầu bằng "Continuous Delivery"). Đọc chương đầu trong tuần này và viết 5 gạch đầu dòng những gì học được.
- Learning in public. Viết một bài blog/ghi chú công khai (dù chỉ 300 từ) về một kỹ thuật automation bạn mới học gần đây. Đăng lên LinkedIn hoặc dev.to. Mục tiêu không phải viết hay, mà là tập thói quen sản xuất.
- Đặt một câu hỏi chất lượng lên cộng đồng. Tìm một vấn đề thật bạn đang kẹt, viết câu hỏi rõ ràng (có bối cảnh, có những gì đã thử) và đăng lên một nhóm testing Việt Nam hoặc Stack Overflow.
Tóm tắt
Học liên tục không phải là chạy theo mọi thứ mới, mà là xây một hệ thống bền vững. Hãy nhớ mấy điểm cốt lõi:
- Chia kiến thức thành 3 tầng: nền tảng (đầu tư nhiều nhất, ~50%), công cụ (~35%), xu hướng (~15%). Nền tảng không lỗi thời và tạo ra khác biệt thật sự.
- Sách là nguồn mật độ cao: bắt đầu với "Continuous Delivery" và "Growing Object-Oriented Software, Guided by Tests".
- Kết hợp nguồn có cấu trúc (học từ đầu) và tình huống (giải quyết vấn đề ngay), tham gia cộng đồng, và ưu tiên sản xuất hơn tiêu thụ.
- Bảo vệ thời gian học như một cuộc họp bất khả xâm phạm; biến việc học thành lịch cố định, không phải chuyện hứng lên mới làm.
- Đón nhận AI và công cụ mới như bộ khuếch đại, nhưng đừng để chúng thay thế nền tảng — khi output sai, chỉ người hiểu nguyên lý mới sửa được.
- Học theo T-shape, học công khai, và chạy marathon chứ không phải nước rút.