[Sưu tầm] 100 từ viết tắt mà Tester nên biết

14/07/2026

Table of Contents

Có rất nhiều từ viết tắt được sử dụng trong phát triển phần mềm. Những bạn tester mới bước vào nghề, sẽ bị “đứng hình” khi thấy mọi người trao đổi với nhau bằng những câu như:

  • “API này đã qua SIT chưa?”
  • “QA đang chuẩn bị UAT.”
  • “Dữ liệu được lấy từ DB.”

Nếu không hiểu các từ viết tắt này, việc nắm bắt nội dung cuộc trao đổi, thảo luận, và khi đọc tài liệu bạn sẽ gặp nhiều khó khăn.

Vì vậy, mình bắt đầu chuỗi “100 từ viết tắt mà mọi tester nên biết”. Bài viết sẽ giới thiệu 100 từ thông dụng nhất, kèm ý nghĩa ngắn gọn và dễ nhớ. 100 từ viết tắt này liên quan đến phát triển phần mềm và sử dụng trong công nghệ thông tin, không bao gồm những từ thông thường như dm = direct message, WDYT = what do you think?

1. API

Application Programming Interface: Giao diện lập trình ứng dụng, cho phép các phần mềm hoặc hệ thống giao tiếp và trao đổi dữ liệu với nhau. Đây là cách mà các phần mềm giao tiếp với nhau.

2. UI

User Interface: Giao diện người dùng, bao gồm màn hình, nút bấm, biểu mẫu và các thành phần mà người dùng tương tác với phần mềm/ hệ thống. Đây là cách mà con người giao tiếp với phần mềm.

3. UX

User Experience: Trải nghiệm của người dùng khi sử dụng sản phẩm, bao gồm mức độ dễ sử dụng, thuận tiện và hài lòng.

4. QA

Quality Assurance: Đảm bảo chất lượng thông qua việc xây dựng quy trình và các hoạt động giúp phòng ngừa lỗi.

QA không chỉ là kiểm thử. Đây là khái niệm rộng hơn, bao gồm mọi hoạt động nhằm nâng cao chất lượng sản phẩm thông qua quy trình phát triển. QA liên quan đến quản lý chất lượng. Kết quả kiểm thử được sử dụng để cải tiến quy trình làm việc (bao gồm các hoạt động phát triển và kiểm thử, liên quan đến mọi vai trò trong dự án gồm DEV và PM).

5. QC

Quality Control: Kiểm soát chất lượng bằng cách đánh giá (chất lượng) sản phẩm và tìm lỗi, trong đó kiểm thử phần mềm là một hoạt động tiêu biểu. Kiểm thử là một hoạt động kiểm soát chất lượng.

Có thể hiểu đơn giản: QA giúp ngăn ngừa lỗi, còn QC giúp phát hiện lỗi.

6. UAT

User Acceptance Testing: Kiểm thử chấp nhận do người dùng hoặc đại diện khách hàng thực hiện để xác nhận hệ thống đáp ứng yêu cầu nghiệp vụ trước khi đưa vào sử dụng.

7. SIT

System Integration Testing: Kiểm thử tích hợp hệ thống nhằm xác nhận các hệ thống hoặc module hoạt động chính xác khi kết nối và trao đổi dữ liệu với nhau.

8. SDLC

Software Development Life Cycle: Vòng đời phát triển phần mềm, bao gồm các giai đoạn từ thu thập yêu cầu, thiết kế, phát triển, kiểm thử đến triển khai và bảo trì.

9. STLC

Software Testing Life Cycle: Vòng đời kiểm thử phần mềm, mô tả các hoạt động kiểm thử từ lập kế hoạch, thiết kế, thực thi đến tổng kết kiểm thử.

10. DB

Database: Cơ sở dữ liệu, nơi lưu trữ và quản lý dữ liệu của hệ thống.

chúng ta sẽ tìm hiểu những từ mà Tester thường xuyên gặp khi làm việc với Developer như JSON, XML, v.v… Đây cũng là những thuật ngữ xuất hiện rất nhiều trong các tài liệu kỹ thuật, hoặc khi làm việc với các công cụ kiểm thử API như Swagger, Postman, DevTools và trong nhật ký hệ thống.

11. SQL: Structured Query Language

Ngôn ngữ truy vấn cơ sở dữ liệu quan hệ, được sử dụng để tạo, truy vấn, cập nhật và xóa dữ liệu.
Tester nên biết các câu lệnh cơ bản như SELECT, INSERT, UPDATE, DELETE để kiểm tra dữ liệu trong Database.

12. JSON: JavaScript Object Notation

Định dạng dữ liệu phổ biến dùng để trao đổi dữ liệu giữa Client và Server, đặc biệt trong REST API.
Hầu hết các API hiện đại đều sử dụng JSON để gửi và nhận dữ liệu.

13. XML: eXtensible Markup Language

Định dạng dữ liệu có cấu trúc, từng được sử dụng rất phổ biến trong Web Service và hiện vẫn còn xuất hiện ở nhiều hệ thống doanh nghiệp.
SOAP API thường sử dụng XML.

14. HTTP: Hypertext Transfer Protocol

Giao thức truyền tải dữ liệu trên Web giữa Client và Server.
Các phương thức (Method) phổ biến gồm GET, POST, PUT, PATCH và DELETE.

15. HTTPS: Hypertext Transfer Protocol Secure

Phiên bản bảo mật của HTTP, sử dụng mã hóa TLS để bảo vệ dữ liệu truyền trên mạng.
Hiện nay gần như mọi website đều sử dụng HTTPS.

16. REST: Representational State Transfer

Một phong cách kiến trúc để xây dựng Web API.
Khi nói “REST API”, mọi người thường đang nói đến các API sử dụng HTTP để trao đổi dữ liệu (thường ở định dạng JSON).

17. SOAP: Simple Object Access Protocol

Một giao thức Web Service sử dụng XML để trao đổi dữ liệu giữa các hệ thống.
SOAP thường xuất hiện trong các hệ thống ngân hàng, bảo hiểm và doanh nghiệp lớn.

18. CRUD: Create – Read – Update – Delete

  • Bốn thao tác cơ bản đối với dữ liệu:
    Create – Tạo mới
    Read – Đọc dữ liệu
    Update – Cập nhật
    Delete – Xóa dữ liệu
    Đây là nhóm chức năng mà hầu như mọi ứng dụng quản lý đều có.

19. JWT: JSON Web Token

Chuẩn token dùng để xác thực và phân quyền người dùng khi gọi API.
Tester thường gặp JWT khi kiểm thử đăng nhập hoặc kiểm thử API yêu cầu Authorization.

20. CORS: Cross-Origin Resource Sharing

Cơ chế cho phép hoặc giới hạn việc một website truy cập tài nguyên từ một domain khác.
Nếu Frontend báo lỗi “CORS policy”, nguyên nhân thường không nằm ở Tester hay Frontend mà do cấu hình của Server.

21. BA: Business Analyst

Chuyên viên phân tích nghiệp vụ, người làm việc với khách hàng và các bên liên quan để thu thập, phân tích và làm rõ yêu cầu, sau đó truyền đạt lại cho nhóm phát triển.
Trong nhiều dự án, Tester thường trao đổi với BA để làm rõ yêu cầu và xác nhận các trường hợp kiểm thử.

22. PO: Product Owner

Người chịu trách nhiệm tối đa về sản phẩm, quản lý Product Backlog và quyết định mức độ ưu tiên của từng User Story.
Khi có thay đổi yêu cầu hoặc cần xác nhận giá trị nghiệp vụ, PO thường là người đưa ra quyết định cuối cùng.

23. SM: Scrum Master

Người hỗ trợ Scrum Team áp dụng Scrum đúng cách, loại bỏ các trở ngại (Impediments) và giúp nhóm cải tiến quy trình làm việc.
Scrum Master không phải là người quản lý nhóm (Team Manager).

24. DoD: Definition of Done

Bộ tiêu chí xác định khi nào một User Story hoặc Product Backlog Item được xem là hoàn thành.

Ví dụ có thể bao gồm:

  • Đã lập trình xong
  • Đã review code
  • Unit Test đạt
  • Không còn lỗi nghiêm trọng
  • Đã cập nhật tài liệu
  • Đã triển khai lên môi trường kiểm thử

Một Story chỉ được coi là “Done” khi đáp ứng đầy đủ Definition of Done.

25. DoR: Definition of Ready

Bộ tiêu chí xác định một User Story đã sẵn sàng để nhóm bắt đầu phát triển.

Ví dụ:

  • Yêu cầu rõ ràng
  • Có Acceptance Criteria
  • Được ước lượng (Estimate)
  • Không còn câu hỏi lớn chưa được giải đáp

DoR giúp tránh việc nhóm bắt đầu phát triển khi yêu cầu còn mơ hồ.

26. US: User Story

Một cách mô tả yêu cầu từ góc nhìn của người dùng nhằm làm rõ giá trị mà tính năng mang lại.

Một User Story thường có dạng:

As a …
I want …
So that …

Ví dụ: As a customer, I want to reset my password so that I can access my account when I forget my password.

User Story không phải là tài liệu đặc tả chi tiết. Đây chỉ là điểm khởi đầu cho các cuộc trao đổi trong nhóm.

27. AC: Acceptance Criteria

Các điều kiện mà một User Story phải đáp ứng để được chấp nhận là hoàn thành.

Ví dụ:

  • Email phải đúng định dạng.
  • Mật khẩu tối thiểu 8 ký tự.
  • Hiển thị thông báo khi đăng nhập thành công.

Acceptance Criteria thường là cơ sở để tester dựa vào đó thiết kế test case.

28. MVP: Minimum Viable Product

Phiên bản sản phẩm tối thiểu nhưng vẫn đủ giá trị để người dùng có thể sử dụng và đưa ra phản hồi.
MVP không có nghĩa là sản phẩm chất lượng thấp, mà là chỉ xây dựng những tính năng cần thiết nhất để kiểm chứng ý tưởng.

29. POC: Proof of Concept

Một bản thử nghiệm nhằm chứng minh rằng một ý tưởng hoặc giải pháp về mặt kỹ thuật là khả thi.

Ví dụ:

  • Thử tích hợp AI vào chatbot.
  • Thử kết nối với một cổng thanh toán mới.
  • Thử áp dụng framework mới.
    POC thường được thực hiện trước khi quyết định đầu tư phát triển chính thức.

30. KPI: Key Performance Indicator

Chỉ số đánh giá hiệu quả của cá nhân, nhóm hoặc tổ chức dựa trên các mục tiêu đã đặt ra.

Ví dụ:

  • Tỷ lệ lỗi bị khách hàng phát hiện.
  • Thời gian xử lý Bug.
  • Sprint Velocity.
  • Test Automation Coverage.
  • Defect Removal Efficiency.

KPI dùng để theo dõi hiệu quả công việc, không nên bị nhầm lẫn với mục tiêu của Agile. Trong Agile, mục tiêu quan trọng nhất vẫn là tạo ra giá trị cho khách hàng.

31. E2E: End-to-End Testing

Kiểm thử từ đầu đến cuối nhằm xác nhận một quy trình nghiệp vụ hoàn chỉnh hoạt động đúng trên toàn bộ hệ thống và các thành phần liên quan.

Ví dụ, với một ứng dụng thương mại điện tử, một luồng E2E có thể là:

Đăng nhập → Tìm sản phẩm → Thêm vào giỏ hàng → Thanh toán → Nhận xác nhận đơn hàng

E2E Testing không chỉ kiểm tra một chức năng riêng lẻ mà kiểm tra toàn bộ luồng từ điểm bắt đầu đến kết quả cuối cùng.

32. BVT: Build Verification Testing

Kiểm thử nhằm xác nhận một bản build mới có đủ ổn định để tiếp tục thực hiện các hoạt động kiểm thử chi tiết hơn hay không.

BVT thường tập trung vào các chức năng quan trọng và các luồng cơ bản.

Nếu BVT thất bại, team có thể quyết định không tiếp tục thực hiện các hoạt động kiểm thử sâu hơn trên build đó và yêu cầu Developer cung cấp build mới. Trong thực tế, BVT đôi khi được sử dụng gần với khái niệm Smoke Testing. Tuy nhiên, tên gọi và phạm vi có thể khác nhau tùy tổ chức và quy trình của từng dự án.

33. FAT: Factory Acceptance Testing

Kiểm thử nghiệm thu được thực hiện tại phía nhà cung cấp hoặc nơi phát triển hệ thống nhằm xác nhận sản phẩm đáp ứng các yêu cầu đã thỏa thuận trước khi được bàn giao hoặc triển khai.

FAT thường gặp trong các dự án có sự tham gia của nhà cung cấp và khách hàng, đặc biệt với các hệ thống lớn hoặc giải pháp được triển khai cho doanh nghiệp.

Có thể hiểu đơn giản: Nhà cung cấp kiểm tra và chứng minh sản phẩm đã sẵn sàng → Khách hàng nghiệm thu → Sau đó mới triển khai hoặc bàn giao.

34. SAT: Site Acceptance Testing

Kiểm thử nghiệm thu được thực hiện tại môi trường hoặc địa điểm triển khai thực tế của khách hàng nhằm xác nhận hệ thống hoạt động đúng trong điều kiện thực tế.

Nếu FAT tập trung vào việc nghiệm thu tại phía nhà cung cấp, SAT thường được thực hiện sau khi hệ thống được triển khai tại địa điểm của khách hàng.

35. PVT: Production Verification Testing

Kiểm thử xác nhận hệ thống sau khi được triển khai lên môi trường Production, nhằm đảm bảo các chức năng quan trọng hoạt động đúng trong môi trường thực tế.

PVT thường tập trung vào các kiểm tra có phạm vi nhỏ và rủi ro thấp, chẳng hạn:

  • Kiểm tra hệ thống có hoạt động không.
  • Kiểm tra các API quan trọng.
  • Kiểm tra khả năng đăng nhập.
  • Kiểm tra một số luồng nghiệp vụ chính.
  • Kiểm tra kết nối với các hệ thống phụ thuộc.

PVT thường được thực hiện sau Deployment và có thể được xem là một phần của hoạt động Production Verification.

Không nên nhầm PVT với việc thực hiện toàn bộ Regression Testing trên Production.

36. TDD: Test-Driven Development

Phương pháp phát triển phần mềm trong đó Developer viết automated test trước khi viết code để triển khai chức năng.

Quy trình TDD thường được mô tả bằng chu kỳ: Red → Green → Refactor

🔴 Red: Viết test và test thất bại.

🟢 Green: Viết code tối thiểu để test thành công.

🔵 Refactor: Cải thiện code mà vẫn đảm bảo test tiếp tục Pass.

TDD chủ yếu liên quan đến Unit Testing và thường được thực hiện bởi Developer.

Tester không nhất thiết phải trực tiếp thực hiện TDD, nhưng hiểu TDD giúp Tester hiểu rõ hơn về cách Developer xây dựng và kiểm thử code.

37. BDD: Behavior-Driven Development

Phương pháp phát triển tập trung vào hành vi mong đợi của hệ thống từ góc nhìn của người dùng hoặc các bên liên quan.

BDD thường sử dụng cấu trúc: Given → When → Then

Ví dụ:

Given người dùng đang ở màn hình đăng nhập
When nhập đúng username và password
Then hệ thống đăng nhập thành công

Điểm quan trọng của BDD không chỉ nằm ở cú pháp Given–When–Then, mà còn ở việc Developer, Tester và Business cùng thống nhất hành vi mong đợi của hệ thống.

38. ATDD: Acceptance Test-Driven Development

Phương pháp phát triển trong đó các Acceptance Test được xác định trước hoặc song song với quá trình phát triển để làm rõ tiêu chí chấp nhận của tính năng.

ATDD khuyến khích sự hợp tác giữa các vai trò như: Business + Developer + Tester

Mục tiêu là thống nhất trước về: “Chúng ta cần xây dựng đúng điều gì?” và “Làm thế nào để biết rằng tính năng đã đáp ứng yêu cầu?”

Lưu ý: TDD, BDD, và ATDD là ba thuật ngữ rất dễ bị nhầm lẫn. Chúng có điểm tương đồng (đều là phương pháp tiếp cận “kiểm thử trước”) nhưng không giống nhau. Trong thực tế, ranh giới giữa BDD và ATDD có thể không hoàn toàn rõ ràng và cách áp dụng cũng phụ thuộc vào từng đội nhóm.

  • TDD → Tập trung vào code và thiết kế kỹ thuật.
  • BDD → Tập trung vào hành vi của hệ thống.
  • ATDD → Tập trung vào tiêu chí chấp nhận và giá trị nghiệp vụ.

39. SDET: Software Development Engineer in Test

Kỹ sư phần mềm chuyên về kiểm thử, thường có năng lực lập trình và tham gia xây dựng các giải pháp kiểm thử tự động, framework, công cụ hoặc hạ tầng hỗ trợ kiểm thử.

SDET có thể tham gia vào:

  • Test Automation
  • Test Framework
  • API Testing
  • Performance Testing
  • CI/CD
  • Developer Tools
  • Test Infrastructure

SDET không đơn giản chỉ là “Tester biết code”. Vai trò SDET thường yêu cầu tư duy và kỹ năng phát triển phần mềm ở mức cao hơn để xây dựng các giải pháp kiểm thử có khả năng mở rộng và bảo trì.

40. RCA: Root Cause Analysis

Phân tích nguyên nhân gốc nhằm xác định nguyên nhân thực sự dẫn đến một vấn đề hoặc sự cố, thay vì chỉ xử lý triệu chứng bên ngoài.

Ví dụ: Problem: Người dùng không thể thanh toán.

❌ “Thanh toán thất bại” → Đây chỉ là hiện tượng.

❌ “API trả về HTTP 500” → Đây có thể là một triệu chứng.

RCA cần tiếp tục tìm hiểu:

Tại sao API trả về HTTP 500?
→ Database timeout.

Tại sao Database timeout?
→ Query không được tối ưu.

Tại sao query không được tối ưu?
→ Thiếu index cho một trường dữ liệu quan trọng.

Root Cause: Thiết kế Database hoặc Query chưa phù hợp.

Với Tester, RCA không chỉ giúp tìm ra “ai gây ra bug”, mà quan trọng hơn là giúp team hiểu tại sao lỗi xảy ra và làm thế nào để ngăn lỗi tương tự tái diễn.

41. BRD: Business Requirements Document

Tài liệu mô tả các yêu cầu và nhu cầu ở góc độ nghiệp vụ của doanh nghiệp hoặc khách hàng.

BRD thường tập trung vào câu hỏi:

“Doanh nghiệp cần giải quyết vấn đề gì và muốn đạt được điều gì?”

Ví dụ, một ngân hàng có thể yêu cầu xây dựng chức năng chuyển tiền trực tuyến để giúp khách hàng thực hiện giao dịch mà không cần đến chi nhánh.

Với Tester, BRD giúp hiểu bối cảnh nghiệp vụ và mục tiêu kinh doanh phía sau một tính năng, thay vì chỉ biết tính năng đó hoạt động như thế nào.

42. SRS: Software Requirements Specification

Tài liệu đặc tả các yêu cầu của hệ thống hoặc phần mềm, mô tả hệ thống cần cung cấp những chức năng và hành vi nào.

SRS có thể bao gồm:

  • Functional Requirements
  • Non-functional Requirements
  • Các quy tắc nghiệp vụ
  • Giao diện hoặc tương tác
  • Các ràng buộc của hệ thống
  • Yêu cầu về hiệu năng, bảo mật
  • V.v…

SRS thường là một nguồn thông tin quan trọng để Tester hiểu cần kiểm thử điều gì và xác định các điều kiện kiểm thử.

Tuy nhiên, trong các dự án Agile hiện đại, yêu cầu có thể được quản lý dưới nhiều hình thức khác nhau như User Story, Acceptance Criteria, Product Backlog thay vì một tài liệu SRS lớn và cố định.

43. FR: Functional Requirement

Yêu cầu chức năng mô tả hệ thống phải làm gì.

Ví dụ:

  • Người dùng có thể đăng nhập bằng email và mật khẩu.
  • Người dùng có thể tìm kiếm sản phẩm.
  • Người dùng có thể thêm sản phẩm vào giỏ hàng.
  • Hệ thống gửi email xác nhận sau khi đặt hàng thành công.

Khi kiểm thử FR, Tester thường tập trung vào việc xác nhận hệ thống thực hiện đúng hành vi và chức năng được yêu cầu.

44. NFR: Non-functional Requirement

Yêu cầu phi chức năng mô tả hệ thống phải hoạt động như thế nào hoặc các thuộc tính chất lượng mà hệ thống cần đáp ứng.

Ví dụ:

  • Thời gian phản hồi không quá 2 giây.
  • Hệ thống hỗ trợ 10.000 người dùng đồng thời.
  • Dữ liệu nhạy cảm phải được mã hóa.
  • Hệ thống có khả năng hoạt động liên tục.
  • Ứng dụng phải dễ sử dụng.

Đây là nhóm yêu cầu rất quan trọng nhưng đôi khi bị bỏ quên.

Tester không nên chỉ hỏi: Chức năng này có hoạt động đúng không?

Mà còn cần đặt câu hỏi:

  • Nó có hoạt động đủ nhanh không?
  • Có an toàn không?
  • Có thể chịu được tải dự kiến không?
  • Có dễ sử dụng không?

45. ALM: Application Lifecycle Management

Quản lý toàn bộ vòng đời của một ứng dụng, từ khi hình thành ý tưởng, phân tích yêu cầu, phát triển, kiểm thử, triển khai đến bảo trì. Ví dụ như Jira.

ALM có thể bao gồm các hoạt động như:

Requirements → Development → Testing → Release → Maintenance

Với Tester, ALM giúp nhìn nhận kiểm thử như một phần của toàn bộ vòng đời sản phẩm, thay vì một hoạt động độc lập chỉ diễn ra sau khi Developer hoàn thành code.

Các công cụ ALM có thể hỗ trợ quản lý:

  • Requirements
  • Test Cases
  • Defects
  • Releases
  • Traceability

46. SDM: Software Development Methodology

Phương pháp hoặc cách tiếp cận được sử dụng để tổ chức và quản lý quá trình phát triển phần mềm.

Ví dụ:

  • Waterfall
  • Agile
  • Scrum
  • Kanban
  • DevOps

Tester cần hiểu phương pháp phát triển mà team đang sử dụng vì nó ảnh hưởng trực tiếp đến:

  • Khi nào Tester tham gia?
  • Khi nào kiểm thử được thực hiện?
  • Cách quản lý yêu cầu như thế nào?
  • Cách báo cáo lỗi ra sao?
  • Khi nào sản phẩm được Release?

Cùng là hoạt động kiểm thử nhưng cách Tester làm việc trong Waterfall và Agile có thể rất khác nhau.

47. Spike

Một khoảng thời gian hoặc một công việc được thực hiện nhằm nghiên cứu, tìm hiểu hoặc thử nghiệm để giảm sự không chắc chắn trước khi quyết định cách triển khai một giải pháp.

Ví dụ, nhóm bạn muốn tích hợp một API thanh toán mới nhưng chưa biết:

  • API có đáp ứng yêu cầu không?
  • Có giới hạn số lượng request không?
  • Có hỗ trợ tính năng cần thiết không?
  • Tích hợp mất bao lâu?
  • Có vấn đề kỹ thuật nào không?

Team có thể tạo một Spike (hay gọi là spike task) để nghiên cứu hoặc xây dựng một bản thử nghiệm nhỏ.

Spike thường không nhằm mục tiêu tạo ra một tính năng hoàn chỉnh. Mục tiêu chính là học hỏi và giảm rủi ro trước khi phát triển.

Tester cũng có thể tham gia Spike, đặc biệt khi cần tìm hiểu:

  • Khả năng kiểm thử
  • Khả năng tự động hóa
  • Công cụ kiểm thử
  • Khả năng quan sát hệ thống
  • Rủi ro về kỹ thuật

48. CI: Continuous Integration

Tích hợp liên tục, là thực hành trong đó các thay đổi mã nguồn được tích hợp thường xuyên vào một repository chung và được kiểm tra tự động.

Một quy trình CI có thể thực hiện:

Code Commit → Build → Automated Tests → Feedback

Với Tester, CI giúp phát hiện lỗi sớm hơn thông qua việc tự động chạy các kiểm thử như:

  • Unit Test
  • Integration Test
  • API Test
  • Static Analysis
  • Security Scan

CI giúp đưa hoạt động kiểm thử đến gần hơn với thời điểm Developer thay đổi code.

49. CD: Continuous Delivery / Continuous Deployment

CD có thể được hiểu theo hai nghĩa phổ biến:

Continuous Delivery

Đảm bảo phần mềm luôn ở trạng thái sẵn sàng để triển khai.
Việc triển khai phiên bản mới lên Production có thể vẫn cần một bước phê duyệt thủ công.

Continuous Deployment

Các thay đổi đã vượt qua các bước kiểm tra cần thiết sẽ được tự động triển khai lên Production.

Vì vậy, Continuous Delivery ≠ Continuous Deployment. Đây là hai khái niệm liên quan nhưng không hoàn toàn giống nhau.

Với Tester, CD có thể liên quan đến:

  • Automated Testing
  • Quality Gates
  • Test Environment
  • Deployment Verification
  • Release Validation

50. DevOps: Development + Operations

Một cách tiếp cận nhằm tăng cường sự hợp tác giữa các nhóm phát triển phần mềm và vận hành hệ thống, đồng thời tự động hóa và cải tiến dòng chảy từ phát triển đến triển khai và vận hành.

DevOps thường liên quan đến quá trình:

Plan → Code → Build → Test → Release → Deploy → Operate → Monitor

Tester trong môi trường DevOps không chỉ kiểm thử ở giai đoạn cuối.

Tester có thể tham gia vào nhiều hoạt động như:

  • Test Automation
  • CI/CD
  • Quality Gates
  • API Testing
  • Performance Testing
  • Security Testing
  • Monitoring
  • Observability

Điều quan trọng là chất lượng trở thành trách nhiệm của cả đội (mỗi vai trò sẽ chịu trách nhiệm cho khía cạnh chất lượng khác nhau), không phải chỉ của tester.

51. IDE: Integrated Development Environment

Môi trường phát triển tích hợp, là phần mềm cung cấp các công cụ hỗ trợ lập trình trong một giao diện thống nhất.

Một IDE thường cung cấp:

  • Code Editor
  • Debugger
  • Build Tools
  • Version Control Integration
  • Plugin / Extension

Ví dụ phổ biến:

  • IntelliJ IDEA
  • Visual Studio Code
  • Eclipse

Tester không nhất thiết phải sử dụng IDE để viết code mỗi ngày. Tuy nhiên, nếu làm Kiểm thử tự động, việc sử dụng IDE sẽ giúp viết, debug, và quản lý test case tự động hiệu quả hơn.

52. SDK: Software Development Kit

Bộ công cụ phát triển phần mềm, cung cấp các công cụ, thư viện, tài liệu và thành phần cần thiết để phát triển ứng dụng cho một nền tảng hoặc hệ sinh thái cụ thể.

Ví dụ:

  • Android SDK
  • iOS SDK
  • AWS SDK
  • OpenAI SDK

Một SDK có thể bao gồm: Libraries + APIs + Tools + Documentation

Tester có thể gặp SDK khi kiểm thử ứng dụng mobile hoặc khi kiểm thử các hệ thống tích hợp với dịch vụ bên thứ ba.

Ví dụ: Một ứng dụng tích hợp thanh toán có thể sử dụng Payment SDK. Khi đó, Tester cần kiểm thử không chỉ giao diện của ứng dụng mà còn cách ứng dụng tương tác với SDK và hệ thống bên ngoài.

53. OOP: Object-Oriented Programming

Lập trình hướng đối tượng, một phương pháp lập trình tổ chức chương trình dựa trên các object (đối tượng) và class (lớp).

Bốn khái niệm thường được nhắc đến trong OOP:

  • Encapsulation – Đóng gói
  • Inheritance – Kế thừa
  • Polymorphism – Đa hình
  • Abstraction – Trừu tượng

Tại sao Tester nên biết OOP? Vì nếu bạn làm Test Automation, đặc biệt với các framework lớn, bạn sẽ thường xuyên gặp:

  • Class
  • Object
  • Method
  • Inheritance
  • Interface

Hiểu OOP sẽ giúp bạn đọc hiểu cấu trúc của automation framework và dễ dàng trao đổi với Developer về cách code được tổ chức.

54. ORM: Object-Relational Mapping

Kỹ thuật ánh xạ giữa các đối tượng trong chương trình và dữ liệu được lưu trữ trong cơ sở dữ liệu quan hệ.

Ví dụ: Trong code có một object: User

  • Object này có thể được ánh xạ với bảng: users
  • và các thuộc tính: id, name, email được ánh xạ với các cột trong Database.

Một số ORM phổ biến:

  • Hibernate
  • Entity Framework
  • Django ORM
  • Sequelize

Tester nên biết ORM vì đôi khi một lỗi nhìn thấy ở UI hoặc API có thể bắt nguồn từ việc ánh xạ giữa Application  ORM  Database.

Khi hiểu được luồng này, Tester có thể phân tích lỗi tốt hơn thay vì chỉ báo: “API trả về sai dữ liệu.”

55. MVC: Model – View – Controller

Một mô hình kiến trúc phần mềm phổ biến, chia ứng dụng thành ba thành phần chính:

  • Model: Quản lý dữ liệu và logic liên quan đến dữ liệu.
  • View: Hiển thị giao diện cho người dùng.
  • Controller: Tiếp nhận request và điều phối xử lý giữa các thành phần.

Có thể hình dung đơn giản: User → View → Controller → Model → Database

Hiểu MVC giúp Tester hình dung được lỗi có thể nằm ở đâu.

Ví dụ: Người dùng nhấn Login nhưng nhận được thông báo sai.

Tester có thể bắt đầu phân tích:

  • UI/ View: Request có được gửi đúng không?
  • Controller: Request có được xử lý đúng không?
  • Model: Dữ liệu có được truy vấn đúng không?
  • Database: Dữ liệu người dùng có chính xác không?

Đây là một cách tư duy hữu ích khi phân tích lỗi, dù hệ thống thực tế có thể sử dụng kiến trúc khác.

56. MVVM: Model – View – ViewModel

Một mô hình kiến trúc thường được sử dụng trong phát triển ứng dụng giao diện, đặc biệt trong một số framework và nền tảng mobile.

Ba thành phần gồm:

  • Model: Dữ liệu và logic nghiệp vụ.
  • View: Giao diện mà người dùng nhìn thấy và tương tác.
  • ViewModel Lớp trung gian cung cấp dữ liệu và trạng thái cho View.

Tester có thể gặp MVVM khi kiểm thử ứng dụng mobile hoặc các ứng dụng sử dụng framework hỗ trợ mô hình này.

Hiểu kiến trúc giúp Tester biết rằng:

  • Một lỗi hiển thị trên màn hình chưa chắc đã bắt nguồn từ UI.
  • Có thể dữ liệu từ ViewModel đã sai, hoặc nguồn dữ liệu từ Backend đã sai ngay từ đầu.

57. GitOps: Git Operations

Một cách tiếp cận quản lý vận hành và triển khai hệ thống trong đó Git repository đóng vai trò là nguồn sự thật (Source of Truth) cho cấu hình hệ thống và hạ tầng.

⚠️ Lưu ý: Trong thực tế, thuật ngữ GitOps thường được hiểu rộng hơn là chỉ “Git Operations”. Đây là một phương pháp vận hành dựa trên Git, Infrastructure as Code và tự động hóa.

Một quy trình GitOps có thể được hình dung: Git Repository → Configuration / Infrastructure as Code → Automated Deployment → Environment

Tester nên biết GitOps vì thay đổi cấu hình môi trường có thể ảnh hưởng trực tiếp đến kết quả kiểm thử.

Ví dụ: Code không thay đổi nhưng hôm nay test lại fail.

Có thể nguyên nhân nằm ở:

  • Environment Configuration
  • Database Configuration
  • Feature Flag
  • Infrastructure
  • Deployment Configuration

58. VM: Virtual Machine

Máy ảo, là một môi trường máy tính được mô phỏng bằng phần mềm và chạy trên một máy vật lý hoặc hạ tầng máy chủ.

Một máy tính vật lý có thể chạy nhiều VM: Physical Machine →VM 1 – Test Environment | VM 2 – Staging Environment | VM 3 – Development Environment

Tester có thể gặp VM khi làm việc với các môi trường kiểm thử hoặc hệ thống được triển khai trên hạ tầng ảo hóa.

VM cũng giúp tạo môi trường tương đối độc lập để:

  • Test
  • Development
  • Deployment
  • Troubleshooting

59. OS: Operating System

Hệ điều hành, phần mềm nền tảng quản lý tài nguyên phần cứng và cung cấp môi trường để các ứng dụng hoạt động.

Ví dụ:

  • Windows
  • macOS
  • Linux
  • Android
  • iOS

Tester cần đặc biệt quan tâm đến OS khi kiểm thử khả năng tương thích.

Ví dụ:

Mobile App

  • Android
  • iOS

Desktop App

  • Windows
  • macOS

Server

  • Linux
  • Windows Server

Một lỗi có thể chỉ xảy ra trên một hệ điều hành cụ thể. Vì vậy, OS là một phần quan trọng của Test Environment.

60. CPU: Central Processing Unit

Bộ xử lý trung tâm, thành phần thực hiện các phép tính và xử lý các lệnh của chương trình.

Hiểu đơn giản:

  • CPU → Khả năng xử lý
  • RAM → Bộ nhớ tạm thời
  • Storage → Lưu trữ dữ liệu

Với Tester, CPU đặc biệt quan trọng khi thực hiện Performance Testing hoặc kiểm tra các vấn đề liên quan đến tài nguyên hệ thống.

Ví dụ: Một hệ thống có thể phản hồi chậm không phải vì API có vấn đề mà vì:

  • CPU sử dụng quá cao.
  • RAM không đủ.
  • Database quá tải.
  • Một process chiếm nhiều tài nguyên.

Vì vậy, khi kiểm thử hiệu năng, Tester cần nhìn hệ thống ở nhiều lớp khác nhau thay vì chỉ đo thời gian phản hồi của API.

Nguồn@Hoàng Liên Sơn_nhóm TESTING VN

Còn cập nhật tiếp…

Bài viết liên quan

NHỮNG KỸ NĂNG CẦN THIẾT ĐỂ APPLY BUSINESS ANALYST THỜI AI

Muốn apply Business Analyst trong thời AI, biết công cụ thôi là chưa đủ. Vậy bạn cần trang bị những kỹ năng gì để thực sự được chọn?

Rất nhiều người khi bắt đầu học Business Analyst đều mặc định một điều: chỉ cần học UML, BPMN, SQL, biết viết User Story, BRD, SRS và làm thêm vài project là đủ để apply job.

Nhưng nếu chỉ dừng ở đó thôi thì chưa đủ.

Trong bối cảnh AI đang hỗ trợ ngày càng tốt các công việc mang tính tài liệu và quy trình, những gì bạn đang dành hàng tháng để luyện tập: từ viết User Story, xây dựng Use Case, tạo Flow Diagram cho đến soạn Requirement Document, đang dần mất đi sự khác biệt. Bởi AI có thể hỗ trợ thực hiện những công việc này nhanh hơn, đầy đủ hơn và gần như tức thời.

Kết quả là "biết công cụ và biết viết tài liệu" từ một lợi thế trở thành điều kiện tối thiểu. Khi ai cũng đạt được mức tối thiểu, thì đó không còn là lý do để bạn được chọn nữa.

Và đây là lúc khoảng cách bắt đầu xuất hiện.

Trong khi bạn vẫn đang tập trung vào việc hoàn thiện tài liệu và sơ đồ, thì doanh nghiệp lại đánh giá ở một level khác: Bạn có thực sự hiểu bài toán kinh doanh không? Bạn có xác định được đâu là vấn đề gốc rễ cần giải quyết không? Và giải pháp bạn đề xuất có tạo ra giá trị thực tế cho doanh nghiệp hay không?

Nói cách khác, giá trị của Business Analyst hiện đại không nằm ở việc viết tài liệu đẹp đến đâu, mà nằm ở khả năng kết nối giữa nhu cầu kinh doanh, người dùng và giải pháp phù hợp.

Đây cũng chính là lý do vì sao nhiều người rơi vào vòng lặp: học rất nhiều, làm rất nhiều, nhưng kết quả apply không thay đổi. Không phải vì họ thiếu nỗ lực, mà vì họ đang xây dựng năng lực theo một cách không còn phù hợp với cách thị trường đang đánh giá.

Vậy nếu muốn apply Business Analyst thời AI, newbie cần phải chuẩn bị kỹ năng gì?

Từ suy nghĩ: “học công cụ = trở thành Business Analyst”, bạn cần chuyển sang: kết hợp business thinking + problem solving + AI workflow để tạo ra giá trị thực tế cho doanh nghiệp.

1. Hiểu business & bài toán nghiệp vụ: Biết doanh nghiệp đang gặp vấn đề gì, mục tiêu kinh doanh là gì và tại sao dự án cần được thực hiện, thay vì chỉ tập trung viết tài liệu.

→ Đây là điểm khác biệt giữa một người “làm BA” và một người có thể trả lời: “giải pháp này giúp doanh nghiệp đạt được điều gì?”.

2. Khai thác yêu cầu và phân tích vấn đề: Đi từ nhu cầu thực tế của stakeholder → phân tích nguyên nhân → làm rõ yêu cầu → đề xuất giải pháp phù hợp, thay vì chỉ ghi nhận thông tin và chuyển tiếp cho đội phát triển.

→ Đây là phần giúp bạn chứng minh năng lực phân tích và tư duy hệ thống, thay vì chỉ đóng vai trò trung gian truyền đạt thông tin.

3. Chuyển yêu cầu thành giải pháp có thể triển khai: Một bộ requirement tốt không chỉ mô tả hệ thống cần làm gì, mà còn phải đảm bảo đội phát triển, kiểm thử và các bên liên quan đều hiểu đúng và thực hiện được.

→ Đây chính là điểm khiến bạn nổi bật hơn so với những ứng viên chỉ biết viết tài liệu hoặc vẽ sơ đồ.

4. Sử dụng AI có kiểm soát: AI có thể hỗ trợ bạn phân tích yêu cầu, xây dựng user story, viết tài liệu hoặc tạo mockup nhanh hơn. Nhưng nếu không hiểu nghiệp vụ và logic phía sau, bạn sẽ không biết đâu là yêu cầu hợp lý và đâu là nội dung AI đang suy diễn sai.

→ Người được chọn không phải là người dùng AI nhiều nhất, mà là người hiểu bài toán kinh doanh, biết tận dụng AI để tăng tốc và vẫn kiểm soát được chất lượng đầu ra.

Khi bắt đầu với mindset này, cách bạn học cũng sẽ thay đổi hoàn toàn. Bạn không còn học rời rạc từng công cụ như UML, BPMN, SQL hay AI Prompting, mà học cách đi từ bài toán kinh doanh → yêu cầu nghiệp vụ → giải pháp → triển khai → giá trị mang lại cho doanh nghiệp. Đồng thời, bạn biết tận dụng AI để tăng tốc toàn bộ quy trình phân tích, nhưng vẫn hiểu rõ bản chất vấn đề và kiểm soát được kết quả.

Đó cũng là sự khác biệt giữa một người “biết làm BA” và một người có thể thực sự trở thành Business Analyst.

Business Analyst Làm Gì? Lộ Trình Và Kỹ Năng “Sống Còn” Cho Người Mới

Trong kỷ nguyên số, doanh nghiệp không chỉ cần công nghệ, họ cần những giải pháp thực tế. Đó là lý do Business Analyst (BA) trở thành "mắt xích" không thể thiếu, kết nối giữa bài toán kinh doanh và lời giải vận hành, hệ thống hoặc công nghệ.

Vậy Business Analyst là gì? BA làm gì trong doanh nghiệp? Bài viết này sẽ giúp bạn hiểu rõ toàn bộ vai trò, công việc, kỹ năng và lộ trình phát triển của một BA – đặc biệt phù hợp với người mới bắt đầu hoặc đang muốn chuyển sang ngành này, dù bạn xuất phát từ IT hay bất kỳ lĩnh vực nào khác như tài chính, vận hành, marketing, giáo dục, bán lẻ hay dịch vụ.

1. Business Analyst là ai?

Hiểu một cách đơn giản nhất, BA là "người phiên dịch" đa năng. Họ đứng giữa Business (Kinh doanh) và các bộ phận thực thi (có thể là IT, vận hành, sản phẩm, tài chính...) để đảm bảo tất cả cùng hiểu đúng vấn đề và cùng đi về một hướng.

Vai trò cốt lõi của một BA là đảm bảo:

  • Doanh nghiệp đang giải quyết đúng vấn đề: Không lãng phí nguồn lực vào những hoạt động không tạo ra giá trị thực tế.
  • Giải pháp được triển khai đúng mục tiêu: Dù đó là phần mềm, quy trình vận hành, chiến dịch marketing hay mô hình kinh doanh.

Vì thế, BA không chỉ “ghi nhận yêu cầu”, mà còn phải hiểu bản chất vấn đề, đặt câu hỏi, phản biện và đề xuất giải pháp tối ưu.

BA có thể làm việc trong rất nhiều bối cảnh khác nhau:

  • Trong doanh nghiệp vận hành: chuẩn hóa quy trình, giảm sai sót
  • Trong công ty công nghệ: phân tích yêu cầu để xây dựng hệ thống/phần mềm
  • Trong ngân hàng: tối ưu quy trình phê duyệt, giảm rủi ro
  • Trong e-commerce: cải thiện trải nghiệm mua hàng, tăng conversion
  • Trong giáo dục: thiết kế lại hành trình học viên

2. BA làm gì trong một dự án hoặc doanh nghiệp?

Công việc của BA trải dài xuyên suốt vòng đời của một dự án, từ lúc hình thành ý tưởng cho đến khi sản phẩm được triển khai và vận hành. Để thành công trong nghề này, có 5 kỹ năng "xương máu" mà bạn không chỉ cần biết, mà phải thực sự làm chủ:

2.1. Thu thập yêu cầu (Requirement Gathering)

Đây là bước đầu tiên nhưng cực kỳ quan trọng. Đừng nghĩ thu thập yêu cầu chỉ là đi hỏi "Anh/chị muốn làm gì?". Sai lầm lớn nhất của BA mới vào nghề là khách hàng nói gì thì ghi nấy.

Công việc thực sự ở đây là "đào bới". Khách hàng đôi khi không biết họ thực sự cần gì, hoặc họ mô tả một giải pháp thay vì nêu vấn đề. BA giỏi phải giống như một thám tử: dùng các buổi phỏng vấn (Interview), thảo luận nhóm (Workshop), khảo sát (Survey) hay thậm chí là ngồi quan sát nhân viên làm việc cả ngày để nhìn ra những "nỗi đau" (pain points) mà chính họ cũng không nhận ra.

BA làm việc trực tiếp với stakeholder (khách hàng, người dùng, team nội bộ, quản lý, đội kỹ thuật...) để hiểu:

  • Vấn đề thực sự là gì
  • Kỳ vọng của họ ra sao
  • Mục tiêu kinh doanh mà họ hướng tới là gì
  • Các ràng buộc về thời gian, chi phí, nguồn lực, quy trình hay công nghệ

BA cần sử dụng nhiều kỹ thuật như: phỏng vấn, workshop, khảo sát, quan sát thực tế để đảm bảo thông tin thu thập là đầy đủ và chính xác.

Điều quan trọng là BA cần phải nghe để hiểu. Nhiều khi thứ stakeholder nói ra chỉ là “mong muốn bề mặt”, còn nhiệm vụ của BA là tìm ra nhu cầu thật sự phía sau.
Ví dụ, họ nói muốn thêm một chức năng mới, nhưng điều họ thực sự cần có thể chỉ là rút ngắn thời gian xử lý, giảm sai sót hoặc cải thiện trải nghiệm người dùng.

2.2. Phân tích nghiệp vụ (Business Analysis)

Sau khi thu thập được thông tin, BA không thể bê nguyên xi những gì khách hàng nói vào hệ thống được.

BA sẽ phải tự hỏi: "Tại sao họ lại làm bước này? Nếu bỏ đi có sao không? Nếu làm theo cách mới thì quy trình sẽ chạy thế nào? Nếu thay đổi một điểm thì các bộ phận khác có bị ảnh hưởng không?". Bạn sẽ vẽ ra luồng công việc hiện tại (AS-IS) để thấy nó đang "tắc" ở đâu, và vẽ ra viễn cảnh tương lai (TO-BE) để mọi thứ trơn tru hơn. Đây là giai đoạn bạn biến những dữ liệu thô thành một chiến lược giải quyết vấn đề.

BA cần phân tích các yếu tố như:

  • Root cause (nguyên nhân gốc rễ)
  • Luồng nghiệp vụ hiện tại (AS-IS)
  • Điểm bất cập trong quy trình hiện tại
  • Đề xuất luồng nghiệp vụ mới (TO-BE)
  • Tác động của thay đổi đến các bên liên quan
  • Giá trị mang lại cho doanh nghiệp và người dùng

Giá trị của BA được thể hiện chính qua giai đoạn này, vì thế đừng bỏ lỡ cơ hội thể hiện bản thân mình.

Đây cũng là lúc BA chứng minh rằng mình không chỉ “biết quy trình”, mà thực sự hiểu cách một doanh nghiệp vận hành. Một BA giỏi có thể nhìn thấy mối liên hệ giữa nghiệp vụ, con người, hệ thống và kết quả cuối cùng, từ đó đưa ra những đề xuất không chỉ đúng về mặt logic mà còn khả thi khi triển khai.

Ở các lĩnh vực khác nhau, phần này vẫn giữ nguyên bản chất:

  • Với IT: tối ưu hệ thống, tính năng
  • Với vận hành: tối ưu quy trình
  • Với marketing: tối ưu hành trình khách hàng
  • Với tài chính: tối ưu dòng tiền, quy trình kiểm soát

2.3. Viết tài liệu nghiệp vụ (Documentation)

BA chịu trách nhiệm chuyển toàn bộ phân tích thành tài liệu rõ ràng, dễ hiểu cho các bên liên quan. Và viết tài liệu không phải là viết văn sớ, mà là viết sao để "ai đọc cũng hiểu giống nhau".

  • Sếp đọc thấy: "À, phần mềm này sẽ giúp công ty tăng doanh thu / giảm chi phí / tối ưu vận hành".
  • Người thực thi đọc thấy: "À, chỗ này mình phải code một chức năng như thế này, xử lý dữ liệu như thế này".
  • Bạn QA đọc thấy: "À, tính năng này cần được kiểm thử với các điều kiện nào để đảm bảo đúng nghiệp vụ".
  • Người dùng đọc thấy: "À, hệ thống này sẽ giúp tôi làm việc nhanh hơn và ít sai hơn".

Từ những bản tài liệu đồ sộ như BRD, SRS cho đến những mẩu User Stories ngắn gọn trong Agile, tất cả đều phải logic, chặt chẽ và không có chỗ cho sự "mập mờ".

=> Một tài liệu tốt không chỉ đầy đủ, mà còn phải logic, nhất quán và tránh gây hiểu sai cho team phát triển.

Ngoài việc mô tả yêu cầu, BA còn phải biết cách sắp xếp thông tin theo thứ tự hợp lý, tách bạch phần nào là business rule, phần nào là luồng xử lý, phần nào là ngoại lệ, phần nào là điều kiện chấp nhận. Viết rõ là một chuyện, viết đúng trọng tâm để người đọc dễ dùng lại là một chuyện khó hơn rất nhiều.

2.4. Truyền đạt giữa Business và các bộ phận thực thi

Đây có lẽ là phần "nghệ thuật" nhất trong nghề BA. Bạn đứng giữa nhiều thế giới:

  • Phía Business: mục tiêu, doanh thu, kỳ vọng
  • Phía thực thi: hệ thống, quy trình, nguồn lực, giới hạn

Nhiệm vụ của bạn là giải thích cho phía Business hiểu tại sao một giải pháp không thể làm ngay lập tức, và thuyết phục phía thực thi rằng một yêu cầu nào đó thực sự quan trọng.

Nếu không có BA, các bên rất dễ "ông nói gà, bà nói vịt".

BA cần đảm bảo các bên hiểu nhau và cùng đi về một hướng.

2.5. Hỗ trợ kiểm thử và triển khai

Nhiều người tưởng viết xong tài liệu là xong việc, nhưng không. Khi giải pháp bắt đầu được triển khai (dù là phần mềm hay quy trình), BA chính là người thẩm định cuối cùng.

Bạn sẽ kiểm tra xem thực tế triển khai có đúng với những gì mình đã phân tích hay không. Sau đó, bạn lại đóng vai trò là "người hướng dẫn", giúp người dùng cuối làm quen với hệ thống hoặc quy trình mới. Nếu có vấn đề phát sinh hoặc hiểu sai nghiệp vụ, bạn chính là người đứng ra "gỡ rối".

BA không kết thúc công việc khi tài liệu được viết xong. Trong quá trình triển khai, BA sẽ:

  • Hỗ trợ kiểm tra (test/validate) giải pháp
  • Đảm bảo kết quả đúng với yêu cầu ban đầu
  • Tham gia nghiệm thu (UAT hoặc tương đương)

3. Vai trò của BA trong các mô hình làm việc khác nhau

Vai trò của một BA không bao giờ là "bất di bất dịch". Tùy vào việc công ty bạn đang chạy theo lối truyền thống hay hiện đại, công việc hằng ngày của bạn sẽ xoay chuyển rất khác nhau.

3.1. BA trong Agile/Scrum

Trong thế giới Agile, mọi thứ diễn ra rất nhanh. Dự án được chia nhỏ thành từng giai đoạn ngắn (thường là 2-4 tuần gọi là Sprint). Ở đây, BA giống như một người đầu bếp tại quầy buffet: vừa làm, vừa quan sát thực khách và điều chỉnh món ăn ngay lập tức. Vì thế, BA cần:

  • Chấp nhận sự thay đổi: Khách hàng có thể đổi ý sau mỗi 2 tuần khi thấy bản demo. Thay vì khó chịu, BA trong Agile coi đó là chuyện bình thường và nhanh chóng cập nhật yêu cầu mới.Trong Agile, BA thường làm việc rất sát với team và có thể đảm nhận vai trò gần với Product Owner.
  • Viết và quản lý Backlog (User Stories): Thay vì viết một quyển "bí kíp" dày cộp, bạn viết những mẩu tin nhỏ (User Stories) dạng: "Với tư cách là người dùng, tôi muốn... để có thể...". Bạn phải liên tục sắp xếp xem cái nào quan trọng thì làm trước.
  • Làm rõ yêu cầu theo "thời gian thực": Trong mỗi Sprint, đội ngũ lập trình có thể hỏi bạn bất cứ lúc nào. Bạn cần có mặt để giải thích ngay lập tức để không làm gián đoạn tiến độ.

3.2. BA trong Waterfall

Waterfall là mô hình truyền thống, mọi thứ diễn ra theo trình tự từ trên xuống dưới như một dòng thác. Nếu Agile là buffet thì Waterfall là một bữa tiệc cưới được lên thực đơn kỹ lưỡng từ cả tháng trước. Lúc này, BA lại cần:

  • Sự ổn định: Ưu điểm là bạn sẽ có một lộ trình rõ ràng, ít bị "xoay như chong chóng" bởi những thay đổi bất ngờ. Nhưng áp lực là bạn phải đúng ngay từ đầu. Nếu bạn phân tích sai ở bước này, toàn bộ "tòa nhà" dự án phía sau có thể bị đổ vỡ.Trong Waterfall, BA tập trung nhiều vào giai đoạn đầu của dự án:
  • Làm kỹ ngay từ đầu: Bạn có nhiệm vụ phải thu thập bằng hết các yêu cầu của khách hàng. Một khi đã chuyển sang giai đoạn lập trình, việc quay lại sửa yêu cầu là cực kỳ khó khăn và tốn kém.
  • Tài liệu là "vua": Bạn sẽ dành rất nhiều thời gian để viết những bộ tài liệu đặc tả (SRS) chi tiết đến từng chân tơ kẽ tóc. Tài liệu này giống như một bản cam kết giữa bên mua và bên bán.

4. Các công cụ thường dùng của BA

Đã có kỹ năng tốt thì không thể thiếu "vũ khí" xịn. Một BA chuyên nghiệp không chỉ làm việc bằng đầu óc mà còn phải biết tận dụng công nghệ để biến những ý tưởng phức tạp thành hình ảnh dễ hiểu.

Dưới đây là bộ "đồ nghề" mà bất kỳ BA nào cũng nên bỏ túi để làm việc nhanh hơn và trông "pro" hơn:

  • Công cụ vẽ sơ đồ: Draw.io, Visio, Lucidchart
  • Công cụ quản lý công việc: Jira, Trello, Azure DevOps
  • Công cụ viết tài liệu: Confluence, Notion, Google Docs
  • Công cụ prototype: Figma, Balsamiq
  • Công cụ quản lý dữ liệu hoặc phân tích đơn giản: Excel, Google Sheets
  • Công cụ giao tiếp và phối hợp: Slack, Microsoft Teams

Việc sử dụng thành thạo công cụ sẽ giúp BA làm việc nhanh hơn, rõ ràng hơn và chuyên nghiệp hơn rất nhiều. Tuy nhiên, lời khuyên là: "Đừng cố gắng giỏi tất cả công cụ cùng một lúc". Hãy bắt đầu bằng việc thành thạo Draw.io để vẽ quy trình, Jira để quản lý yêu cầu và một công cụ viết tài liệu như Confluence hoặc Notion. Khi đã vững tay chèo, các công cụ khác bạn sẽ học rất nhanh thôi.

Cũng cần lưu ý rằng công cụ chỉ là phương tiện. Điều quan trọng hơn là tư duy phân tích, cách đặt câu hỏi và khả năng làm rõ vấn đề. Một BA giỏi không phải vì biết nhiều tool, mà vì biết dùng đúng tool để phục vụ đúng mục tiêu.

5. Kỹ năng cần có của một Business Analyst

Để trở thành một BA giỏi, bạn không chỉ “biết làm” mà phải “làm đúng và làm tới nơi”. Vì vậy, BA cần kết hợp cả kỹ năng cứng và kỹ năng mềm.

5.1. Kỹ năng cứng

Về kỹ năng cứng, BA cần có tư duy phân tích logic để hiểu đúng vấn đề, hiểu cách tổ chức vận hành công việc (dù là phần mềm hay quy trình), biết viết tài liệu rõ ràng, sử dụng công cụ và có kiến thức domain (tài chính, thương mại, giáo dục,...).

  • Phân tích và tư duy logic
  • Hiểu cách hệ thống hoặc quy trình vận hành
  • Viết tài liệu
  • Sử dụng công cụ
  • Kiến thức domain

Điều đáng nói là BA không nhất thiết phải là người code giỏi, nhưng càng hiểu được cách hệ thống vận hành thì càng dễ làm việc với team kỹ thuật và càng dễ viết tài liệu chính xác.

5.2. Kỹ năng mềm

Kỹ năng mềm mới là yếu tố quyết định BA có “làm được việc” hay không. BA cần giao tiếp và lắng nghe tốt để tránh hiểu sai yêu cầu, biết đặt câu hỏi và phản biện để đào sâu insight, có tư duy hệ thống để nhìn được toàn bộ ảnh hưởng của một thay đổi, đồng thời quản lý stakeholder và giải quyết vấn đề một cách linh hoạt.

  • Giao tiếp và lắng nghe
  • Đặt câu hỏi và phản biện
  • Tư duy hệ thống
  • Quản lý stakeholder
  • Giải quyết vấn đề

Thực tế, rất nhiều người mới học BA thường tập trung quá nhiều vào tài liệu và công cụ, nhưng lại quên rằng BA là nghề làm việc với con người rất nhiều. Nếu bạn không thể hỏi đúng, nghe đúng, nói rõ và dung hòa được các bên, thì dù bạn hiểu nghiệp vụ đến đâu, dự án vẫn có thể đi lệch hướng.

6. Lộ trình phát triển nghề nghiệp của BA

BA là một vị trí có nhiều hướng phát triển linh hoạt. Dưới đây là lộ trình phổ biến bạn có thể tham khảo:

Điểm hay của nghề BA là bạn không bị đóng khung trong một con đường duy nhất. Tùy vào sở thích, điểm mạnh và môi trường làm việc, bạn có thể đi theo hướng sản phẩm, hướng quản lý, hướng tư vấn, hoặc trở thành chuyên gia nghiệp vụ trong một domain cụ thể.

7. Ai phù hợp để học và theo nghề BA?

BA là một nghề mở, không chỉ dành riêng cho dân IT. Trên thực tế, rất nhiều người đến với BA từ những nền tảng rất khác nhau.

Bạn có thể phù hợp với BA nếu bạn là:

  • Sinh viên hoặc người mới ra trường đang muốn tìm một vị trí có lộ trình rõ ràng trong môi trường doanh nghiệp
  • Người đi làm muốn chuyển ngành sang lĩnh vực công nghệ nhưng chưa muốn đi sâu vào lập trình
  • Dân vận hành, kinh doanh, CS, marketing, QA, tester... muốn mở rộng sang vai trò phân tích và phối hợp dự án
  • Người có kinh nghiệm trong một lĩnh vực cụ thể như tài chính, giáo dục, thương mại, logistics... và muốn tận dụng kiến thức domain để bước sang BA
  • Người thích phân tích, thích tìm hiểu vấn đề, thích làm việc với nhiều bên và muốn tạo ra tác động thực tế trong doanh nghiệp

Tất nhiên, BA không phải nghề “dễ” chỉ vì không cần code chuyên sâu. Đây là nghề đòi hỏi bạn phải vừa hiểu vấn đề, vừa hiểu con người, vừa có khả năng kết nối nhiều bộ phận. Nhưng nếu bạn thích suy nghĩ, thích giải quyết vấn đề và muốn phát triển lâu dài trong môi trường chuyên nghiệp, BA là một hướng đi rất đáng cân nhắc.

8. Kết luận

Business Analyst không chỉ là người “ghi nhận yêu cầu”, mà là người giúp doanh nghiệp giải quyết đúng vấn đề và xây dựng đúng giải pháp.

Trong bối cảnh doanh nghiệp ngày càng cần tối ưu vận hành và ra quyết định dựa trên dữ liệu, vai trò của BA ngày càng trở nên quan trọng, không chỉ trong ngành IT mà ở hầu hết các lĩnh vực.

Nếu bạn là người yêu thích việc giải mã những rắc rối, thích kết nối con người và đam mê việc tìm ra cách làm tốt hơn cho một vấn đề, BA chính là một lựa chọn phù hợp.

Hãy bắt đầu từ việc rèn luyện tư duy logic và kỹ năng đặt câu hỏi ngay hôm nay. Chúc bạn thành công trên con đường trở thành một BA thực thụ.

Project Manager – Ngành nghề cực hot AI chưa thể đe dọa

Project Manager – Ngành nghề cực hot AI chưa thể đe dọa

Trong bối cảnh AI đang “càn quét” hàng loạt ngành nghề, từ content, thiết kế cho đến lập trình, không ít người bắt đầu hoang mang: Liệu công việc của mình có còn tồn tại trong 3–5 năm tới?

Nhưng có một sự thật thú vị mà nhiều người chưa nhận ra: càng tự động hóa mạnh mẽ, doanh nghiệp lại càng cần những người điều phối, ra quyết định và chịu trách nhiệm tổng thể. Và đó chính là lý do vì sao Project Manager (PM) không chỉ chưa bị thay thế, mà còn trở thành một trong những vị trí “khát nhân lực” nhất hiện nay.

Bài viết này sẽ không chỉ giúp bạn hiểu đúng về nghề PM, mà còn “đập tan” những hiểu lầm phổ biến, từ đó mở ra một hướng đi rõ ràng – đặc biệt nếu bạn đang là sinh viên, người trái ngành hoặc đang muốn bước vào lĩnh vực Business Analyst (BA) / Product.

Thiếu hụt nhân lực Project Manager – Không phải xu hướng, mà là thực tế

Nhiều người nghĩ rằng PM là vị trí “cao cấp”, phải có hàng chục năm kinh nghiệm mới làm được. Điều này đúng một phần, nhưng lại khiến rất nhiều người bỏ lỡ cơ hội.

Thực tế, thị trường hiện nay không chỉ thiếu Senior PM, mà còn thiếu cả những người có nền tảng bài bản để phát triển lên vị trí này.

Khi doanh nghiệp ngày càng chuyển đổi số, số lượng dự án tăng lên nhanh chóng, kéo theo nhu cầu về những người có thể quản lý tiến độ, kiểm soát rủi ro, giao tiếp giữa các bên liên quan. Nhưng nghịch lý ở đây là: rất nhiều người làm việc trong dự án, nhưng lại không hiểu rõ quy trình chuẩn, không có tư duy hệ thống, dẫn đến việc “làm nhiều nhưng không lên được”.

Đặc biệt tại Việt Nam, làn sóng outsourcing và product development khiến nhu cầu PM trong lĩnh vực IT, fintech, edtech… tăng mạnh. Nhưng nguồn nhân lực đáp ứng được yêu cầu – vừa hiểu nghiệp vụ, vừa có tư duy quản lý – lại không nhiều.

Điều này mở ra một cơ hội lớn cho những ai đi đúng hướng ngay từ đầu.

Vì sao Project Manager có mức lương hấp dẫn?

Một trong những lý do khiến PM trở thành “nghề mơ ước” là mức thu nhập vượt trội so với mặt bằng chung. Nhưng nếu chỉ nhìn vào con số, bạn sẽ dễ hiểu sai bản chất.

PM không được trả lương cao vì họ “quản lý người khác”, mà vì họ chịu trách nhiệm cho toàn bộ kết quả của dự án.

Một dự án thất bại không chỉ là trễ deadline. Nó có thể kéo theo mất khách hàng, thiệt hại hàng trăm triệu đến hàng tỷ đồng, ảnh hưởng đến uy tín doanh nghiệp. Và người đứng giữa tất cả những áp lực đó chính là PM.

Để làm được điều này, PM cần kết hợp nhiều kỹ năng mà hiếm vị trí nào có đủ: từ tư duy logic, phân tích nghiệp vụ, giao tiếp đa phòng ban, cho đến khả năng ra quyết định trong điều kiện thiếu thông tin.

Đó là lý do vì sao mức lương của PM không chỉ phản ánh kỹ năng, mà còn phản ánh mức độ ảnh hưởng và trách nhiệm.

Đập tan hiểu lầm: PM không phải là “người giao việc”

Một trong những hiểu lầm phổ biến nhất là: PM chỉ là người chia task và theo dõi tiến độ.

Nếu bạn vẫn nghĩ như vậy, rất có thể bạn đang nhìn thấy một “phiên bản sai” của PM.

Một Project Manager đúng nghĩa phải hiểu được “tại sao” đằng sau mỗi đầu việc, chứ không chỉ là “làm cái gì”. Họ cần nắm rõ mục tiêu kinh doanh, hiểu người dùng, và đảm bảo rằng toàn bộ dự án đang đi đúng hướng.

Điều này khiến PM có mối liên hệ rất chặt chẽ với Business Analyst (BA). Trên thực tế, rất nhiều PM giỏi bắt đầu từ BA, bởi họ đã có sẵn tư duy phân tích, khả năng làm rõ yêu cầu và giao tiếp với stakeholder.

Nếu bạn đang hướng đến BA hoặc Product Owner, thì việc hiểu PM không chỉ là một lựa chọn, mà là một lợi thế cạnh tranh rất lớn.

Vì sao AI chưa thể thay thế Project Manager?

AI có thể viết code, tạo nội dung, phân tích dữ liệu. Nhưng có một thứ mà AI vẫn chưa thể làm tốt: hiểu con người trong bối cảnh phức tạp.

Project Manager không chỉ làm việc với dữ liệu, mà còn làm việc với con người – mỗi người một mục tiêu, một cách suy nghĩ, một áp lực khác nhau.

Khi một developer bị quá tải, khi khách hàng thay đổi yêu cầu vào phút chót, khi team xảy ra mâu thuẫn… đó không phải là những bài toán có công thức.

PM cần đưa ra quyết định dựa trên kinh nghiệm, trực giác và khả năng đọc tình huống. Họ cần thương lượng, thuyết phục, đôi khi là “giữ lửa” cho cả team trong những giai đoạn khó khăn.

AI có thể hỗ trợ PM trong việc tổng hợp thông tin, dự báo rủi ro hay tối ưu quy trình. Nhưng vai trò cốt lõi của PM – kết nối con người và dẫn dắt dự án đi đến kết quả – vẫn là thứ chưa thể tự động hóa.

Nói cách khác, AI không thay thế PM. Nó chỉ khiến những PM giỏi trở nên mạnh hơn, và những người không có nền tảng sẽ bị đào thải nhanh hơn.

Con đường trở thành Project Manager: Không như bạn nghĩ

Nhiều người nghĩ rằng muốn làm PM phải bắt đầu từ developer. Nhưng thực tế, có rất nhiều con đường khác – đặc biệt là thông qua Business Analyst.

BA chính là “cầu nối” giữa business và kỹ thuật, là người làm rõ yêu cầu, phân tích vấn đề và đảm bảo sản phẩm được xây dựng đúng nhu cầu.

Khi bạn đã có nền tảng BA, việc chuyển sang PM trở nên tự nhiên hơn rất nhiều. Bạn không chỉ hiểu dự án đang làm gì, mà còn hiểu vì sao nó tồn tại.

Đây cũng là lý do vì sao BA được xem là một trong những bước đệm tốt nhất để tiến lên các vị trí như Project Manager hoặc Product Owner.

Tuy nhiên, vấn đề của nhiều người mới là: học rất nhiều nhưng không có hệ thống, hiểu rời rạc và khó áp dụng vào thực tế. Điều này khiến họ mất nhiều thời gian mà vẫn không tiến xa được.

Học BA từ đầu – Bước đi chiến lược để vào ngành IT và tiến tới PM

Nếu bạn đang là sinh viên năm cuối, người mới ra trường, hoặc đang làm trái ngành và muốn chuyển sang IT, thì việc bắt đầu với BA là một lựa chọn thực tế và hiệu quả.

Không giống như lập trình, BA không yêu cầu bạn phải có nền tảng kỹ thuật sâu ngay từ đầu. Thay vào đó, bạn cần tư duy phân tích, khả năng đặt câu hỏi và hiểu cách một hệ thống vận hành.

Tuy nhiên, để đi nhanh và đúng hướng, bạn cần một lộ trình rõ ràng và môi trường thực hành đủ tốt.

Khóa học BA cho người mới bắt đầu tại VietIS Education được thiết kế dành riêng cho những người chưa có nền tảng, nhưng muốn đi nghiêm túc với nghề.

Trong khoảng 8 tuần học, bạn sẽ được xây dựng nền tảng từ tư duy đến công cụ, hiểu rõ quy trình làm BA trong thực tế. Quan trọng hơn, bạn không chỉ học lý thuyết mà còn được tham gia 2 tháng OJT – nơi bạn làm việc như một BA thực thụ dưới sự hướng dẫn của mentor.

Điểm khác biệt lớn nhất nằm ở việc chương trình được dẫn dắt bởi những người đang làm dự án thực tế. Điều này giúp bạn không chỉ “biết”, mà còn “làm được” – yếu tố quan trọng nhất khi đi phỏng vấn hoặc bắt đầu công việc.

Khóa học cũng không giới hạn trong lĩnh vực IT, mà áp dụng được cho nhiều ngành khác nhau, từ fintech, thương mại điện tử cho đến giáo dục.

Kết luận: PM không biến mất – nhưng cơ hội không dành cho tất cả

Project Manager là một trong những nghề hiếm hoi vừa có thu nhập tốt, vừa có khả năng phát triển dài hạn trong thời đại AI.

Nhưng điều đó không có nghĩa là ai cũng có thể trở thành PM.

Cơ hội chỉ dành cho những người có nền tảng đúng, tư duy rõ ràng và biết cách phát triển bản thân một cách chiến lược.

Nếu bạn đang đứng ở vạch xuất phát, hoặc đang loay hoay tìm hướng đi trong ngành IT, thì việc bắt đầu với Business Analyst có thể là bước đi thông minh nhất.

Không phải vì nó “dễ”, mà vì nó giúp bạn hiểu bản chất của dự án – thứ sẽ theo bạn suốt cả sự nghiệp, dù bạn trở thành PM, Product Owner hay bất kỳ vai trò nào khác.

Và nếu bạn cần một lộ trình rõ ràng, có người hướng dẫn và môi trường thực hành thực tế, thì VietIS Education là một điểm bắt đầu đáng cân nhắc.