Trở thành Quality Assurance (QA) trong công ty phần mềm

Chương 1 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Mở đầu Chương 1 (giới thiệu khóa học), bài này làm rõ khóa học dành cho ai. Khóa được xây dựng từ kinh nghiệm thực chiến của giảng viên, hướng tới cả người mới lẫn người đã đi làm trong ngành QA.

─── SAU BÀI HỌC, BẠN SẼ

• Xác định được mình có phải đối tượng phù hợp của khóa học không.
• Hiểu khóa học phục vụ cả người chưa biết gì lẫn người đã làm QA.
• Biết cách liên hệ giảng viên khi gặp thắc mắc trong lúc học.

─── NỘI DUNG CHÍNH

▸ 1. Khóa học dành cho ai

Khóa học được tạo ra dựa trên kinh nghiệm thực chiến của giảng viên, nhắm tới hai nhóm chính:

• Người chưa có khái niệm gì về ngành QA, vị trí QA: học xong vẫn có thể hiểu, thực hành và làm được công việc.
• Người đã làm trong ngành QA nhưng chưa nắm rõ hết vai trò, cần tìm hiểu chi tiết cách vị trí này hoạt động trong công ty phần mềm.

▸ 2. Hỗ trợ trong quá trình học

Trong lúc học, nếu có thắc mắc hay gặp vấn đề, bạn liên hệ trực tiếp với giảng viên qua nhóm hỗ trợ để được giải đáp và hiểu rõ hơn. Đây là kênh xuyên suốt khóa học, nên đừng ngại đặt câu hỏi khi cần.

Chương 1 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài này đưa ra vài quy định cơ bản để bạn học hiệu quả cùng giảng viên, và hướng dẫn cách tham gia group hỗ trợ. Nắm đúng cách học ngay từ đầu sẽ giúp bạn không bỏ lỡ tài liệu và luôn có nơi để hỏi khi bí.

─── SAU BÀI HỌC, BẠN SẼ

• Nắm được bốn nguyên tắc học tập mà giảng viên khuyến nghị.
• Biết tận dụng đầy đủ template, checklist, guideline được chia sẻ.
• Biết cách join vào group hỗ trợ bằng đường link hoặc mã QR code.

─── NỘI DUNG CHÍNH

▸ 1. Bốn nguyên tắc học tập

Để theo khóa học hiệu quả, bạn nên:

1. Học tập, nghiên cứu nghiêm túc theo bài.
2. Đặt câu hỏi ngay khi có chỗ chưa hiểu trong quá trình học.
3. Sử dụng toàn bộ template, checklist, guideline mà giảng viên chia sẻ, thay vì chỉ nghe lý thuyết.
4. Tham gia group hỗ trợ để đặt câu hỏi và trao đổi.

▸ 2. Cách tham gia group hỗ trợ

Trong bài có sẵn một đường link kèm QR code để bạn vào group nhanh chóng: quét mã hoặc mở link ở trên. Khi tham gia, bạn sẽ ở cùng nhóm với các học viên khác của khóa, giảng viên và người hỗ trợ — nơi bạn có thể hỏi đáp trực tiếp trong suốt quá trình học.

Chương 1 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Ở thị trường Việt Nam, hai vị trí QA và QC rất hay bị nhầm lẫn — nhiều tin tuyển dụng còn gộp chung làm một. Bài học tách bạch rõ hai vai trò: QA hướng về quy trình của công ty, còn QC hướng về sản phẩm của dự án. Nắm được ranh giới này, bạn sẽ hiểu mình đang ứng tuyển vào đúng công việc nào và trách nhiệm của mình tới đâu.

─── SAU BÀI HỌC, BẠN SẼ

• Phân biệt được QA và QC qua đối tượng công việc: quy trình so với sản phẩm.
• Hiểu vì sao QA mang tính tổng quan còn QC mang tính chi tiết.
• Nhận ra điểm chung: cả hai đều phục vụ một mục tiêu là nâng cao chất lượng.

─── NỘI DUNG CHÍNH

▸ 1. QA hướng về quy trình, QC hướng về sản phẩm

Điểm mấu chốt để phân biệt là đối tượng mà mỗi vị trí "soi" vào.

• QA (Quality Assurance) kiểm soát quy trình làm việc của cả công ty. Ví dụ: mỗi sáng nhóm có họp daily 15 phút không, có sinh ra output đúng quy định không; khi bàn giao cho khách theo hợp đồng thì bộ tài liệu A, B, C đã đủ chưa. Thiếu một tài liệu trong danh mục cam kết là QA sẽ ghi nhận vấn đề.
• QC (Quality Control) — cũng chính là vị trí tester — kiểm tra sản phẩm cụ thể. Ví dụ: test phần mềm xem có lỗi không, lỗi thì báo và theo dõi việc sửa.

▸ 2. Tổng quan so với chi tiết

QA làm việc ở tầm tổng quan hơn: nhìn vào cả guồng máy quy trình, chuẩn mực chung của tổ chức. QC làm việc chi tiết hơn rất nhiều: bám sát từng tính năng, từng ca kiểm thử trên một sản phẩm nhất định. Một bên đứng ở "hàng rào quy trình", một bên đứng ngay tại "mặt trận sản phẩm".

▸ 3. Mẹo ghi nhớ nhanh

Chỉ cần nhớ một câu: QA hướng về công ty (quy trình), QC hướng về dự án (sản phẩm) — nhưng cả hai gặp nhau ở cùng một đích đến là nâng cao chất lượng. Nếu muốn đào sâu, bạn tham khảo thêm tài liệu so sánh QA/QC mà giảng viên đính kèm trong bài.

Chương 1 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Từ trải nghiệm làm QA và trực tiếp lấy chứng nhận ISO cho công ty, giảng viên đúc kết những kỹ năng thiết yếu mà một QA cần có. Nắm được danh sách này, bạn biết mình cần rèn luyện gì để làm tốt vai trò đảm bảo chất lượng.

─── SAU BÀI HỌC, BẠN SẼ

• Biết những kỹ năng cốt lõi mà vị trí QA cần trang bị.
• Hiểu vì sao hiểu biết về quy trình phần mềm lại quan trọng với QA.
• Nắm được khái niệm KPI dự án và số NORM ở mức tổng quan.

─── NỘI DUNG CHÍNH

▸ 1. Kỹ năng công cụ và quy trình

Theo giảng viên, một QA cần trước hết là các kỹ năng nền tảng:

• Excel và Google Sheet (Spreadsheet) — để thống kê, phân tích số liệu.
• Hiểu quy trình phần mềm — biết các quy trình để có thể ngăn chặn, kiểm soát quá trình thực thi và nâng cao chất lượng.

▸ 2. Chỉ số KPI và số NORM

Hai khái niệm quan trọng với QA:

• KPI của dự án và tổ chức: mỗi dự án nằm trong công ty sẽ "ăn theo" các KPI mà công ty giao xuống; QA cần theo dõi xem dự án có đạt các KPI đó không.
• Số NORM: là một con số cơ bản (chuẩn tham chiếu) của dự án trong phần mềm; dựa trên số NORM này để đánh giá và điều chỉnh với khách hàng. Các bài sau của khóa sẽ đi sâu vào NORM và Quality Metrics.

Nếu trong lúc học có chỗ chưa hiểu, bạn liên hệ giảng viên qua group hỗ trợ để được giải đáp.

Chương 1 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài này giới thiệu tài liệu tổng hợp thuật ngữ trong ngành QA — một "từ điển" các khái niệm bạn sẽ gặp thường xuyên khi làm dự án. Tài liệu được giảng viên giải thích ngắn gọn, dễ hiểu và cập nhật liên tục khi có thuật ngữ mới.

─── SAU BÀI HỌC, BẠN SẼ

• Biết nơi tra cứu tài liệu thuật ngữ QA được giảng viên tổng hợp sẵn.
• Làm quen với một số thuật ngữ nền tảng thường gặp trong dự án.
• Biết cách đề nghị bổ sung thuật ngữ mới khi cần.

─── NỘI DUNG CHÍNH

▸ 1. Tài liệu thuật ngữ dùng chung

Giảng viên chuẩn bị sẵn một đường link dẫn tới tài liệu tổng hợp thuật ngữ ngành QA, với các khái niệm được giải thích đơn giản để bạn dễ nắm. Tài liệu này được publish công khai cho học viên và update liên tục: khi bạn gặp một thuật ngữ mới trong dự án mà chưa hiểu, cứ hỏi trên group — giảng viên sẽ giải thích và bổ sung vào tài liệu.

▸ 2. Một số thuật ngữ tiêu biểu

Vài nhóm khái niệm bạn sẽ thấy trong tài liệu:

• Yếu tố dự án: scope (phạm vi công việc), time (thời gian, timeline), cost (chi phí), quality (chất lượng).
• Vòng cải tiến: Plan, Do, Check, Action.
• Thuật ngữ chuyên ngành offshore và tài liệu: OSDC (Offshore Software Development Center), Program Design, Detail Design, High-Level Design, Unit Test Case, Unit Test Report...

Đây là những khái niệm nền, sẽ được dùng lại xuyên suốt các chương sau, nên bạn cứ mở tài liệu ra tra khi gặp từ lạ.

Chương 1 · Bài 6

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Xuyên suốt khóa học, giảng viên sẽ dùng chung một đề bài dự án mẫu để minh họa mọi thao tác QA. Bài học này giới thiệu đề bài đó — cụ thể là một file báo giá dự án — để bạn nắm trước bối cảnh, nhờ đó các bài sau về kiểm soát quy trình và chất lượng đều dễ hiểu hơn. Điểm mấu chốt cần nhớ: một báo giá tốt luôn được xây trên hai chân: yếu tố của khách hàng và yếu tố của chính tổ chức bạn.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vì sao cả khóa dùng chung một dự án demo, và bạn nên bám theo nó khi thực hành.
• Đọc được cấu trúc cơ bản của một file báo giá dự án phần mềm.
• Thấy được vai trò của QA khi kiểm tra một báo giá trước khi nó được gửi cho khách hàng.

─── NỘI DUNG CHÍNH

▸ 1. Đề bài demo là một file báo giá dự án

File chia sẻ trong bài chính là một báo giá thực tế. Trong đó có các thông tin nền của tổ chức: sơ đồ tổ chức công ty, sơ đồ tổ chức dự án (ai là BM, ai là các vai trò khác), phân loại dự án lớn hay nhỏ, các chỉ số cần monitor, và các loại báo cáo phải làm định kỳ (weekly, monthly). Về phía dự án cụ thể, báo giá ghi: khách hàng, ngày bắt đầu, thông tin môi trường, các file cần xử lý, thiết kế theo website nào, điều kiện thanh toán, contract, và WBS (Work Breakdown Structure) — bảng phân rã công việc kèm giá tiền từng phần.

▸ 2. Báo giá dựa trên hai yếu tố: khách hàng và tổ chức

Người làm báo giá (thường là sales hoặc BM) phải hiểu cả quy trình + sơ đồ tổ chức của công ty mình lẫn yêu cầu của khách hàng. Loại hợp đồng cũng chi phối cách viết: fixed rate thì khách chỉ quan tâm giá phù hợp, còn OSDC thì bắt buộc ghi rõ skill để tạo niềm tin. Nếu cứ "add đại" mọi thứ mà không bám tổ chức, chi phí dễ bị phình sai — dự án nhỏ mà tính như dự án lớn thì không hợp lý.

▸ 3. Vai trò của QA với báo giá

Tùy công ty, báo giá có thể phải đi qua QA kiểm tra. Khi đó QA soát lại: tên khách hàng có đúng không, forecast có đúng không, nội dung có phù hợp quy trình tổ chức không — đạt thì báo giá mới được gửi đi. Bạn hãy mở link file mẫu giảng viên đính kèm để xem một báo giá dự án trông ra sao.

Chương 2 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Với vị trí QA, Excel và Google Sheet là công cụ làm việc hằng ngày — bạn dùng chúng để thống kê số liệu và làm báo cáo chất lượng. Bài học định hướng cách học Google Sheet cho đúng trọng tâm: bạn không cần thành thạo mọi tính năng, mà chỉ cần nắm vững một nhóm hàm cơ bản đủ để phục vụ mục tiêu thống kê và báo cáo.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vì sao Google Sheet (và Excel) là kỹ năng nền tảng của một QA.
• Biết trọng tâm cần học là gì: các hàm phục vụ thống kê, báo cáo — không cần học lan man.
• Biết nơi tham khảo khóa học Google Sheet riêng mà giảng viên đã quay sẵn.

─── NỘI DUNG CHÍNH

▸ 1. Google Sheet và Excel dùng để làm gì trong QA

Google Sheet về bản chất tương tự Excel (bài trước đã giới thiệu Excel). Với QA, mục tiêu duy nhất khi dùng hai công cụ này là thống kê và làm báo cáo — chẳng hạn tổng hợp số liệu bug, test case, tính các chỉ số chất lượng của dự án. Vì vậy khi học, bạn hãy luôn gắn thao tác với câu hỏi "số liệu này sẽ vào báo cáo nào".

▸ 2. Học gì cho đủ và học ở đâu

Điểm đáng nhớ: số lượng function cần dùng không nhiều. Bạn chỉ cần nắm vững vài hàm cơ bản như `SUM`, các hàm thống kê, cùng thao tác lọc/tổng hợp dữ liệu là đã đủ dùng cho công việc QA. Giảng viên có quay sẵn một khóa học Google Sheet riêng, đi khá chi tiết: phân tích dữ liệu, giới thiệu các hàm cơ bản rồi đến hàm nâng cao. Bạn hãy bấm vào link được đính kèm trong bài để vào khóa đó và tham khảo khi cần đào sâu.

Chương 2 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học cho bạn thấy đích đến của kỹ năng Excel/Spreadsheet: một báo cáo phân tích chất lượng dự án hoàn chỉnh. Để đi từ dữ liệu thô đến báo cáo đó, giảng viên giới thiệu một quy trình phân tích dữ liệu 6 bước. Nắm được quy trình này, bạn sẽ biết mọi con số mình gõ vào bảng tính đều nhằm trả lời một câu hỏi cụ thể, chứ không phải làm cho có.

─── SAU BÀI HỌC, BẠN SẼ

• Hình dung được sản phẩm đầu ra (output) mà bạn có thể tự làm sau khóa học.
• Nắm quy trình phân tích dữ liệu 6 bước: Ask, Prepare, Process, Analyse, Share, Action.
• Hiểu vì sao phân tích dữ liệu luôn bắt đầu từ việc đặt câu hỏi.

─── NỘI DUNG CHÍNH

▸ 1. Sản phẩm đầu ra: báo cáo phân tích chất lượng dự án

Giảng viên đưa trước một báo cáo mẫu — thứ bạn sẽ có thể tự làm sau chương này — để bạn thấy kết quả và có thêm hứng thú học. Báo cáo tổng hợp các số liệu chất lượng của một dự án: số bug đã đề xuất, số bug theo từng dòng/khu vực, tổng số bug, công nghệ và framework sử dụng, số lượng dòng code, so sánh với tiêu chuẩn chất lượng của công ty. Nhìn vào đó, bạn biết được chất lượng sản phẩm đang nằm ở đâu.

▸ 2. Quy trình phân tích dữ liệu 6 bước

Toàn bộ quá trình đi qua sáu bước:

1. Ask — đặt câu hỏi: đây là nguyên tắc đầu tiên, phải xác định mình đang muốn trả lời điều gì (tại sao số liệu lại như thế này, thế kia).
2. Prepare — chuẩn bị dữ liệu.
3. Process — xử lý dữ liệu.
4. Analyse — phân tích dữ liệu.
5. Share — chia sẻ kết quả, kể lại "câu chuyện" của số liệu cho mọi người.
6. Action — đưa ra hành động phù hợp dựa trên kết quả.

▸ 3. Điểm mấu chốt: mọi phân tích bắt đầu từ câu hỏi

Điều đáng nhớ nhất là bước Ask. Chính câu hỏi định hướng bạn lấy dữ liệu gì, xử lý ra sao và phân tích theo hướng nào. Bạn hãy tham khảo tài liệu báo cáo mẫu giảng viên làm trong dự án thực tế để thấy sáu bước này được áp dụng cụ thể như thế nào.

Chương 2 · Bài 4.1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Mọi dự án phần mềm đều được định hình bởi bốn yếu tố cốt lõi: Time, Cost, Scope và Quality. Đây là "tam giác quản trị dự án" mà một QA phải kiểm soát. Điểm mấu chốt cần nhớ: bốn yếu tố này ràng buộc lẫn nhau — siết chặt cái này thường phải nới cái kia, nên rất hiếm khi giữ được trọn cả bốn. Hiểu được điều đó, khi vào một dự án đang "cháy", bạn sẽ phán đoán được vấn đề nằm ở yếu tố nào.

─── SAU BÀI HỌC, BẠN SẼ

• Gọi tên và giải thích được bốn yếu tố Time, Cost, Scope, Quality của dự án.
• Hiểu quan hệ đánh đổi giữa chúng và thế nào là một dự án "thành công".
• Biết dùng bốn yếu tố này làm khung để chẩn đoán một dự án đang gặp trục trặc.

─── NỘI DUNG CHÍNH

▸ 1. Bốn yếu tố cốt lõi

• Cost — chi phí dự án: bao nhiêu người, bao nhiêu tiền, đều phải ước lượng.
• Time — thời gian thực hiện: từ ngày nào đến ngày nào kết thúc.
• Scope — phạm vi công việc: chỉ coding, chỉ testing, hay có cả deployment cho khách hàng.
• Quality — chất lượng: được định nghĩa bằng số liệu, ví dụ với bấy nhiêu dòng code thì có bao nhiêu test case và bao nhiêu bug tương ứng.

Một dự án chỉ được xem là được định nghĩa đầy đủ khi có đủ cả bốn yếu tố; thiếu một trong bốn là dự án đang có vấn đề.

▸ 2. Quan hệ đánh đổi và định nghĩa "thành công"

Một dự án thành công là dự án không vượt chi phí (Cost), giao đúng hạn (Time), nằm trong Scope đã cam kết và đảm bảo Quality. Nhưng thực tế thường không giữ nổi cả bốn — giữ được 3/4 hay 2/4 đã là tốt. Ví dụ khi ưu tiên rút ngắn Time để giao sớm, bạn buộc phải tăng người (đội Cost lên), trong khi người mới chưa quen việc khiến Quality giảm, thậm chí phải cắt bớt Scope. Đây chính là bản chất đánh đổi giữa bốn yếu tố.

▸ 3. Ví dụ dễ nhớ và ứng dụng cho QA

Hãy hình dung ai đó rủ bạn "có 300 triệu, mở quán cà phê nhé" — 300 triệu mới chỉ là Cost. Muốn thành một dự án thật, phải định nghĩa thêm: mở ở đâu, khi nào mở (Time), khách hàng mục tiêu là ai, cà phê thuộc phân khúc nào (Scope, Quality). Với QA, khi vào kiểm tra một dự án đang cháy — thường biểu hiện đầu tiên là giao không kịp (Time) — bạn dùng khung bốn yếu tố để soi xem Cost, Quality, Scope đang lệch ở đâu và tại sao.

Chương 2 · Bài 4.2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Mỗi dự án đều đi qua một vòng đời gồm các giai đoạn (process group) nối tiếp nhau. Bài học giới thiệu vòng đời đó gồm năm nhóm: Initiating → Planning → Executing → Monitoring & Controlling → Closing. Điểm mấu chốt cần nhớ: Planning và Executing là hai giai đoạn lặp đi lặp lại, và trong suốt quá trình đó lúc nào cũng phải có Monitoring & Controlling để dự án bám đúng kế hoạch.

─── SAU BÀI HỌC, BẠN SẼ

• Kể tên và hiểu ý nghĩa của năm giai đoạn trong vòng đời một dự án.
• Hiểu vì sao Monitoring & Controlling diễn ra song song, xuyên suốt chứ không phải một bước riêng lẻ.
• Nắm được các đầu việc cơ bản ở giai đoạn khởi tạo và giai đoạn đóng dự án.

─── NỘI DUNG CHÍNH

▸ 1. Năm giai đoạn của vòng đời dự án

1. Initiating — khởi tạo dự án: lấy requirement từ khách hàng, ký hợp đồng, assign người PM, xác định danh sách dự án, thống kê khách hàng... còn ở mức sơ khai.
2. Planning — lập kế hoạch: dựa trên thông tin khởi tạo, phân rã công việc chi tiết cho các hoạt động bên trong như coding, testing.
3. Executing — thực thi: triển khai kế hoạch đã lập, rồi review, verify các sản phẩm làm ra.
4. Monitoring & Controlling — giám sát và kiểm soát: theo dõi, quan sát tiến độ rồi điều chỉnh cho phù hợp.
5. Closing — đóng dự án: bàn giao (deliver) cho khách hàng và tổng kết.

▸ 2. Monitoring & Controlling là mạch chạy xuyên suốt

Planning và Executing mang tính lặp lại — làm kế hoạch, thực thi, kiểm tra rồi lại điều chỉnh kế hoạch. Trong toàn bộ quá trình đó, bạn không bao giờ đảm bảo mọi thứ đúng 100% ngay, nên phải liên tục monitoring (theo dõi, quan sát) và controlling (kiểm soát, điều chỉnh). Mỗi ngày bạn tracking dự án để giữ nó bám đúng kế hoạch đã đề ra.

▸ 3. Giai đoạn đóng dự án (Closing)

Khi đã deliver cho khách hàng, dự án bước vào Closing. Đây là lúc làm thủ tục tổng kết: đóng toàn bộ ticket, thống kê kết quả, rút ra bài học kinh nghiệm (những thành tựu đạt được, những điều làm tốt hay chưa tốt) rồi lưu lại cho công ty dùng cho các dự án sau. Bên trong giai đoạn này còn nhiều đầu việc nhỏ chứ không đơn giản như tên gọi.

Chương 2 · Bài 4.2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bên cạnh vòng đời dự án, có một chu trình hoạt động lặp đi lặp lại trong mọi công việc: Plan → Do → Check → Action (PDCA). Bài học chia sẻ đây như một "tip" tư duy: bất cứ khi nào nhận một task, bạn hãy nhớ luôn có kế hoạch đi trước, rồi mới thực thi, kiểm tra và hành động khắc phục. Đây là khung tư duy cốt lõi mà người làm QA hay PM đều phải nằm lòng.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu ý nghĩa của bốn hoạt động Plan, Do, Check, Action và thứ tự của chúng.
• Biết vì sao "Action" chính là bước khắc phục khi kết quả lệch khỏi kế hoạch.
• Áp dụng được PDCA vào công việc verify, kiểm soát một dự án thực tế.

─── NỘI DUNG CHÍNH

▸ 1. Bốn hoạt động Plan, Do, Check, Action

• Plan — kế hoạch: xác định trước sẽ làm gì, kiểm tra gì. Làm mà không có kế hoạch thì không lường trước được, không kiểm soát được tiến độ.
• Do — thực thi: bắt tay thực hiện đúng những gì đã lên kế hoạch.
• Check — kiểm tra: đối chiếu kết quả thực tế với kế hoạch ban đầu.
• Action — hành động: khi Check phát hiện kết quả không đúng với Plan, bạn phải có hành động cụ thể để khắc phục, kéo mọi thứ về đúng kế hoạch.

▸ 2. Áp dụng PDCA vào công việc QA

Giả sử công ty giao bạn vào verify xem một dự án đang tiến tới đâu, có vấn đề gì không. Bạn áp PDCA như sau: Plan — ngày đầu xác định sẽ kiểm tra về Time, Cost, Quality, Scope để đánh giá dự án có ổn không; Do — đến ngày đó vào dự án, lấy data thật của dự án ra kiểm tra; Check — soát toàn bộ số liệu, phát hiện chỗ nào đang tốn thời gian, tốn chi phí; Action — tìm lý do và đề xuất hành động cụ thể, đưa vào báo cáo.

▸ 3. Điểm mấu chốt: kế hoạch luôn đi trước

Điều đáng nhớ nhất là Plan luôn đứng đầu. Hầu như mọi việc trong dự án đều đi theo chu trình này, và nó lặp lại xuyên suốt. Chỉ cần ghi nhớ đúng bốn chữ Plan, Do, Check, Action theo thứ tự, bạn đã có một khung làm việc chắc chắn cho vai trò QA.

Chương 2 · Bài 4.4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Waterfall là mô hình phát triển phần mềm lâu đời nhất: các giai đoạn nối tiếp nhau theo một chiều duy nhất, như thác nước đổ xuống và không chảy ngược lên. Bài học giúp bạn hiểu các giai đoạn của Waterfall cùng ưu, nhược điểm của nó. Điểm mấu chốt cần nhớ: Waterfall mạnh khi yêu cầu rõ ràng, ít thay đổi, nhưng rất yếu khi cần đổi giữa chừng — vì mỗi thay đổi buộc bạn quay lại từ đầu.

─── SAU BÀI HỌC, BẠN SẼ

• Kể được các giai đoạn của quy trình Waterfall theo đúng thứ tự.
• Phân tích được ưu, nhược điểm và biết khi nào nên chọn Waterfall.
• Hiểu vì sao Waterfall xử lý sự thay đổi kém và điều đó ảnh hưởng gì tới QA.

─── NỘI DUNG CHÍNH

▸ 1. Các giai đoạn của Waterfall

Quy trình chạy tuần tự qua sáu giai đoạn:

1. Analysis — phân tích requirement của khách hàng, từng ly từng tí.
2. Design — thiết kế, làm tài liệu thiết kế màn hình chi tiết.
3. Development — phát triển, code toàn bộ các màn hình.
4. Testing — kiểm thử một lần cho tất cả màn hình.
5. Deployment — triển khai cho khách hàng.
6. Maintenance — bảo trì.

Đặc trưng là làm theo chiều ngang: hoàn tất trọn vẹn một giai đoạn rồi mới sang giai đoạn kế tiếp.

▸ 2. Ưu điểm và nhược điểm

Ưu điểm: vì phân tích toàn bộ requirement và scope ngay từ đầu, bạn xác định được budget của dự án ngay lần đầu tiên, đồng thời hạn chế tối đa sự thay đổi. Nhược điểm: thời gian để cho ra sản phẩm đưa ra thị trường khá lâu — có khi 6-7 tháng, thậm chí 1-2 năm. Với các startup muốn sản phẩm ra nhanh để nhận phản hồi thực tế, Waterfall là quá chậm (khi đó người ta chọn Agile/Scrum, sẽ nói ở bài sau).

▸ 3. Khi nào nên dùng và lưu ý về thay đổi

Hãy nhớ đơn giản: cái gì phân tích, xác định được toàn bộ ngay từ đầu thì hợp với Waterfall. Mô hình này vẫn được dùng rất nhiều, kể cả các ngành như xây dựng — nơi người ta không muốn thay đổi và đã thiết kế rất kỹ. Nhưng cạm bẫy lớn nhất là chi phí thay đổi: nếu đang ở giai đoạn Testing mà phát sinh thay đổi, bạn phải quay lại phân tích, thiết kế, code rồi test lại từ đầu. Với vai trò QA, hiểu điều này giúp bạn lường trước rủi ro khi dự án Waterfall có yêu cầu thay đổi giữa chừng.

Chương 2 · Bài 4.5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

V-Model là phiên bản mở rộng của Waterfall: nó chia nhỏ giai đoạn testing và ghép mỗi mức test với một mức thiết kế tương ứng, tạo thành hình chữ V. Điểm mấu chốt cần nhớ: mỗi loại tài liệu thiết kế sẽ có một loại kiểm thử đối ứng — hiểu được các cặp này, khi dự án release, bạn biết ngay đang ở loại test nào và cần verify cái gì.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu V-Model là bản mở rộng của Waterfall và khác ở điểm nào.
• Ghép được từng mức thiết kế với mức kiểm thử tương ứng (unit, integration, system, acceptance).
• Biết ai đảm nhận từng loại test, đặc biệt là sự khác biệt của Acceptance test.

─── NỘI DUNG CHÍNH

▸ 1. Bản chất: mở rộng phần testing của Waterfall

V-Model giữ nguyên tinh thần tuần tự của Waterfall nhưng tách giai đoạn testing thành nhiều mức. Mỗi mức test bám vào một mức thiết kế: mức thiết kế càng chi tiết thì test càng nhỏ, mức thiết kế càng tổng quát (high level) thì test càng bao quát.

▸ 2. Các cặp thiết kế – kiểm thử

• Module design / Detail design ↔ Unit testing: thiết kế chi tiết một màn hình (lấy field nào, database nào, validation ra sao) đối ứng với unit test — chỉ kiểm ở đơn vị một màn hình.
• Software design ↔ Integration testing: thiết kế ở mức liên kết giữa các màn hình, đối ứng với integration test — kiểm sự liên kết giữa các màn hình.
• System ↔ System testing: với hệ thống lớn có liên kết giữa nhiều hệ thống, dùng system test.
• Requirement ↔ Acceptance testing: nghiệm thu dựa trên requirement ban đầu.

▸ 3. Ai test và ý nghĩa với QA

Unit, Integration và System testing thường do tester đảm nhận. Riêng Acceptance testing là do khách hàng/người dùng test để nghiệm thu sản phẩm dựa trên requirement ban đầu — bên tester của mình không làm phần này. Với vai trò QA, hiểu quy trình V-Model giúp bạn biết một bản release đang ở loại test nào, từ đó verify lại xem sản phẩm có ra đúng theo quy trình phần mềm và đạt chuẩn chất lượng của công ty hay không.

Chương 2 · Bài 4.6

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Scrum là mô hình phát triển phần mềm dựa trên Agile, hiện được áp dụng rất phổ biến. Khác hẳn Waterfall, điểm mạnh cốt lõi của Scrum là welcome to change — luôn chấp nhận và chủ động ứng phó với thay đổi thay vì từ chối. Sản phẩm được giao theo từng Sprint ngắn (2–4 tuần), nên tốc độ deliver nhanh hơn nhiều. Bài học giới thiệu ba vai trò chính và luồng hoạt động cơ bản của Scrum.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vì sao Scrum chấp nhận thay đổi và giao sản phẩm nhanh hơn Waterfall.
• Phân biệt ba vai trò: Product Owner, Scrum Master, Development Team.
• Nắm luồng hoạt động: Product Backlog → Sprint Planning → Daily → Sprint Review.

─── NỘI DUNG CHÍNH

▸ 1. Product Backlog và ba vai trò chính

Product Backlog là nơi chứa toàn bộ tính năng của sản phẩm, mỗi tính năng được định nghĩa thành từng item kèm độ ưu tiên (cao/thấp, cái nào làm trước). Hãy tưởng tượng làm phần mềm cho một chiếc remote: mỗi nút là một chức năng, tất cả được liệt kê trong backlog. Ba vai trò cần nhớ:

• Product Owner — người được khách hàng tin tưởng, có quyền quyết định về sản phẩm; đưa các item vào Product Backlog.
• Scrum Master — hướng dẫn, đốc thúc team chạy đúng quy trình. Lưu ý: Scrum Master không phải PM, không có quyền ép team làm theo ý mình.
• Development Team — những người trực tiếp làm ra sản phẩm.

▸ 2. Luồng hoạt động trong một Sprint

Từ Product Backlog, team bóc các item vào một Sprint kéo dài 2–4 tuần để deliver nhanh nhất có thể. Trong Sprint có: Sprint Planning (lên kế hoạch), Daily Meeting — họp đứng (stand-up) khoảng 15 phút, mỗi người trả lời 3 câu: hôm qua làm gì, sắp tới làm gì, có issue gì không; và cuối cùng là Sprint Review — tổng kết, rút bài học để tăng năng suất. Ngoài ba vai trò chính còn có Stakeholder — những người liên quan (HR, SA, IT, admin...) ảnh hưởng trực tiếp hoặc gián tiếp tới dự án.

▸ 3. Nguyên tắc trong một Sprint và ưu điểm

Trong một Sprint đang chạy: không thay đổi (no change) phạm vi đang làm, Quality không được giảm, còn Product Backlog thì được redefine liên tục — tính năng nào không phù hợp thì đưa lại vào backlog cho Sprint sau. Mọi thay đổi về Scope phải negotiate với Product Owner. Ưu điểm của Scrum: welcome to change và deliver nhanh (mỗi 2–4 tuần đã bao gồm cả code lẫn test), trong khi Waterfall phải làm hết theo hàng ngang nên giao rất chậm. Muốn học sâu hơn, bạn tham khảo khóa quản lý dự án và trang scrum.org.

Chương 2 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Project Plan là tài liệu kế hoạch tổng thể mà PM lập sau khi khách hàng chấp nhận đề xuất, ghi lại mọi thứ liên quan tới Time, Scope, Cost, Quality của dự án. Với vai trò QA, nhiệm vụ của bạn là kiểm tra file này xem có hợp lý hay không. Điểm mấu chốt cần nhớ: muốn review đúng, bạn phải hiểu rõ từng sheet bên trong — file mẫu của giảng viên có tới 13 sheet.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu Project Plan là gì, do ai lập và lập vào lúc nào trong dự án.
• Nắm được các nhóm thông tin chính chứa trong một Project Plan.
• Biết cách QA soát tính hợp lý của file, ví dụ phát hiện mâu thuẫn về ngày tháng.

─── NỘI DUNG CHÍNH

▸ 1. Project Plan là gì và vai trò của QA

Khi khách hàng gửi dự án, bên bạn estimation rồi proposal phương án; khách chốt xong thì PM lập Project Plan. Đây chỉ là một mẫu tham khảo (13 sheet) — công ty khác có thể dùng Google Docs, Excel hay kiến trúc riêng. Nhiệm vụ QA là review tính hợp lý. Ví dụ điển hình: ngày create file ghi là hôm nay, nhưng review date lại là hôm trước — tức "review xong trước cả khi tạo file" — đó là một điểm bất hợp lý bạn phải bắt được.

▸ 2. Các nhóm thông tin chính trong Project Plan

• Overview: tên và mã dự án, contract type, khách hàng, unit thực hiện, yêu cầu khách hàng, phạm vi (in-scope/out-of-scope), sản phẩm deliverable, các ràng buộc và giả định, điều kiện để dự án chạy được.
• Scope & môi trường: các giai đoạn (design, coding, unit test, integration test...), version tài liệu, môi trường framework/database/test.
• Deliverables, Risk & Issue: sản phẩm bàn giao theo ngày, các rủi ro và vấn đề cần xử lý, vai trò trách nhiệm từng bên.

▸ 3. Sheet chất lượng và chiến lược thực hiện

Sheet Quality rất quan trọng: định nghĩa các quality metric sẽ đo, kèm cận trên và cận dưới (ngưỡng %). Bài có nhắc chỉ số YY = Bill / Calendar — số người khách hàng trả tiền chia số người thực tế bạn bỏ vào dự án; YY càng cao nghĩa là dùng ít người so với bill, càng thấp là dùng nhiều người hơn (liên quan tới Cost). Ngoài ra còn có sheet chiến lược thực hiện (resource allocation, communication plan với các loại meeting daily/weekly/milestone), sơ đồ tổ chức và CM Plan (Configuration Management Plan) — quy ước quản lý cấu hình cho các công cụ như Git, SVN, Redmine. Các chỉ số quality metric chi tiết sẽ có video riêng.

Chương 2 · Bài 6.1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Sau khi đã có Project Plan ở tầm chiến lược, bạn cần một thứ chi tiết hơn để thật sự quản lý được công việc hằng ngày — đó là Detail Schedule (lịch trình chi tiết). Bài học giải thích Detail Schedule là gì và vì sao mọi dự án muốn kiểm soát chặt đều phải có nó. Điểm mấu chốt: muốn biết dự án đang ở đâu và chạy như thế nào, bạn phải phân rã công việc lớn thành nhiều công việc rất nhỏ để theo dõi.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu Detail Schedule là gì và khác gì với kế hoạch tổng thể (master schedule).
• Nắm được lý do bắt buộc phải phân rã công việc mới quản lý được dự án.
• Hình dung được các nội dung sẽ học ở những bài tiếp theo của chủ đề lịch trình chi tiết.

─── NỘI DUNG CHÍNH

▸ 1. Detail Schedule là gì

Detail Schedule chính là lịch trình chi tiết của dự án — bảng liệt kê đầy đủ những đầu việc nhỏ cần làm để hoàn thành dự án. Nếu master schedule là bức tranh ở mức rất lớn (đi từ điểm A đến điểm B vào ngày 30/4), thì Detail Schedule chia nhỏ chính chặng A đến B đó ra: chuẩn bị xe, đặt phòng, chuẩn bị tiền... Mỗi việc lớn được tách thành nhiều việc con cụ thể, đủ nhỏ để giao và theo dõi được.

▸ 2. Vì sao bắt buộc phải có Detail Schedule

Khi làm một dự án, muốn quản lý chặt chẽ và biết dự án đang tiến tới đâu, bạn không thể chỉ nhìn vào các mốc lớn. Bạn phải phân rã khối lượng công việc lớn thành các đầu việc rất nhỏ. Chính nhờ những đầu việc nhỏ này mà bạn mới đo được tiến độ, phân bổ được người làm và phát hiện sớm chỗ chậm trễ.

▸ 3. Những gì sẽ học tiếp theo

Chủ đề lịch trình chi tiết gồm nhiều phần nối tiếp nhau: các yếu tố cấu thành một Detail Schedule, cách tạo lịch trình bằng Microsoft Project, và cách đưa lịch trình lên hệ thống quản lý dự án. Bài này chỉ giới thiệu khái niệm và lý do; các thao tác cụ thể sẽ được hướng dẫn trong những video ngay sau đó.

Chương 2 · Bài 6.2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài trước bạn đã biết Detail Schedule là gì; bài này đi sâu vào các thành phần cấu tạo nên một lịch trình chi tiết. Điểm mấu chốt cần nhớ: lịch trình chi tiết thực chất là bảng liệt kê rõ mỗi người, mỗi ngày cần làm việc gì — nhờ đó cả nhóm đi đúng hướng còn người quản trị luôn biết dự án đang ở đâu.

─── SAU BÀI HỌC, BẠN SẼ

• Kể được bốn yếu tố cốt lõi của một dòng công việc trong Detail Schedule.
• Hiểu vì sao khi mới lập kế hoạch thì mọi task đều ở trạng thái new và chưa có số liệu actual.
• Biết Detail Schedule liên kết thế nào với biểu đồ burn-down để theo dõi tiến độ.

─── NỘI DUNG CHÍNH

▸ 1. Bốn yếu tố của một đầu việc

Sau khi đã có estimation ban đầu và Project Plan, bạn lên lịch trình chi tiết cho từng công việc. Mỗi đầu việc trong Detail Schedule cần đủ bốn yếu tố:

1. Tên công việc (task).
2. Effort dự kiến — khối lượng công sức ước tính cho công việc đó.
3. Người thực hiện (assignee).
4. Kế hoạch ngày bắt đầu và ngày kết thúc.

Nhờ mức chi tiết này, developer biết hôm nay code màn hình nào rồi unit test, còn tester biết viết test case cho màn hình nào — mọi người phối hợp trơn tru hơn.

▸ 2. Đọc mẫu Detail Schedule

Trong file mẫu, mỗi task gắn với dự án nào, tracker là gì, thuộc file/màn hình nào, người làm là ai và khi nào xong. Lưu ý cột actual ban đầu sẽ trống: lúc mới lập kế hoạch, dự án chưa chạy nên mọi trạng thái đều là new và chưa có số liệu thực tế. Actual chỉ được điền dần khi công việc bắt đầu được thực hiện.

▸ 3. Liên kết với biểu đồ burn-down

Từ bảng lịch trình, bạn có thêm một sheet dạng graph liên quan tới burn-down — cho thấy khối lượng công việc còn lại đang giảm ra sao theo thời gian. Đây là cách trực quan để nhìn xem dự án có đang bám sát kế hoạch hay không. Nắm chắc các yếu tố ở bài này là nền tảng để bước sang phần tạo lịch trình bằng công cụ và đưa lên hệ thống quản lý.

Chương 2 · Bài 6.3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Có Detail Schedule rồi, bạn cần một công cụ để tính ra ngày bắt đầu — ngày kết thúc thực tế cho từng người, có tính cả ngày nghỉ và ràng buộc giữa các công việc. Bài học hướng dẫn dùng Microsoft Project để làm việc đó. Điểm mấu chốt: trước khi đưa vào tool, bạn phải cân bằng khối lượng effort giữa các developer cho hợp lý, rồi mới để Microsoft Project tự tính lịch.

─── SAU BÀI HỌC, BẠN SẼ

• Cài đặt được Microsoft Project và nắm những chức năng cơ bản cần dùng.
• Cân đối effort giữa các thành viên trước khi lên lịch, tránh người quá tải người quá rảnh.
• Thiết lập được task, người thực hiện, số giờ, ngày nghỉ và ràng buộc để tool tự tính ngày start/finish.

─── NỘI DUNG CHÍNH

▸ 1. Chuẩn bị: tải công cụ và cân bằng effort

Giảng viên có để sẵn đường dẫn tải Microsoft Project; bạn cài đặt rồi tham khảo thêm hướng dẫn sử dụng trên YouTube vì tính năng rất nhiều, bài chỉ đi phần cơ bản. Trước tiên, từ file estimation, bạn dùng hàm UNIQUE để lấy danh sách từng developer và hàm SUMIF để cộng tổng effort mỗi người. Vẽ thêm một column chart sẽ thấy ngay ai đang gánh quá nhiều — ví dụ Dev 3 chiếm tỷ trọng cao — để san sẻ bớt việc sang người còn rảnh, nhưng lưu ý phải phù hợp với năng lực của người nhận.

▸ 2. Đưa dữ liệu vào Microsoft Project

Tạo một plan mới, dán (copy/paste) các task vào. Chuyển Task Mode sang Auto để tool tự tính lịch. Sau đó điền Resource Name (tên người thực hiện) và số giờ vào cột thời lượng — nhớ quy ước nhập đúng đơn vị giờ thay vì mặc định là ngày.

▸ 3. Ngày nghỉ và ràng buộc giữa các task

Vào Project → Change Working Time để khai báo ngày nghỉ (lễ 30/4, 1/5, thứ Bảy, Chủ nhật) trên standard calendar; tool sẽ tự tránh những ngày này khi tính lịch. Bạn cũng đặt ràng buộc thứ tự: một task chỉ bắt đầu khi các task phụ thuộc đã xong. Khi khai báo đủ, Microsoft Project tự tính ngày start/finish, rồi bạn copy dữ liệu này quay lại bảng lịch trình. Cuối cùng, hãy chú ý chiến lược lên task (theo hàng ngang hay hàng dọc) và đừng quên những task không tên như setup môi trường, release, dịch tài liệu, review test case — chúng cũng phải nằm trong kế hoạch.

Chương 2 · Bài 6.4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Khi đã lên xong danh sách công việc trong spreadsheet, bạn cần đẩy toàn bộ lên hệ thống quản lý dự án (ở đây là Redmine) thay vì gõ tay từng issue. Bài học chỉ hai cách làm nhanh: dùng chức năng import file CSV có sẵn của Redmine, và dùng một công cụ viết bằng Google Sheets để đồng bộ hai chiều. Điểm mấu chốt: mọi hệ thống (Redmine, Jira, Backlog...) đều có import/export hoặc API, nên cách làm này áp dụng được ở đâu cũng vậy.

─── SAU BÀI HỌC, BẠN SẼ

• Import được danh sách công việc lên Redmine bằng file CSV.
• Biết mẹo lấy đúng template CSV bằng cách tạo một ticket mẫu rồi export.
• Hiểu vì sao dùng API/công cụ riêng giúp cập nhật hàng loạt issue nhanh hơn thao tác tay.

─── NỘI DUNG CHÍNH

▸ 1. Import bằng file CSV

Vào dự án trên Redmine, chọn chức năng Import, trỏ tới file CSV rồi map các cột (subject, assignee, start/end date, tracker, status, estimated time, % done...) cho khớp với trường của Redmine, cuối cùng bấm Import. Để có đúng cấu trúc file, mẹo là tạo trước một ticket mẫu trên Redmine rồi export ra CSV để lấy template — sau đó bạn chỉ việc điền dữ liệu công việc của mình vào đúng các cột đó.

▸ 2. Lưu ý về dữ liệu trước khi import

Khi mới lập kế hoạch, bỏ cột ID (chưa có), đặt status = new và % done = 0 cho mọi task. Với các trường phân cấp như assignee/depth, tên người và nhóm phải đã tồn tại trên Redmine trước; nếu chưa có, bạn phải tạo tài khoản/nhóm tương ứng, nếu không giá trị sẽ bị null khi import. Nhớ format lại cột ngày cho đúng định dạng.

▸ 3. Công cụ đồng bộ hai chiều bằng Google Sheets

Ngoài import, giảng viên còn giới thiệu một công cụ tự viết chạy trên Google Sheets, kết nối Redmine qua API. Nó cho phép get issue (kéo toàn bộ dữ liệu dự án về sheet), update những dòng đã chọn ngược lên Redmine, và bắn issue mới lên hệ thống rồi nhận lại ID. Cách này giúp bạn sửa và cập nhật hàng loạt issue nhanh gọn, đồng thời kéo data về để làm báo cáo. Nguyên tắc tương tự áp dụng được với Jira, Backlog hay bất kỳ hệ thống nào có API.

Chương 2 · Bài 7.1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Khi nói đến quản lý dự án, hầu hết project manager đều dùng một hệ thống nào đó để theo dõi công việc. Bài học giới thiệu Redmine — một công cụ mã nguồn mở (open source) khá ổn để quản lý dự án. Điểm mấu chốt cần nhớ: công cụ nào cũng quản lý được dự án, quan trọng là chọn công cụ phù hợp với dự án, với nhóm và với tình huống; và với vai trò QA, mục tiêu không phải là xây Redmine mà là dùng Redmine để kiểm soát dự án.

─── SAU BÀI HỌC, BẠN SẼ

• Biết Redmine là gì và vị trí của nó giữa các công cụ như Google Sheets, Jira.
• Hiểu Redmine dùng để quản lý những gì trong một dự án phần mềm.
• Xác định đúng vai trò của QA: kiểm soát dự án trên Redmine, không phải dựng hệ thống.

─── NỘI DUNG CHÍNH

▸ 1. Redmine là công cụ gì

Redmine là một hệ thống quản lý dự án mã nguồn mở. Người quản lý có thể dùng nhiều công cụ khác nhau — Google Sheets, spreadsheet, Jira, Redmine... — nhưng sẽ chọn cái phù hợp nhất cho từng dự án và từng nhóm. Redmine được đánh giá là một lựa chọn tương đối ổn trong nhóm open source, dùng để quản lý task, issue, Q&A, báo cáo (report), change request (CR) và nhiều loại thông tin khác của dự án.

▸ 2. Redmine trong hệ sinh thái của khóa học

Trong khóa học, Redmine không đứng một mình mà được liên kết với Google Sheets, Slack và cả hệ thống quản lý mã nguồn. Sự kết nối này cho phép tự động kéo dữ liệu ra để phân tích và làm báo cáo chất lượng — điều sẽ được dùng ở các chương sau khi QA kiểm tra quy trình dự án. Giảng viên cũng có sẵn một hệ thống Redmine đã dựng để học viên tham khảo và thực hành.

▸ 3. Vai trò của QA với Redmine

Nếu bạn theo hướng QA, mục tiêu không phải là học cách xây dựng một hệ thống Redmine (việc đó dành cho một khóa riêng về dựng Redmine miễn phí mà giảng viên có đề cập). Điều bạn cần là biết cách quản lý và kiểm soát dự án trên Redmine: theo dõi công việc, kiểm tra xem quy trình dự án có tuân thủ chuẩn của công ty hay không. Bài tiếp theo sẽ đi chi tiết hơn vào các tính năng của hệ thống này.

Chương 2 · Bài 7.2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Nối tiếp bài giới thiệu, bài này đi sâu hơn vào lý do chọn Redmine và cho bạn nhìn thực tế giao diện một hệ thống Redmine đã dựng sẵn. Điểm mấu chốt: Redmine là công cụ theo dõi vấn đề (issue tracking) mã nguồn mở, chi phí thấp, phù hợp với nhiều quy mô công ty, và có thể cài thêm plugin, cấu hình lại cho vừa với đặc thù từng dự án.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vì sao Redmine phù hợp cho cả công ty nhỏ lẫn công ty vài trăm người.
• Biết Redmine có thể tùy biến bằng plugin và cấu hình theo nhu cầu dự án.
• Nắm cách được cấp tài khoản để vào hệ thống Redmine của giảng viên và thực hành.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao dùng Redmine

Redmine là phần mềm miễn phí, mã nguồn mở, đúng nghĩa một công cụ theo dõi các vấn đề (issue tracking) của dự án. Vì open source nên chi phí dựng rất thấp. Nó cho phép quản lý bằng Gantt chart, quản lý chi tiết từng issue rất rõ ràng. Theo kinh nghiệm của giảng viên, Redmine hợp với công ty vừa và nhỏ (dưới 100 người), nhưng cũng có những công ty 300–400 người vẫn dùng tốt.

▸ 2. Tùy biến bằng plugin và cấu hình

Ở các công ty lớn, bản Redmine thường được tùy biến (customize): cài thêm một số plugin rồi cấu hình lại cho phù hợp với đặc thù dự án. Nhờ khả năng mở rộng này, cùng một nền Redmine có thể phục vụ nhiều loại dự án khác nhau. Trong khóa học riêng về dựng Redmine, giảng viên hướng dẫn từ đầu đến cuối, gồm cả việc tích hợp hệ thống quản lý vào.

▸ 3. Trải nghiệm hệ thống thực tế

Giảng viên đã setup sẵn một hệ thống Redmine để học viên thực hành. Bạn có thể đăng ký qua group Zalo hỗ trợ của khóa học để được cấp tài khoản, sau đó đăng nhập vào và tự trải nghiệm. Trên giao diện, ngoài quản lý issue theo dự án (ISO), hệ thống còn tích hợp các phần như khu vực chat và wiki — giúp bạn hình dung một môi trường quản lý dự án hoàn chỉnh trông ra sao trước khi đi vào các bài kiểm soát chất lượng.

Chương 2 · Bài 8

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Trong quản lý chất lượng có một bộ 7 công cụ cơ bản (7 QC tools) giúp bạn phân tích và cải thiện chất lượng của quy trình. Bài học điểm qua cả bảy công cụ, tập trung giải thích ba công cụ được dùng nhiều nhất. Điểm mấu chốt: mỗi công cụ giải quyết một kiểu vấn đề khác nhau, và trong thực tế QA thường xuyên dùng nhất là sơ đồ xương cá, check sheet và control chart.

─── SAU BÀI HỌC, BẠN SẼ

• Gọi tên được đủ 7 công cụ cơ bản trong quản lý chất lượng.
• Biết dùng sơ đồ xương cá để truy tìm nguyên nhân gốc (root cause) của một vấn đề.
• Hiểu ý nghĩa của check sheet và control chart trong kiểm soát chất lượng.

─── NỘI DUNG CHÍNH

▸ 1. Danh sách 7 công cụ

Bảy công cụ gồm: sơ đồ xương cá (Cause-and-Effect / Ishikawa diagram), check sheet (phiếu kiểm tra), control chart (biểu đồ kiểm soát), histogram, Pareto chart, scatter diagram (biểu đồ phân tán) và stratification (phân tầng). Giảng viên có đính kèm link tài liệu và template có sẵn công thức để bạn tải về tham khảo. Trong thực tế, giảng viên chủ yếu dùng ba công cụ đầu; các công cụ còn lại ít khi dùng đến.

▸ 2. Ba công cụ dùng nhiều nhất

• Sơ đồ xương cá: khi gặp một vấn đề, bạn vẽ các nhánh xương cá ứng với những thành phần tạo nên vấn đề, rồi chia nhỏ dần để tìm ra nguyên nhân gốc (root cause).
• Check sheet: hoạt động như một checklist — bạn đánh dấu vào từng mục cần kiểm tra, đơn giản nhưng hiệu quả.
• Control chart: biểu đồ có cận trên và cận dưới. Bạn chấp nhận một độ sai lệch nhất định so với giá trị chuẩn; nếu số đo nằm trong khung đó thì sản phẩm được xem là bình thường, ra ngoài khung là bất thường.

▸ 3. Histogram và các công cụ ít dùng

Histogram cho thấy sự phân bố của dữ liệu. Các công cụ còn lại (Pareto chart, scatter diagram, stratification) hầu như ít được dùng trong thực tế công việc của giảng viên. Nếu bạn có kinh nghiệm dùng chúng, đây là cơ hội tốt để chia sẻ và học hỏi lẫn nhau. Quan trọng là hiểu mỗi công cụ phù hợp với tình huống nào để chọn đúng khi cần.

Chương 2 · Bài 9

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Checklist là một trong 7 công cụ cơ bản; bài này giới thiệu một checklist lớn hơn, chuyên dụng cho QA, gọi là PCV (Process Check Verification). Điểm mấu chốt: PCV là tập hợp toàn bộ checklist về quy trình của dự án, giúp QA kiểm tra và chấm điểm theo tuần xem dự án có tuân thủ đúng quy trình công ty từ lúc khởi tạo đến lúc kết thúc hay không.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu PCV là gì và vai trò của nó trong việc giám sát quy trình dự án.
• Biết cách chấm điểm từng hạng mục (0 / 50 / 100) và khi nào phải tạo issue để theo dõi.
• Nắm phương pháp verify bằng phỏng vấn để xác nhận quy trình có được thực hiện thật hay không.

─── NỘI DUNG CHÍNH

▸ 1. PCV là gì và cấu trúc file

PCV gom tất cả checklist liên quan tới quy trình dự án vào một chỗ, trải theo các giai đoạn: initiation → planning → executing → monitoring → closing. File gồm nhiều sheet, mỗi sheet ứng với một Process; mỗi dòng gồm Process ID, tên process, sub-process và hạng mục cần kiểm tra. Có bốn Rule Set chính, trong đó Rule Set đầu tiên liên quan tới performance management — quản lý yêu cầu khách hàng.

▸ 2. Cách chấm điểm và tạo issue

Với mỗi hạng mục, QA đánh giá theo từng tầng của dự án: đạt = 100 điểm, có làm nhưng chưa đúng = 50 điểm, không làm = 0 điểm. Trung bình các hạng mục ra điểm của process. Với bất kỳ hạng mục nào bị 0 hoặc 50 điểm, bạn bắt buộc phải tạo (log) một issue lên hệ thống quản lý, ghi rõ lý do và yêu cầu dự án khắc phục, rồi tracking đến khi xong.

▸ 3. Verify bằng phỏng vấn

Điểm quan trọng: QA không tin "miệng nói đã làm" mà phải verify. Phương pháp là phỏng vấn. Ví dụ với hạng mục "PM đã nắm và truyền đạt yêu cầu khách hàng chưa", bạn phỏng vấn cả PM lẫn thành viên: hỏi member có thấy tài liệu ruleset chưa, có hiểu dự án cần deliver gì không. Nếu PM biết mà member không biết, nghĩa là PM chưa transfer dự án xuống — hạng mục đó bị 50 điểm. Chấm điểm mỗi tuần như vậy giúp công ty đánh giá dự án có bám quy trình không, làm cơ sở tính KPI và điểm thưởng.

Chương 3 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học đưa ra bức tranh tổng thể về một quy trình ISO của công ty và chỉ rõ những "cổng" mà QA cần tham gia (join) vào để kiểm tra chất lượng trong suốt vòng đời dự án. Điểm mấu chốt: hầu như mỗi khâu tạo ra output đều phải đi qua chu trình Plan – Do – Check – Action, và bước Check chính là chỗ QA vào cuộc. Lưu ý mỗi công ty có quy trình riêng, đây chỉ là một ví dụ tham khảo.

─── SAU BÀI HỌC, BẠN SẼ

• Hình dung được 5 giai đoạn của dự án và điểm QA cần kiểm tra ở mỗi giai đoạn.
• Hiểu QA kiểm soát chất lượng dựa trên thông tin khách hàng, kế hoạch và quy trình công ty.
• Biết vì sao sơ đồ quy trình phải điều chỉnh theo đặc thù từng công ty, không áp dụng máy móc.

─── NỘI DUNG CHÍNH

▸ 1. Năm giai đoạn của dự án

Quy trình chạy qua các khâu: khởi tạo → lập kế hoạch → thực thi → đóng gói/bàn giao sản phẩm → đóng dự án (tương ứng initiating, planning, executing, closing). Ở cột bên trái sơ đồ là các vai trò tham gia như BM, QC, QA, CC (Configuration Controller). Mỗi khâu tạo ra output đều có hình thoi "kiểm tra" — đó là điểm quyết định đạt thì đi tiếp, không đạt thì quay lại làm lại.

▸ 2. QA kiểm tra gì ở từng giai đoạn

• Khởi tạo: QA lấy Estimation, Proposal, thông tin từ Sales để kiểm tra thông tin chất lượng có đúng tiêu chí ban đầu không, rồi mới cho mở dự án.
• Theo dõi (monitoring & controlling): QA kiểm tra các chỉ số KPI như progress, quality, cost, scope xem dự án có bám plan không; lệch thì báo PM/SM điều chỉnh. Report này chạy bằng tool, phần lớn collect data tự động và gửi hằng tuần.
• Bàn giao: QA tham gia Final Inspection (FI) — kiểm tra sản phẩm đóng gói (source code, test case, design, deployment...) có đủ, đúng format, đủ nội dung và đạt chuẩn hay chưa.

▸ 3. Đóng dự án và lưu ý áp dụng

Ở giai đoạn đóng dự án, QA gửi file đánh giá cho khách hàng chấm điểm mức độ hài lòng, thu thập dữ liệu, rồi đóng gói và lưu trữ toàn bộ data dự án làm lịch sử cho các dự án sau tham khảo. Cuối cùng QA kiểm tra thông tin lần cuối trước khi bàn giao cho bộ phận IT/CC đóng dự án. Hãy nhớ: sơ đồ này tùy công ty, tùy tính chất dự án mà khác nhau — mục tiêu là thấy được bức tranh tổng thể của việc kiểm soát chất lượng, đừng áp dụng rập khuôn.

Chương 3 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu số NORM — bộ tiêu chuẩn chất lượng mà công ty đặt ra để đo đạc và đánh giá một sản phẩm phần mềm là ổn hay chưa ổn. Điểm mấu chốt dễ nhớ: số NORM giống hệt bảng chỉ số khi bạn đi xét nghiệm ở bệnh viện — mỗi chỉ số có cận trên, cận dưới; nằm trong khoảng là bình thường, vượt ra ngoài là bất thường cần soi kỹ.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu số NORM là gì và vì sao mỗi công ty tự định nghĩa bộ tiêu chuẩn riêng.
• Nắm được các thuật ngữ nền: KLOC, test case density, bug density, effort efficiency, CS...
• Biết cách đọc một bảng quality metrics (cận trên – trung bình – cận dưới) để phát hiện bất thường.

─── NỘI DUNG CHÍNH

▸ 1. Số NORM là gì

Số NORM là con số tiêu chuẩn của công ty, được rút ra từ việc lưu trữ và đo đạc lịch sử dữ liệu qua nhiều dự án. Không phải công ty nào cũng có; chỉ những nơi tích lũy data và có chuẩn mới định nghĩa được. Nhờ số NORM, câu hỏi mơ hồ như "lỗi nhiều hay ít" mới có định nghĩa cụ thể để phán đoán. Tiêu chuẩn cũng phân biệt theo loại hợp đồng, ví dụ OSDC (thanh toán theo tháng, giao việc tới đâu tính tới đó) khác với Fixed-price (chốt tổng số tiền, làm lời ăn lỗ chịu).

▸ 2. Các thuật ngữ nền cần nắm

Bảng tiêu chuẩn dùng nhiều thuật ngữ: KLOC/LOC (số dòng code — đơn vị nhỏ nhất), test case (UT, IT, UAT), bug (Bug UT, Bug IT), Effort Efficiency = buildable effort chia cho calendar effort, actual effort (gồm cả overtime), và CS (điểm khách hàng đánh giá mức độ hài lòng). Tất cả những chỉ số này đều được hướng dẫn cách đo ở các bài sau. Chúng cũng quy về đúng 4 yếu tố dự án: time, cost, quality, scope.

▸ 3. Đọc bảng Quality Metrics

Mỗi chỉ số có trung bình, cận dưới (Lower Control Limit), cận trên (Upper Control Limit) với một độ chênh cho phép. Ví dụ code review chuẩn 15 lỗi/1000 LOC, độ chênh 10%, tức cận dưới 13 – cận trên 17: bắt ít hơn cận dưới nghĩa là review sót lỗi, bắt nhiều hơn cận trên nghĩa là sản phẩm có vấn đề chất lượng. QA chỉ phát hiện (detect) bất thường từ số liệu, sau đó mới điều tra sâu để tìm root cause — y như bác sĩ thấy chỉ số lạ thì cho xét nghiệm chuyên sâu hơn. Lưu ý quan trọng: bộ chỉ số này phải được điều chỉnh và thống nhất khi khởi tạo mỗi dự án, không bê nguyên xi.

Chương 3 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Chất lượng của một dự án không phải đợi làm xong mới đi kiểm tra, mà phải soi ngay từ khâu đầu tiên là lập kế hoạch. Bài học hướng dẫn bạn cách QA review hai tài liệu cốt lõi của giai đoạn planning: Project Plan và Detailed Schedule. Điểm mấu chốt là bạn dùng một checklist tự xây, chia rõ hai nhóm tiêu chí: đúng format và đúng logic nội dung.

─── SAU BÀI HỌC, BẠN SẼ

• Biết lập checklist review kế hoạch với hai nhóm tiêu chí format và logic.
• Review được từng sheet của Project Plan và Detailed Schedule rồi comment đúng chỗ.
• Phân loại được ba dạng phát hiện của QA: lỗi, đề nghị cải thiện, và thiếu sót.

─── NỘI DUNG CHÍNH

▸ 1. Checklist review: format và logic

Trước khi review, bạn tự tạo một checklist liệt kê các tiêu chí cần kiểm tra và phân loại chúng (ví dụ: category, format, logic). Nhóm thứ nhất là format: font chữ có nhất quán không, có lỗi break link, đứt dòng, rớt chữ không. Nhóm thứ hai là logic: nội dung có hợp lý, có matching với requirement ban đầu của khách hàng và chuẩn của công ty không. Lưu ý các tiêu chí này thay đổi theo tính chất từng dự án, nên bạn phải điều chỉnh cho phù hợp.

▸ 2. Review từng sheet và comment lại

Bạn mở tài liệu, đi qua từng sheet (overview, scope, resource allocation, communication...) và đối chiếu. Ví dụ: requirement ghi không đầy đủ, scope không đúng, version tài liệu bị thiếu, hay Detailed Schedule không né thứ bảy, chủ nhật và ngày lễ. Mỗi vấn đề bạn comment (audit) ngay trên tài liệu rồi gửi lại cho dự án fix.

▸ 3. Ba dạng phát hiện và vai trò thật của QA

Khi review, phát hiện của bạn rơi vào ba dạng: lỗi (tài liệu sai), đề nghị cải thiện theo quy trình công ty, và thiếu (cần bổ sung). Hãy nhớ: QA không phải người "bắt bẻ" gây khó, mà là người hỗ trợ dự án làm tốt hơn — vì QA nắm quy trình công ty rõ nhất. Sau khi được PM fix và bạn approve, kế hoạch đó phải thực sự được thực thi; mỗi tuần bạn dùng PCV để chấm điểm dự án và theo dõi.

Chương 3 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Sau khâu kế hoạch, tài liệu thiết kế (Design) là thứ tiếp theo QA phải kiểm soát trước khi nó được approve. Bài học chỉ bạn cách review tài liệu thiết kế theo hai nhóm tiêu chí quen thuộc — format và logic — đồng thời đo năng suất và chất lượng review dựa trên hai con số: số trang tài liệu và số lượng comment.

─── SAU BÀI HỌC, BẠN SẼ

• Review được tài liệu Design theo format (header, thông tin đầy đủ) và logic (đúng nghiệp vụ).
• Dùng chức năng insert comment của nhiều công cụ (Excel, Google Sheets, Word, PDF) để đánh dấu lỗi.
• Đo chất lượng khâu thiết kế bằng tỉ lệ số comment trên số trang tài liệu.

─── NỘI DUNG CHÍNH

▸ 1. Hai nhóm tiêu chí review tài liệu thiết kế

Mỗi tài liệu thiết kế được nhận về, bạn kiểm hai lớp. Format: các header đã đầy đủ chưa — tên system, mã màn hình, tên màn hình, người đối ứng, người review, người điều chỉnh, ngày tạo, ngày điều chỉnh cuối. Logic: nội dung đúng nghiệp vụ chưa — ví dụ chỗ định nghĩa input/output phải có ký hiệu tương ứng, dropdown list phải có đủ giá trị. Role QA không cần hiểu sâu toàn bộ nghiệp vụ, nhưng vẫn kiểm được tính đúng đắn và logic của tài liệu.

▸ 2. Dùng insert comment trên bất kỳ công cụ nào

Việc review được thực hiện bằng chức năng insert comment có sẵn ở hầu hết công cụ: Excel, Google Sheets, Word, hay PDF. Bạn click phải vào ô/chỗ cần bắt lỗi, chèn comment ghi rõ chỗ nào chưa đúng, rồi gửi lại cho người viết tài liệu sửa. Cách làm giống nhau ở mọi editor, nên bạn dùng công cụ nào cũng được.

▸ 3. Đo chất lượng bằng số page và số comment

Để định lượng, bạn đếm tổng số trang của tài liệu (ví dụ 21 page) và số comment phát sinh khi review. Từ đó đặt ra một chuẩn (NORM): mỗi trang tài liệu nên có khoảng bao nhiêu comment. Đối chiếu số thực tế với chuẩn này, bạn biết tài liệu thiết kế có đạt chất lượng hay không. Lưu ý: nếu dự án có 10 file thiết kế thì bạn phải review đủ cả 10 để đảm bảo chất lượng cả khâu Design.

Chương 3 · Bài 6

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đến khâu Coding, QA kiểm soát chất lượng bằng cách nhìn hai con số quan trọng: số dòng code (LOC) của từng màn hình và số lượng bug / comment review code phát sinh trên màn hình đó. Bài học chỉ bạn cách gom LOC theo màn hình, rồi so con số bug thực tế với chuẩn NORM để kết luận màn hình nào đạt, màn hình nào chưa đạt chất lượng.

─── SAU BÀI HỌC, BẠN SẼ

• Tổng hợp được LOC theo từng màn hình bằng hàm thống kê hoặc bằng tool đếm code.
• Tính được số bug kỳ vọng (NORM) từ LOC và chuẩn chất lượng của công ty.
• So sánh bug thực tế với cận trên / cận dưới để đánh giá chất lượng mỗi màn hình.

─── NỘI DUNG CHÍNH

▸ 1. Gom LOC về từng màn hình

Sau khi có kết quả đếm LOC cho từng file (đã hướng dẫn ở bài LOC riêng), bạn thêm một cột màn hình (screen name) để gán mỗi file thuộc màn hình nào — login, list, edit, user... Rồi tạo một sheet tổng kết: dùng hàm lấy danh sách màn hình duy nhất và hàm SUMIF để cộng LOC theo từng màn hình. Bạn cũng có thể dùng tool đếm code đã cấu hình sẵn để count nhanh theo màn hình, theo ngày và theo người.

▸ 2. Từ LOC suy ra số bug chuẩn (NORM)

Chuẩn chất lượng của công ty ví dụ: 1000 LOC thì có 15 bug review code. Với một màn hình 985 LOC, bạn lấy LOC chia 1000 rồi nhân 15, ra khoảng 14.7 và làm tròn thành 15 bug chuẩn. Đây là số bug kỳ vọng theo NORM cho màn hình đó.

▸ 3. Đặt cận trên, cận dưới và kết luận

Chỉ một con số NORM là chưa đủ, bạn tính thêm biên độ ±10%: lower control limit và upper control limit. Ví dụ NORM 15 bug thì cận dưới ≈ 14, cận trên ≈ 17. Đối chiếu bug thực tế: nếu màn hình login có 18 bug — vượt cận trên — thì màn hình đó không đạt chuẩn, cần review lại. Nếu bug thực tế thấp hơn cận dưới nghĩa là bắt bug chưa đủ so với NORM. Bạn kéo công thức xuống cho cả danh sách và tô màu để dễ nhìn, từ đó chặn lỗi sớm ngay ở khâu code, trước khi sang testing.

Chương 3 · Bài 7

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Ở khâu Testing, QA kiểm soát chất lượng qua hai loại số liệu: mật độ test case (số test case tạo ra so với LOC) và mật độ bug (số bug bắt được so với LOC). Điểm mấu chốt là bạn phải hiểu ba mức kiểm thử — unit test, integration test, user acceptance test — vì mỗi mức có chỉ số đo lường riêng, rồi so với NORM để biết khâu kiểm thử có đạt hay không.

─── SAU BÀI HỌC, BẠN SẼ

• Phân biệt được ba mức kiểm thử: unit test, integration test và user acceptance test.
• Suy ra số unit test case chuẩn từ LOC của mỗi màn hình theo NORM.
• Đánh giá chất lượng testing bằng cách so mật độ bug thực tế với chuẩn trên KLOC.

─── NỘI DUNG CHÍNH

▸ 1. Ba mức kiểm thử cần kiểm soát

Unit test kiểm ở mức đơn vị một màn hình; integration test kiểm nhiều màn hình ghép với nhau; user acceptance test là người dùng trực tiếp test. Mỗi mức có chỉ số đo lường khác nhau, nên khi kiểm soát chất lượng bạn phải tách riêng chỉ số cho từng mức chứ không gộp chung.

▸ 2. Mật độ test case (UTC density)

Danh sách file test case của dự án (thường viết trên Google Sheets) được import vào để bạn biết mỗi ngày, mỗi màn hình có bao nhiêu test case. Dựa trên LOC của từng mã màn hình và chuẩn chất lượng, bạn suy ra số unit test case kỳ vọng. So với thực tế: viết nhiều hơn chuẩn là dư, viết ít hơn là thiếu — cả hai đều là dấu hiệu cần xem lại.

▸ 3. Mật độ bug theo KLOC

Với bug, chuẩn ví dụ là 1000 LOC (KLOC) thì có 8 bug. Một màn hình 2000 LOC thì kỳ vọng khoảng 16 bug; nếu thực tế chỉ bắt được 5 bug thì đang thiếu bug — có thể test chưa kỹ. Ngược lại, bắt quá nhiều bug so với chuẩn chứng tỏ chất lượng sản phẩm có vấn đề. Bạn áp cùng cách đo này cho integration test và user acceptance test, dựa trên số lượng và phân loại bug từng giai đoạn, để kiểm soát trọn vẹn chất lượng khâu Testing. Các tool đo cụ thể đã được hướng dẫn ở những video riêng.

Chương 3 · Bài 8

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bug Rate (mật độ bug) là một chỉ số cốt lõi để đánh giá chất lượng phần mềm: nó cho biết cứ 1000 dòng code (KLOC) thì có bao nhiêu bug. Bài học chỉ bạn công thức tính mật độ bug, cách so con số thực tế với NORM (chuẩn), và quan trọng hơn — cách dùng thêm mật độ test case để nhìn ra bức tranh tương quan, thay vì chỉ nhìn một con số bug đơn lẻ.

─── SAU BÀI HỌC, BẠN SẼ

• Tính được mật độ bug bằng công thức số bug chia cho KLOC.
• So sánh mật độ bug thực tế với mật độ bug theo NORM để biết đang thừa hay thiếu bug.
• Dùng mật độ bug để dự đoán số bug của một function chưa test.

─── NỘI DUNG CHÍNH

▸ 1. Công thức tính mật độ bug

Mật độ bug = số lượng bug chia cho số LOC, rồi quy về 1000 LOC (KLOC). Ví dụ chuẩn NORM là 1000 LOC có 8 bug; với 983 LOC thì số bug chuẩn ≈ 7.8, làm tròn thành 8 bug. Bạn tính song song hai cột: mật độ bug theo NORM (kế hoạch) và mật độ bug thực tế, tô màu khác nhau cho dễ đối chiếu.

▸ 2. So sánh thực tế với NORM

Khi có hai con số, bạn so ngay: mật độ bug theo NORM là 8.1 trên 983 LOC, nhưng thực tế là 10.17 — nghĩa là cao hơn chuẩn. Bug thực tế cao hơn hoặc thấp hơn NORM đều đáng chú ý: cao hơn có thể do chất lượng code kém, còn thấp hơn thường là bắt bug chưa đủ so với chỉ tiêu.

▸ 3. Dùng mật độ bug để dự đoán và nhìn tương quan

Khi đã biết mật độ bug trung bình của dự án (ví dụ 6 bug trên 1000 LOC), bạn có thể dự đoán: một function 10.000 LOC chưa test sẽ phát sinh khoảng 60 bug. Đừng dừng ở mật độ bug — hãy đặt cạnh mật độ test case để đọc tương quan: bug nhiều mà test case ít, hay test case nhiều bug cũng nhiều... Mỗi kiểu tương quan hé lộ một vấn đề khác nhau ở từng màn hình. Đây là phần khó, nên trước hết bạn cần nắm nhận thức; khi làm thực tế phát sinh thắc mắc thì trao đổi thêm với giảng viên.

Chương 3 · Bài 9

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Final Inspection (FI) là bước kiểm tra cuối cùng toàn bộ thông tin của dự án ngay trước khi release, bàn giao cho khách hàng. Đây là round mà QA vào cuộc để rà lại một lần chót: sản phẩm giao có đúng cam kết không, tài liệu có đúng format và logic không. Bài học giới thiệu khái niệm FI, các tiêu chí kiểm tra, và hé lộ một công cụ tự viết giúp check FI nhanh hơn (sẽ demo ở bài kế tiếp).

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu Final Inspection là gì và vì sao nó là chốt chặn cuối trước khi giao khách hàng.
• Nắm các tiêu chí kiểm tra FI: format, logic và tính đúng với sản phẩm deliverable.
• Biết rằng có một tool riêng để check FI, sẽ được demo ở bài tiếp theo.

─── NỘI DUNG CHÍNH

▸ 1. Final Inspection là gì

FI chính là việc kiểm tra toàn bộ thông tin dự án ở khâu sau cùng, khi bạn chuẩn bị release và gửi cho khách hàng. Giai đoạn này QA là người zone vào để kiểm tra. Dù mỗi tài liệu đã được review lúc làm design, nhưng đến khúc cuối vẫn cần một round rà soát lần chót — và đó là round của QA.

▸ 2. Các tiêu chí kiểm tra FI

Tiêu chí không phức tạp. Thứ nhất, với mỗi tài liệu, kiểm logic và format đã ok chưa. Thứ hai, kiểm sản phẩm có nằm đúng trong danh mục deliverable cần giao không — đúng phần, đúng bản. Ví dụ Project Plan quy định test case phải dịch sang tiếng Nhật, nhưng thực tế đang để tiếng Anh thì FI phải phát hiện ra sai lệch đó. Mọi tài liệu, định dạng đều phải đúng chuẩn trước khi bàn giao.

▸ 3. Có công cụ hỗ trợ check FI

Vì kiểm tay ở khâu cuối rất tốn công, giảng viên có tự viết một công cụ giúp check FI nhanh hơn. Ở video này công cụ chỉ được giới thiệu sơ; do quay không hiện đủ full màn hình nên phần thao tác chi tiết sẽ được tách sang bài kế tiếp. Bạn hãy nắm vững khái niệm và tiêu chí FI trước, rồi xem bài sau để thấy tool chạy thực tế.

Chương 3 · Bài 9

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Nối tiếp bài khái niệm Final Inspection, bài này demo trực tiếp công cụ Check Final Inspection — một tool tự viết giúp QA kiểm hàng loạt tài liệu trước khi giao khách hàng. Điểm mạnh của tool là kiểm được mọi loại template, không phụ thuộc định dạng cụ thể; bạn chỉ cần cấu hình các tiêu chí một lần rồi chạy check cả chục file cùng lúc.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vai trò của bốn sheet cấu hình trong tool Check Final Inspection.
• Cấu hình được các quan điểm kiểm tra như zoom, font name, font size, giá trị Not Empty.
• Chạy check hàng loạt file, click vào link lỗi để nhảy đúng ô sai và sửa.

─── NỘI DUNG CHÍNH

▸ 1. Bốn sheet cấu hình của tool

Để dùng tool, bạn phải hiểu bốn sheet: sheet cấu hình để tool chạy được; sheet danh sách file cần check kèm lựa chọn run / not run; sheet danh sách lỗi; và sheet tổng hợp. Mỗi tiêu chí kiểm tra ứng với một FICode — mã báo lỗi kèm mô tả hướng dẫn. Ví dụ FI010 kiểm zoom cho tất cả sheet, chỉ cần một param.

▸ 2. Cấu hình các quan điểm kiểm tra

Mỗi "quan điểm" cần khai báo tham số. Ví dụ check font name Tahoma: bạn nhập font bắt buộc, tên sheet, và vùng dữ liệu (như B2:AQ17). Check Not Empty: khai báo sheet name và các ô bắt buộc phải có giá trị (D4, D5, M4...). Khi cần nhập nhiều sheet động, bạn dùng ký hiệu rút gọn và ngăn cách bằng dấu gạch dưới. Tool được viết theo hướng mở rộng được, nên cần quan điểm kiểm tra mới thì có thể yêu cầu giảng viên bổ sung.

▸ 3. Chạy check và sửa lỗi theo link

Sau khi cấu hình, bạn bấm chạy; tool trả về tổng số lỗi (ví dụ 3 lỗi Not Empty, 7 lỗi zoom sai 85% thay vì 100%, hay lỗi sai font). Ở sheet kết quả, mỗi lỗi có một link nhảy thẳng tới file và đúng dòng đang lỗi. Bạn điền/sửa giá trị, save file, rồi chạy lại cho tới khi hết lỗi. Tool đặc biệt hiệu quả khi phải review 20–30 file test case cùng lúc, và được đính kèm trong tài liệu khóa học để bạn tải về.

Chương 3 · Bài 10

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Muốn kiểm soát dự án, QA cần một công cụ quản lý tập trung. Bài học giới thiệu Redmine — công cụ dùng để tra cứu thông tin dự án, theo dõi tiến độ và phát hiện việc trễ hạn. Điểm mấu chốt không nằm ở riêng Redmine: khi bạn có tư duy quản lý tốt, bạn có thể áp dụng lên bất kỳ công cụ nào (Google Sheets, Trello, Jira...), nhưng ở đây Redmine được chọn để minh họa.

─── SAU BÀI HỌC, BẠN SẼ

• Dùng query trong Redmine để lọc và kiểm tra tình trạng công việc của dự án.
• Đọc Gantt chart để nhận ra ngay việc nào trễ, việc nào đúng tiến độ.
• Group issue theo user để thấy khối lượng còn lại của từng người.

─── NỘI DUNG CHÍNH

▸ 1. Dùng query để kiểm soát dự án

Trên một dự án Redmine, bạn tạo các query để đo xem công việc đang trễ hay không, có vấn đề gì không. Sau khi lập query đúng ý, bạn save query lại để tái sử dụng. Từ đó, việc kiểm soát dự án chỉ còn là nhìn vào các query đã lưu và đối chiếu thông tin đã ổn hay chưa.

▸ 2. Theo dõi tiến độ bằng Gantt chart

Về mặt tiến độ, bạn mở Gantt chart của Redmine. Đây là view rất trực quan: nhìn vào là biết ngay task nào trễ, task nào đúng hạn. Nó giúp bạn nắm bức tranh tiến độ toàn dự án mà không phải dò từng issue.

▸ 3. Group theo user và mở rộng tự động hóa

Redmine còn nhiều option lọc: đưa status, gán người, và đặc biệt là group by user. Khi group theo người, bạn thấy ngay mỗi thành viên còn bao nhiêu việc, ai đang quá tải. Ở quy mô lớn — hệ thống gần và hơn 100 người — giảng viên còn liên kết Redmine với Slack để mỗi lần thống kê, hệ thống tự bắn notification báo dự án nào có vấn đề. Công cụ báo cáo thống kê tự động này sẽ được demo ở phần sau; nếu muốn tự dựng Redmine, bạn có thể tham khảo khóa học dựng Redmine miễn phí của giảng viên.

Chương 3 · Bài 11

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Xuyên suốt chương này, bạn học cách đo chất lượng bằng số liệu — LOC, test case, bug, NORM. Bài học này lùi lại một bước để nhắc: số liệu chỉ là một phương pháp, không phải toàn bộ chất lượng. Một sản phẩm có thể đúng hết mọi con số nhưng khách hàng vẫn không hài lòng nếu nó không thiết thực. Đây là bài mang tính nhận thức, giúp bạn đặt số liệu vào đúng vị trí của nó.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vì sao đạt chuẩn số liệu chưa chắc đã đạt chất lượng thực sự.
• Nhận ra các lỗi nghiêm trọng ngoài số liệu như lỗi logic và lỗi layout.
• Thấy được giá trị thật của việc đánh giá chất lượng: rà soát sớm để giảm chi phí sửa lỗi.

─── NỘI DUNG CHÍNH

▸ 1. Số liệu là phương pháp, không phải tất cả

Bạn có thể làm đúng hết số lượng test case, đúng hết LOC, đúng mọi chỉ số — nhưng khi giao, khách hàng vẫn chê vì sản phẩm không thiết thực: layout vỡ, chữ bị rớt dòng khác với design, cần đổi bố cục... Nghĩa là chuẩn chất lượng thực tế rất khó đáp ứng chỉ bằng con số. Bản thân bài toán đo LOC cũng khó và ít chính xác với dự án lớn; thực tế chủ yếu các công ty Nhật mới dùng LOC nhiều, nơi khác dùng ít hơn.

▸ 2. Những lỗi nghiêm trọng ngoài số liệu

Có hai nhóm cần đặc biệt lưu tâm. Thứ nhất là lỗi logic — sản phẩm phải không sai logic. Thứ hai là lỗi layout làm mất người dùng, ví dụ layout hỏng nghiêm trọng, hiển thị sai. Tùy tính chất sản phẩm mà bạn định nghĩa chuẩn chất lượng cho phù hợp; không có một chuẩn cứng nào đúng cho mọi dự án, thường bạn follow chuẩn của công ty mình.

▸ 3. Giá trị thật: rà soát sớm, giảm chi phí sửa lỗi

Việc đánh giá chất lượng giống như tầm soát — rà hết số liệu và toàn bộ màn hình sản phẩm để lọc ra chỗ có vấn đề, xem cái nào đạt, cái nào chưa. Lợi ích lớn nhất là hạn chế rủi ro và chi phí sửa lỗi về sau: nếu bắt được lỗi ngay ở giai đoạn review code, bạn tiết kiệm được rất nhiều so với để tester bắt và bắt developer sửa lại. Phát hiện càng sớm, chi phí càng thấp — đó chính là ý nghĩa của tiêu chuẩn chất lượng.

Chương 4 · Bài giới thiệu

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đây là bài mở đầu chương 4, giới thiệu mục tiêu của cả chương: thống kê số liệu dự án bằng công cụ. Ý tưởng cốt lõi là đo đơn vị nhỏ nhất mà mỗi role tạo ra — developer thì đo LOC, tester thì đo test case và bug, quản lý thì đo chi phí effort. Có được các con số này, ở vai trò QA bạn mới có cơ sở để phán đoán chất lượng và quy trình của dự án.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu chương 4 sẽ đo những đơn vị số liệu nào ứng với từng role trong dự án.
• Biết vì sao QA cần các số liệu này để đánh giá chất lượng và so với NORM.
• Nắm được các bài trong chương này dùng chung với khóa quản lý dự án (PM).

─── NỘI DUNG CHÍNH

▸ 1. Đo đơn vị nhỏ nhất của từng role

Mỗi vai trò trong dự án cho ra một loại "output" đo được. Developer cho ra số LOC. Tester cho ra test case và số lượng bug. Về chi phí, dự án cần đo calendar effort — công sức phải bỏ ra, cũng như bill khách hàng trả hàng tháng. Chương 4 sẽ lần lượt hướng dẫn cách thống kê từng loại số liệu này bằng công cụ.

▸ 2. QA dùng số liệu để phán đoán chất lượng

Cùng những con số đó, người quản lý dự án (PM) dùng để quản lý tiến độ, còn QA dùng để quản lý quy trình và chất lượng. Sau khi đo, bạn dựa vào số liệu để đối chiếu với số NORM — chuẩn chất lượng — xem dự án có đạt hay không. Đây chính là nền tảng cho toàn bộ việc đánh giá ở các chương sau.

▸ 3. Nội dung dùng chung với khóa quản lý dự án

Để tiết kiệm thời gian, các video thao tác công cụ trong chương này được lấy chung từ khóa quản lý dự án (PM), nơi chúng nằm ở chương 5. Vì công cụ và cách đo là như nhau, nên khi xem bạn sẽ thấy tên chương/bài gốc khác đôi chút — ví dụ "Chương 4 Bài 1" ở khóa QA chính là "Chương 5 Bài 1" bên khóa PM — nhưng nội dung hoàn toàn tương đương.

Chương 4 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Để đo được năng suất và quy mô công việc của lập trình viên, ta cần một đơn vị đo lường — và đơn vị nhỏ nhất, cơ bản nhất chính là LOC (Line Of Code), tức số dòng code developer viết ra. Bài học hướng dẫn bạn dùng một công cụ đếm dòng code tự động (StepCounter / LineCounter) để lấy con số LOC cho từng file, từng màn hình, từng người, hay cả dự án.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu LOC là gì và vì sao nó là đơn vị đo cơ bản của developer.
• Cài đặt và cấu hình được công cụ đếm dòng code để nó chạy đúng.
• Đếm được LOC theo file, theo màn hình và theo từng thành viên, rồi đổ số liệu sang Excel/Google Sheets.

─── NỘI DUNG CHÍNH

▸ 1. LOC là gì và đo bằng công cụ nào

LOC là số dòng code mà developer tạo ra — đơn vị nhỏ nhất để định lượng khối lượng lập trình. Thay vì đếm tay, ta dùng công cụ chuyên đếm dòng code. Giảng viên có để sẵn link tải công cụ trong tài liệu khóa học; bạn cũng có thể tự tìm trên mạng. Công cụ sẽ tách rõ ba loại dòng: comment, dòng trống (blank) và actual code (dòng code thực sự).

▸ 2. Lưu ý quan trọng: cấu hình trước khi dùng

Đây là công cụ có nguồn gốc từ Nhật, nên trước khi chạy phải chỉnh ngôn ngữ hệ thống sang tiếng Nhật rồi khởi động lại máy — nếu không, công cụ dễ bị lỗi font và đọc sai mã nguồn. Đường đi: Region → Administrative → đổi system locale sang Japanese. Đây là bước hay bị bỏ sót và là nguyên nhân số một khiến công cụ báo lỗi.

▸ 3. Đếm LOC và xử lý ngôn ngữ chưa được hỗ trợ

Mở công cụ rồi kéo (drag) thư mục source code vào, nó tự nhận diện và trả về số comment, blank và actual LOC. Nếu dự án dùng một ngôn ngữ lập trình mà công cụ chưa biết (ví dụ PHP), bạn phải định nghĩa (define) thêm: khai báo ký hiệu comment theo dòng và theo block, rồi gán phần mở rộng file (extension) cho ngôn ngữ đó. Sau khi cấu hình, công cụ sẽ đếm được cả ngôn ngữ mới.

▸ 4. Tổng hợp số liệu ra Excel / Google Sheets

Sau khi có kết quả, bạn dùng chức năng Copy to Clipboard để lấy toàn bộ số liệu rồi dán vào Excel hoặc Google Sheets. Giảng viên còn chia sẻ một file template đã viết sẵn công thức: chỉ cần trỏ tới thư mục source, cấu hình file/folder nào cần bỏ qua và function thuộc về ai, rồi bấm nút là template tự đổ ra LOC theo từng màn hình, từng người, thậm chí theo từng ngày để tính năng suất. File template và công cụ đều nằm trong thư mục tài liệu của khóa học.

Chương 4 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Sau khi biết đếm số dòng code (LOC), bài này chuyển sang một đơn vị đo khác của người tester: Test Case. Test case chính là đơn vị nhỏ nhất, là output của tester khi họ kiểm thử một sản phẩm. Muốn thống kê chất lượng và khối lượng test, bạn cần đếm được tổng số test case đã viết. Bài học chỉ cho bạn hai cách đếm tự động — một bằng công cụ Excel, một bằng công thức trên Google Sheets (spreadsheet) — thay vì đếm tay từng file.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu test case là gì và vì sao nó là đơn vị đo cơ bản của công việc kiểm thử.
• Dùng được công cụ Excel (viết bằng VBA) để đếm test case từ một thư mục nhiều file.
• Gom số liệu test case theo thời gian thực bằng hàm ImportRange trên Google Sheets.

─── NỘI DUNG CHÍNH

▸ 1. Đếm test case bằng công cụ Excel

Giảng viên có sẵn một thư mục demo gồm nhiều file test case (file 1, file 2, file 3...), mỗi file ghi tổng số lượng test case. Để đếm nhanh, bạn dùng công cụ viết bằng VBA mà giảng viên đã để trong thư mục công cụ của khóa học. Cách dùng: điền tên file, folder chứa file, column cần lấy và sheet tương ứng, rồi bấm Go and get. Công cụ sẽ chạy vào thư mục, mở đúng file test case, đọc đúng dòng và trả về tổng số test case. Trong công cụ còn kèm sẵn một guideline hướng dẫn từng bước, bạn bấm theo là xong.

▸ 2. Đếm test case bằng Google Sheets với ImportRange

Nếu cả team làm việc trên spreadsheet — mỗi người một file test case riêng — bạn dùng hàm ImportRange để kéo dữ liệu từ các file đó về một bảng tổng. Lần đầu chạy, Google Sheets sẽ yêu cầu allow permission (cấp quyền truy cập file nguồn) thì hàm mới lấy được số liệu. Ưu điểm lớn nhất: khi tester bên file nguồn cập nhật thêm test case, con số ở bảng tổng của bạn tự nhảy theo trực tiếp, không phải đếm lại. Đây là cách theo dõi tiến độ viết test case của cả nhóm gần như theo thời gian thực.

Chương 4 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Không có dự án phần mềm nào là không có bug — và ngay cả sản phẩm đã phát hành vẫn còn lỗi. Vì vậy, đo được chỉ số bug là cách để bạn biết dự án của mình có chất lượng hay không. Bài học hướng dẫn bạn quy trình đầy đủ: export dữ liệu bug từ Redmine ra file CSV, đưa vào Excel hoặc Google Sheets, rồi dùng pivot để thống kê xem ai đang nhiều bug, bug ở trạng thái nào, và loại lỗi nào chiếm tỷ trọng lớn.

─── SAU BÀI HỌC, BẠN SẼ

• Export danh sách bug từ Redmine ra file CSV để mang đi thống kê.
• Import CSV vào Excel/Google Sheets và dùng pivot để tổng hợp bug theo người và theo trạng thái.
• Đọc được biểu đồ bug để phân tích nguyên nhân lỗi và đề ra hành động cải thiện.

─── NỘI DUNG CHÍNH

▸ 1. Lấy dữ liệu bug từ Redmine ra CSV

Trong Redmine, bạn lọc các issue có tracker là Bug (nếu dự án đang là task, có thể chuyển tracker sang Bug để demo), rồi dùng chức năng export CSV. File CSV này chính là nguồn dữ liệu thô để thống kê.

▸ 2. Import và dựng pivot trong Excel / Google Sheets

Trong Excel, vào Data → From File → CSV, chọn đúng file bug và import vào. Với Google Sheets cũng làm tương tự. Sau khi có bảng dữ liệu, bạn Insert Pivot để tổng hợp: đếm số bug theo status (ví dụ status New có bao nhiêu bug), theo assignee (dev 1, dev 2, dev 3 mỗi người bao nhiêu bug). Từ pivot, bạn tạo chart để nhìn ai đang gánh nhiều bug nhất.

▸ 3. Phân tích nguyên nhân và ra đề nghị cải thiện

Giảng viên chia sẻ một file template dựng sẵn: đổ data vào là tự ra biểu đồ và bảng phân tích. Ví dụ, template chỉ ra lỗi layout chiếm 47% (lỗi bất cẩn), coding logic chiếm 58% với nhiều lỗi do misunderstand requirement. Từ đó rút ra hành động: tăng cường training về layout, bổ sung người hiểu nghiệp vụ (BrSE) hoặc yêu cầu khách hàng giải thích rõ nghiệp vụ. Thống kê bug không chỉ để đếm — mục tiêu là tìm nguyên nhân gốc và đề xuất cách sửa.

Chương 4 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Chi phí là một trong bốn yếu tố của dự án (Time, Scope, Cost, Quality) mà bạn phải kiểm soát chặt. Bài học giới thiệu Calendar Effort — chỉ số đo lượng công sức thực tế mà công ty bỏ vào dự án dựa trên những người được allocate. Nó khác với Billable Effort (số người mà khách hàng trả tiền theo hợp đồng). So sánh hai con số này, bạn biết dự án đang lời hay lỗ về mặt effort. Điểm cốt lõi: Calendar Effort được tính bằng hàm NETWORKDAYS, có tính ngày nghỉ, nhân với tỷ lệ tham gia và hệ số hợp đồng của từng người.

─── SAU BÀI HỌC, BẠN SẼ

• Phân biệt Calendar Effort (effort mình bỏ ra) với Billable Effort (effort khách hàng trả tiền).
• Tính được Calendar Effort bằng hàm NETWORKDAYS với start date, end date và danh sách ngày nghỉ.
• So sánh Calendar Effort với Billable để đánh giá dự án đang lời, lỗ hay cần OT.

─── NỘI DUNG CHÍNH

▸ 1. Công thức tính Calendar Effort

Trên spreadsheet, bạn dùng hàm NETWORKDAYS để đếm số ngày làm việc từ start date đến end date, loại trừ các ngày nghỉ (ví dụ vùng ô O2 đến O15). Sau đó nhân với tỷ lệ tham gia dự án của người đó (Effort Rate, ví dụ 50%) và hệ số hợp đồng. Kết quả cho ra Calendar Effort của từng người, cộng lại thành tổng của dự án.

▸ 2. Hệ số quy đổi theo loại hợp đồng

Vì Project Manager thường không biết chính xác mức lương từng nhân viên, công ty dùng hệ số quy đổi thay cho lương: nhân viên chính thức tính hệ số 1, cộng tác viên tính 0.5 (một số nơi quy định khác). Hệ số này giúp quy chuẩn chi phí mà không cần lộ lương cụ thể.

▸ 3. Đọc kết quả: lời, lỗ hay phải OT

Ví dụ Billable của dự án là 8 MM (man-month) nhưng Calendar Effort thực tế chỉ 7.25 MM. Nghĩa là bạn đang bỏ ra ít hơn kế hoạch, tức lời hơn so với số bill. Tuy nhiên, nếu khối lượng công việc thật sự cần tới 8 MM mà chỉ bỏ 7.25 MM, thì đội có thể phải OT mới làm kịp. Vì vậy con số này phải đọc trong tương quan với khối lượng thực tế, không chỉ nhìn riêng.

Chương 4 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Nối tiếp Calendar Effort, bài này giới thiệu Effort Efficiency (EI) — chỉ số cho biết dự án đang dùng nguồn lực hiệu quả tới đâu, lời hay lỗ về effort. Công thức rất gọn: EI = Billable / Calendar. So sánh số effort khách hàng trả (Billable) với số effort mình thực bỏ ra (Calendar), bạn biết đội đang thừa người hay thiếu người, đang ước lượng đúng hay sai. Đơn vị dùng ở đây là MM (man-month).

─── SAU BÀI HỌC, BẠN SẼ

• Tính được chỉ số EI theo từng tháng bằng công thức Billable chia Calendar.
• Đọc được ý nghĩa của EI: trên 100% là lời, dưới 100% là lỗ và có thể đang thiếu người.
• Vẽ combo chart để nhìn tương quan giữa Billable, Calendar và EI qua các tháng.

─── NỘI DUNG CHÍNH

▸ 1. Công thức EI và cách đọc con số

Trên một sheet mới, bạn lập cột các tháng (dùng hàm EOMONTH để tự sinh tháng kế tiếp), điền dòng Billable (effort khách hàng trả) và dòng Calendar (effort thực tế), đơn vị MM. EI của mỗi tháng = Billable / Calendar, nhân 100 để ra phần trăm. Nếu tổng Billable là 19 MM mà Calendar là 22 MM thì dự án lỗ 3 MM. EI lớn hơn 100% nghĩa là bỏ ra ít hơn khách hàng trả (lời); EI nhỏ hơn 100% nghĩa là bỏ ra nhiều hơn (lỗ).

▸ 2. Điều EI nói về khối lượng và nhân sự

EI thấp (bỏ nhiều người hơn dự kiến) thường báo hiệu khối lượng công việc nhiều hơn ước lượng ban đầu — có thể bạn đang underestimation (ước lượng sai), kế hoạch 3 người nhưng thực tế phải 4 người mới xong. Ngược lại, EI thấp cũng có thể nghĩa là dự án ít việc thừa người, khi đó nên rút bớt một người ra khỏi dự án.

▸ 3. Mức EI hợp lý và cách vẽ combo chart

Trong ngành phần mềm, EI 100% thường khó vận hành vì không có ai dự phòng; mức đẹp thường quanh 85% — tức luôn thừa khoảng nửa đến một người để xử lý tình huống phát sinh. Để nhìn dễ hơn, bạn select dữ liệu → Insert Chart, chọn combo chart: Billable và Calendar để dạng column trục trái (cùng đơn vị MM), EI để trục phải (phần trăm), rồi bật data label. Biểu đồ này giúp bạn thấy ngay tương quan effort của team đang lời hay lỗ.

Chương 4 · Bài 6-1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Không đo được tiến độ là một trong những điều nguy hiểm nhất khi làm dự án — đến lúc khách hàng nhìn vào output mới phát hiện chưa xong thì dự án đã "cháy". Đây là phần 1 của bài đo tiến độ, đặt nền tảng: vì sao phải đo tiến độ mỗi ngày, cách nhìn tiến độ theo giá trị mang lại (EVM), phân biệt trễ ngày bắt đầu với trễ ngày kết thúc, và cách viết công thức tự nhận diện task trễ trên spreadsheet.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vì sao phải giữ dự án "đúng lane" mỗi ngày thay vì để dồn đến cuối.
• Đo tiến độ theo phương pháp EVM (Earned Value Management), so cost bỏ ra với giá trị đạt được.
• Phân biệt và viết công thức nhận diện trễ ngày bắt đầu và trễ ngày kết thúc.

─── NỘI DUNG CHÍNH

▸ 1. Nhận thức về tiến độ và đo theo EVM

Mỗi ngày bạn phải biết dự án đang tới đâu và đang "đúng lane" hay đã trượt. Cách đo chuẩn là EVM (Earned Value Management) — nhìn theo giá trị mang lại chứ không chỉ theo tiền đã tiêu. Ví dụ khách hàng có budget 100.000 USD trong 5 tháng, mỗi tháng plan tiêu 2.000 USD tương ứng 20% tiến độ. Nếu đến một mốc, chi phí đã tiêu đúng 60% kế hoạch nhưng tiến độ thực tế (actual progress) mới 50%, thì dự án đang trễ so với chi phí — dấu hiệu phải xem lại ngay.

▸ 2. Trễ ngày bắt đầu và trễ ngày kết thúc

Có hai loại trễ bạn phải phân biệt rõ:

• Trễ ngày bắt đầu: đến ngày phải start task mà bạn vẫn chưa bắt đầu (task còn ở trạng thái New).
• Trễ ngày kết thúc: đến ngày phải hoàn thành mà task vẫn chưa xong (chưa chuyển sang Closed/Low).

▸ 3. Viết công thức nhận diện trễ

Trên Excel/Google Sheets, bạn dùng hàm IFS để tự gắn nhãn cho từng task. Nếu status bằng Closed thì coi như Finish, không quan tâm. Nếu status vẫn là New và ngày kết thúc dự kiến đã nhỏ hơn ngày báo cáo hôm nay thì gắn trễ ngày kết thúc; nếu ngày bắt đầu dự kiến đã qua mà task chưa start thì gắn trễ ngày bắt đầu. Nhờ công thức này, bảng sẽ tự bôi ra những task đang có vấn đề để bạn xử lý kịp. Phần tính phần trăm trễ/sớm và cách vẽ chart sẽ tiếp tục ở phần 2.

Chương 4 · Bài 6-2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đây là phần 2, nối tiếp cách phân biệt trễ ở phần 1. Ở đây bạn học cách tính phần trăm trễ và sớm tiến độ dựa trên phần trăm hoàn thành thực tế của từng task, rồi dùng Gantt chart và Burndown chart để nhìn tiến độ dự án một cách trực quan. Điểm mấu chốt: con số trễ/sớm chỉ mang tính tương đối, nên phải kết hợp với phần trăm hoàn thành do người làm tự đánh giá.

─── SAU BÀI HỌC, BẠN SẼ

• Tính được số giờ trễ hoặc sớm của một task dựa trên effort estimate và phần trăm hoàn thành.
• Đọc được Burndown chart để thấy tổng thể dự án đang thừa hay thiếu bao nhiêu task/effort.
• Đọc được Gantt chart để biết một mốc ngày cụ thể đang sớm hay trễ so với kế hoạch.

─── NỘI DUNG CHÍNH

▸ 1. Tính phần trăm trễ và sớm tiến độ

Số giờ đã spend không phản ánh hết mức độ trễ. Ví dụ một task estimate 7 tiếng, đã làm hết 7 tiếng nhưng người làm tự đánh giá mới xong 50% — suy ra cần thêm 7 tiếng nữa mới hoàn thành, tức độ trễ là 7 tiếng chứ không phải 0. Vì vậy bạn nên có thêm cột phần trăm hoàn thành do người làm tự đánh (do developer/doer báo). Công thức tính effort còn lại: Estimate × (1 − phần trăm đã hoàn thành). Với task làm sớm (start trước ngày kế hoạch, đã đạt một phần trăm nào đó) thì tính ngược lại thành sớm bao nhiêu giờ. Mọi con số này chỉ tương đối, có thể điều chỉnh theo công thức riêng của công ty.

▸ 2. Đọc Burndown chart

Burndown chart cho bạn nhìn tổng thể theo hai chiều: số lượng task còn lại và số lượng effort còn lại. Ví dụ theo kế hoạch chỉ còn 3 task / 3 ngày, nhưng thực tế còn 18 task / 18 ngày — nghĩa là dự án đang trễ tiến độ. Nhược điểm: burndown cho thấy tổng thể nhưng không thấy chi tiết từng task.

▸ 3. Đọc Gantt chart và tracking mỗi ngày

Gantt chart cho thấy chi tiết từng task. Tại một ngày báo cáo, nếu đường phần trăm hoàn thành nằm bên phải/cao hơn mốc kế hoạch thì đang sớm hơn tiến độ; nếu nằm dưới (ví dụ ngày 21 mà mới 40%) thì đang trễ. Quản trị dự án tốt là mỗi ngày tracking bằng chart và số liệu để phát hiện chỗ có vấn đề, giữ đúng plan; nếu trễ nhiều thì phải có phương án recover độ trễ, thậm chí re-plan cả dự án.

Chương 5 · Bài 0

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đây là bài mở đầu Chương 5 — chương dạy bạn đánh giá chất lượng dự án dựa trên số liệu, thông qua bộ chỉ số Quality Metrics. Sau khi các chương trước đã hướng dẫn cách thu thập số liệu (LOC, test case, bug, effort, tiến độ), chương này ghép chúng lại thành một bức tranh chất lượng để bạn phán đoán và ra quyết định cải thiện. Bài học phác ra lộ trình của cả chương và một lưu ý nhỏ về nguồn video.

─── SAU BÀI HỌC, BẠN SẼ

• Nắm được toàn bộ mạch nội dung của Chương 5 về đánh giá chất lượng bằng Quality Metrics.
• Hiểu tinh thần chung: có số liệu rồi thì dùng nó để đánh giá và cải thiện chất lượng dự án.
• Biết cách tham khảo các video liên quan dù đánh số chương/bài khác nhau giữa các khóa.

─── NỘI DUNG CHÍNH

▸ 1. Lộ trình của Chương 5

Chương này gồm chuỗi bài đi từ dựng báo cáo đến hành động cải thiện:

• Làm báo cáo thống kê chất lượng bằng Excel.
• Làm báo cáo thống kê chất lượng bằng spreadsheet (Google Sheets).
• Vẽ chart để trình bày báo cáo chất lượng trực quan.
• Nhìn các chỉ số để phán đoán tình trạng chất lượng của dự án.
• Thực hiện các hành động cải thiện chất lượng dựa trên phán đoán đó.

▸ 2. Tinh thần đánh giá dựa trên số liệu

Điểm cốt lõi của chương là: khi đã có số liệu, bạn dùng chính nó làm căn cứ để đánh giá chất lượng dự án một cách khách quan, thay vì cảm tính. Toàn bộ các bài sau sẽ xoay quanh việc biến số liệu thô thành nhận định và hành động cụ thể.

▸ 3. Lưu ý về nguồn video

Một số video của chương này được quay chung với khóa PM (quản lý dự án), nên đánh số chương/bài có thể khác với thứ tự trong khóa QA. Tuy nhiên nội dung là như nhau, bạn hoàn toàn có thể tham khảo song song mà không lo lệch kiến thức.

Chương 5 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học đưa lý thuyết về số NORM vào thực hành trên file Excel: dựng một bảng Quality Metrics đo chất lượng theo từng màn hình (function), so sánh giữa kế hoạch (plan) suy ra từ số NORM và thực tế (actual) thu thập được. Từ chênh lệch đó, bạn dùng một ma trận đánh giá để biết mỗi function đang ở "vùng" chất lượng nào và cần hành động gì. Đây là bài khá phức tạp — nắm được cách đọc ma trận T/D là chìa khóa.

─── SAU BÀI HỌC, BẠN SẼ

• Lập bảng Quality Metrics trên Excel theo function ID, đo LOC, test case và bug.
• Suy ra số kế hoạch từ số NORM và so với số thực tế để thấy độ chênh lệch.
• Đọc được ma trận đánh giá T1–T3 / D1–D3 để xác định vùng chất lượng và action tương ứng.

─── NỘI DUNG CHÍNH

▸ 1. Dựng bảng và tính số kế hoạch từ NORM

Với mỗi function ID (mã màn hình), bạn đếm LOC bằng công cụ đếm code, quy ra KLOC (chia 1000). Dựa trên số NORM của công ty — ví dụ 15 bug / 1 KLOC, 90 test case / 1 KLOC — bạn tính ngược ra con số kế hoạch (plan): số bug dự kiến, số test case cần viết cho từng function. Đây là phương pháp estimation kiểu Nhật, lấy đơn vị nhỏ nhất là LOC.

▸ 2. Thu thập số thực tế và tính mật độ

Sau khi code và test xong, bạn collect data thực tế: LOC thật, số test case thật, số bug thật (thường điền tay từ hệ thống quản lý). Từ đó tính mật độ thực tế, ví dụ bug density 11.1 bug / 1 KLOC. Bảng đặt cạnh nhau hai cột plan và actual để thấy ngay độ lệch của từng function.

▸ 3. Ma trận đánh giá T/D và đọc vùng chất lượng

Trọng tâm của bài là ma trận đánh giá. Test case được phân thành T1/T2/T3 và defect thành D1/D2/D3: mức 2 là nằm trong ngưỡng NORM, mức 3 là nhiều hơn NORM, mức 1 là ít hơn NORM. Tổ hợp T và D cho ra các vùng có ý nghĩa khác nhau — ví dụ T3 + D2 (test case nhiều hơn NORM nhưng bug bằng NORM) nghĩa là có test case thừa, cần rà lại nội dung; T1 + D1 (cả test case lẫn bug đều quá ít) nghĩa là số test case quá ít nên bắt được ít bug, cần bổ sung test. Nhớ nguyên tắc: lỗi hợp lệ phải nằm trong bộ test case. Cuối cùng, ở sheet Quality Report, bạn đối chiếu số actual với ma trận để kết luận từng function nằm vùng nào và cần action gì. Bài sau sẽ làm điều tương tự trên Google Sheets.

Chương 5 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài trước bạn đã dựng báo cáo Quality Metrics trên Excel; bài này làm đúng nội dung đó nhưng trên Google Sheets (spreadsheet). Tin vui là bạn gần như không phải làm lại từ đầu: chỉ cần đưa file Excel lên và convert thành Google Sheets, công thức vẫn giữ nguyên, template dùng lại được. Điểm khác biệt duy nhất nằm ở nguồn dữ liệu tham chiếu — thay vì trỏ tới file Excel, bạn trỏ tới các file test case đang nằm trên Google Sheets.

─── SAU BÀI HỌC, BẠN SẼ

• Chuyển báo cáo Quality Metrics từ Excel sang Google Sheets mà vẫn giữ nguyên công thức.
• Trỏ nguồn dữ liệu về các file test case trên Google Sheets thay vì file Excel.
• Đọc lại bảng đánh giá chất lượng trên spreadsheet để xác định vùng test case và defect.

─── NỘI DUNG CHÍNH

▸ 1. Convert template từ Excel sang Google Sheets

Bạn lấy chính file template đã dựng ở bài Excel, import/convert lên thành Google Sheets. Toàn bộ công thức được giữ nguyên, không cần viết lại, không phát sinh vấn đề gì. Template này đã có sẵn trong thư mục tài liệu của khóa học để bạn tham khảo.

▸ 2. Thay nguồn refer data sang Google Sheets

Khác biệt cốt lõi so với bản Excel chỉ là nguồn dữ liệu tham chiếu. Bạn lấy các file test case đang ở dạng Google Sheets, cộng số test case của từng màn hình rồi điền vào bảng. Kết quả trả về y hệt bản Excel: vẫn ra đủ thông tin theo function, vẫn tính được độ trung bình cho từng phần.

▸ 3. Đọc lại bảng đánh giá chất lượng

Bên spreadsheet cũng có sheet đánh giá chất lượng giống hệt bản Excel: bạn xem test case rơi vào vùng T nào và defect rơi vào vùng D nào để kết luận. Về cơ bản mọi thứ giống nhau, chỉ khác ở công cụ: một bên Excel, một bên Google Sheets. Riêng phần vẽ chart thì hai công cụ khác nhau khá nhiều và sẽ được hướng dẫn riêng ở các bài sau.

Chương 5 · Bài 3.1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Khi đã có bảng số liệu chất lượng dự án, bước tiếp theo là biến những con số khô khan thành chart để người đọc nhìn một cái là thấy vấn đề. Bài học hướng dẫn bạn vẽ các chart cơ bản ngay trong Excel từ file số liệu đã dựng ở bài trước. Điểm mấu chốt: chart không cần cầu kỳ — chỉ cần vài chart đơn giản là đủ để chỉ ra chỗ bất thường và làm báo cáo trực quan hơn.

─── SAU BÀI HỌC, BẠN SẼ

• Vẽ được chart từ vùng dữ liệu bằng chức năng Insert của Excel.
• Nhân bản nhanh một chart và đổi dữ liệu nguồn để tạo chart mới.
• Nhúng số liệu và chart vào báo cáo, thêm đường xu hướng (trendline) để trình bày.

─── NỘI DUNG CHÍNH

▸ 1. Vẽ chart cơ bản từ vùng dữ liệu

Mở file Excel đã có sẵn số liệu, bôi đen (kéo) vùng dữ liệu bạn muốn thể hiện, vào Insert rồi chọn Recommended Charts hoặc trực tiếp một loại chart bạn muốn — ví dụ Column chart — và nhấn OK. Trong bài, chart đầu tiên vẽ ra là chart về LOC (Line Of Code). Nhìn vào chart này bạn phát hiện ngay điểm bất thường: có màn hình đang ở trạng thái kế hoạch giống các màn khác nhưng số LOC lại cao gấp mấy lần — dấu hiệu cần xem lại.

▸ 2. Nhân bản chart và đổi dữ liệu nguồn

Cách nhanh nhất để có nhiều chart cùng kiểu là copy một chart đã vẽ rồi paste ra, sau đó đổi dữ liệu nguồn sang vùng khác. Bạn có thể vẽ chart mật độ bug trên LOC để soi tương quan: màn hình nào LOC rất cao mà mật độ bug lại thấp bất thường (dưới 0.6 bug/nghìn dòng) thì cần xem lại vì có thể review chưa kỹ. Tương tự, kéo dữ liệu test case và defect sang là ra chart phản ánh nhiều yếu tố hơn.

▸ 3. Tổng hợp số liệu và nhúng vào báo cáo

Muốn thể hiện một con số tổng (ví dụ tổng LOC), bạn dùng hàm SUM gộp toàn bộ cột actual lại rồi vẽ chart tổng. Để đưa cả số liệu lẫn chart vào file báo cáo, copy vùng cần lấy, nhấn chuột phải chọn Paste Special → Picture (linked picture) — số liệu sẽ hiển thị dạng ảnh liên kết, tự cập nhật theo nguồn. Bạn cũng có thể thêm trendline (Linear) để thấy xu hướng tăng/giảm. Cuối cùng đưa các chart vào PowerPoint là có một báo cáo chất lượng rõ ràng, dễ trình bày.

Chương 5 · Bài 3.2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài này làm lại đúng công việc vẽ chart của bài trước, nhưng lần này trên Google Sheets thay vì Excel. Ý tưởng và mục tiêu không đổi — vẫn là biến số liệu chất lượng thành chart để báo cáo — nhưng thao tác cấu hình dữ liệu nguồn trong Google Sheets khác Excel một chút. Điểm mấu chốt cần nhớ: chọn đúng dòng làm header và đúng cột làm label thì chart mới hiển thị chính xác.

─── SAU BÀI HỌC, BẠN SẼ

• Vẽ được chart trong Google Sheets bằng Insert → Chart.
• Cấu hình đúng loại chart, header và label cho dữ liệu.
• Nhân bản chart và chỉnh lại data range để tạo nhiều chart khác nhau.

─── NỘI DUNG CHÍNH

▸ 1. Chèn chart và chọn loại chart

Bôi đen vùng dữ liệu cần vẽ, vào Insert → Chart. Google Sheets sẽ bung ra một chart mặc định. Trong bảng cấu hình (Chart editor), bạn đổi Chart type sang Column chart để có dạng cột. Sau đó bật các tùy chọn cần thiết như Use row as headers và Data labels để chart hiển thị đúng tiêu đề và giá trị trên từng cột.

▸ 2. Cấu hình đúng header và label

Đây là chỗ khác Excel và dễ sai nhất. Trong phần Data range, bạn khai báo vùng dữ liệu (ví dụ B7 đến B22 làm cột nhãn, rồi dùng nút Add another range để thêm vùng G7 đến H22). Quan trọng: đánh dấu dùng dòng 7 (row) làm header và dùng cột B (column) làm label. Khai báo đúng thì chart mới ra đúng chỉ số — ví dụ chart bug trên LOC (bug/clock) sẽ hiển thị chuẩn.

▸ 3. Nhân bản và đổi kiểu chart

Cách làm nhanh vẫn là copy một chart đã có để giữ nguyên format, rồi vào Edit và trỏ lại vùng dữ liệu (data range) sang chỗ khác — chart mới sẽ hiện ra ngay. Nếu muốn đổi sang kiểu chart khác (ví dụ bar chart, line chart), bạn chỉ cần vào Chart editor chọn lại Chart type là hình đổi theo. Nhìn chung cấu hình trên Google Sheets hơi khác Excel nhưng làm quen vài lần là thành thạo.

Chương 5 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Vẽ được chart rồi, nhưng đọc chart thế nào để hiểu dự án đang có vấn đề gì mới là kỹ năng cốt lõi của QA. Bài học dùng một file sample thống kê chất lượng thật để hướng dẫn bạn quy trình phân tích: đặt câu hỏi, lấy dữ liệu, phân tích rồi đánh giá. Điểm mấu chốt: mọi con số đều được đối chiếu với tiêu chuẩn quy trình của công ty, và so sánh bug nội bộ với bug khách hàng để lần ra bản chất vấn đề.

─── SAU BÀI HỌC, BẠN SẼ

• Nắm được 5 bước phân tích chất lượng một dự án từ dữ liệu thống kê.
• Biết đặt đúng câu hỏi và các chỉ số cần soi (effort, LOC, phân loại bug, severity).
• Đọc được ý nghĩa đằng sau chart bug nội bộ và bug khách hàng (UAT).

─── NỘI DUNG CHÍNH

▸ 1. Bố cục file sample và 5 bước phân tích

File sample có nhiều sheet: bug nội bộ, bug khách hàng bắt (bug UAT), report nội bộ và report cho khách hàng. Quy trình phân tích một dự án đi theo 5 bước: đặt câu hỏi → lấy dữ liệu → xử lý dữ liệu → phân tích → đánh giá và ra action. Các câu hỏi mở đầu thường là: chất lượng dự án hiện tại có vấn đề không, quy trình có thực hiện đúng không, cần action gì để nâng chất lượng, và kế hoạch sắp tới ra sao.

▸ 2. Lấy dữ liệu và phân tích theo tiêu chuẩn công ty

Phần lấy dữ liệu: đổ toàn bộ số liệu về và soi dự án có đủ các phase quy trình không (ví dụ đủ 13 phase), phân tích effort/build/calendar theo từng tháng, phân loại bug, số LOC hiện tại và tiêu chuẩn công ty. Khi phân tích effort, so số công ty thực chi với số build khách hàng trả, bạn phát hiện dự án đang underestimate — bị lỗ effort và cần đề xuất thêm cho kế hoạch tháng sau.

▸ 3. So sánh bug nội bộ với bug khách hàng

Đây là phần đắt giá nhất. Đặt cạnh nhau bug nội bộ (UT) và bug khách hàng (UAT) rồi đọc từng góc: bug layout thường được bắt hết nội bộ nên khách hàng ít thấy; bug logic/nghiệp vụ còn lọt sang khách hàng chứng tỏ nghiệp vụ dự án khó. Về severity, nội bộ chủ yếu bắt minor còn khách hàng bắt major — nghĩa là khách đang gặp lỗi nghiêm trọng, dễ bực. Sau khi đọc chart, bạn viết nhận xét nội dung; riêng file trình bày cho khách hàng thì tóm gọn từng giai đoạn bị gì, tránh đưa chart quá rối.

Chương 5 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Phân tích ra vấn đề rồi thì phải ra hành động (action) để cải thiện — nếu không, báo cáo chỉ nằm trên giấy. Bài học hướng dẫn cách biến kết quả phân tích thành các action cụ thể cho cả nội bộ lẫn khách hàng. Điểm mấu chốt đáng nhớ nhất: phòng cháy hơn chữa cháy — đo chất lượng và ra action càng sớm càng tốt, đừng đợi cuối dự án mới làm báo cáo tổng vì lúc đó đã muộn.

─── SAU BÀI HỌC, BẠN SẼ

• Đề xuất được các action cải thiện về nhân sự, chi phí và nghiệp vụ dựa trên số liệu.
• Biết cách deliver theo chiều dọc để khách hàng test và feedback sớm.
• Áp dụng tư duy phòng ngừa: theo dõi chỉ số hàng ngày, action ngay khi chỉ số không đạt.

─── NỘI DUNG CHÍNH

▸ 1. Ra action từ kết quả phân tích

Từ vấn đề đã lộ ra, bạn đề xuất các action cụ thể: bổ sung người quản lý để hỗ trợ BM/PM đánh giá tình hình chính xác hơn; rà lại nhân sự, không đủ chất lượng thì thay thế; chi phí khách hàng trả thấp thì đề nghị tăng bill; nghiệp vụ khó thì nhờ khách hàng giải thích và report thông tin xuyên suốt cho stakeholder. Ví dụ khi bug major nhiều và phần nghiệp vụ bất ổn, thay vì chỉ dồn dev, hãy thêm BA vào team để nắm nghiệp vụ — dev thuần chỉ lo ra sản phẩm, khó đảm bảo chất lượng logic.

▸ 2. Cải thiện với khách hàng và cách deliver

Với khách hàng, để nâng chất lượng sản phẩm bạn tăng khâu nghiệp vụ (training, đào tạo team), communicate nhiều hơn để khách transfer nghiệp vụ. Về cách giao hàng, thay vì gom một cục rồi deliver, hãy deliver theo chiều dọc (stream): xong vài function thì giao một đợt và nhờ khách hàng test, confirm. Cách này giúp khách thấy được output sớm, feedback sớm, dự án hợp lý và khách hài lòng hơn.

▸ 3. Mẹo quan trọng: phòng cháy hơn chữa cháy

Đừng đợi tới cuối mới dựng bảng phân tích lớn — khi đó đã muộn. Ngay từ đầu hãy định nghĩa chỉ số chất lượng, làm một bảng thống kê hàng ngày, đánh giá từng function ngay khi có số liệu. Khi một chỉ số không đạt là phải warning và action tại thời điểm đó, không để "cháy" rồi mới vào cuộc. Để tìm nguyên nhân gốc và ra action phù hợp, dùng các công cụ như biểu đồ xương cá (fishbone) hoặc 5 Why.

Chương 6 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đây là bài mở màn chương tổng kết — chúc mừng bạn đã gần hoàn thành khóa QA. Mục tiêu của bài rất gọn: ôn nhanh lại toàn bộ công cụ đã học để hệ thống lại kiến thức. Điểm mấu chốt là biết tìm chúng ở đâu: tất cả công cụ và hướng dẫn đều gom sẵn qua một link tài liệu tham khảo trong slide khóa học.

─── SAU BÀI HỌC, BẠN SẼ

• Biết đường truy cập vào kho công cụ được chia sẻ trong khóa.
• Nắm được các công cụ đã học và mục đích từng cái.
• Biết mỗi công cụ đều có link hướng dẫn riêng để tra cứu lại.

─── NỘI DUNG CHÍNH

▸ 1. Truy cập kho công cụ của khóa học

Trong slide khóa học, bạn kéo tới phần link tài liệu tham khảo công cụ và click vào. Link này dẫn tới toàn bộ công cụ mà khóa cung cấp cho bạn. Đây là những công cụ bình thường bán lẻ đều tốn phí, nhưng trong khóa được chia sẻ miễn phí với mục tiêu để bạn dùng được ngay trong công việc thực tế.

▸ 2. Các công cụ đã học và hướng dẫn kèm theo

Danh sách gồm các công cụ như tool định dạng (Format), tool check FI (Final Inspection) và nhiều công cụ đo chỉ số, đo tiến độ khác đã đi qua trong khóa. Điểm tiện lợi: mỗi công cụ đều được gắn hyperlink hướng dẫn riêng ngay tại trang tài liệu — hướng dẫn cài đặt, cách dùng, cách đọc chỉ số. Bạn chỉ cần chịu khó ngồi coi lại một lượt để ôn tập trước khi qua các bài tổng kết tiếp theo về template.

Chương 6 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Nối tiếp bài ôn công cụ, bài này chỉ cho bạn kho template chuẩn chất lượng được chia sẻ trong khóa — những file mẫu bạn có thể lấy về dùng ngay cho công việc QA thật. Điểm mấu chốt: các template này chính là file giảng viên đang dùng trong dự án, và sẽ được bổ sung, chỉnh sửa theo nhu cầu học viên trong quá trình học.

─── SAU BÀI HỌC, BẠN SẼ

• Biết đường truy cập vào thư mục template và tài liệu chia sẻ của khóa.
• Nắm được các loại template chuẩn chất lượng hiện có.
• Biết cách yêu cầu bổ sung template khi cần cho dự án của mình.

─── NỘI DUNG CHÍNH

▸ 1. Truy cập thư mục template và tài liệu chia sẻ

Vẫn từ link tài liệu tham khảo của khóa, bạn sẽ thấy khu vực chứa các thư mục template cùng tài liệu chia sẻ của giảng viên. Đây là nơi tập trung mọi file mẫu đi kèm các bài đã học. Kho này còn được cập nhật dần: trong quá trình học, bạn cần template nào cho tình huống nào thì giảng viên cung cấp thêm cái đó.

▸ 2. Các template và tài liệu có sẵn

Ngoài các file template mẫu, thư mục còn có nhiều tài liệu liên quan tới chuẩn chất lượng như checklist, postmortem, code review và bug rate. Bạn click vào là mở đúng file mà giảng viên đang dùng trong công việc thật, và có thể được chỉnh sửa lại cho phù hợp nếu bạn cần. Hãy xem đây là bộ tài sản để tái sử dụng, đừng dựng lại từ đầu mỗi khi làm báo cáo hay kiểm soát chất lượng.

Chương 6 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đây là bài chia sẻ kinh nghiệm nghề — những kỹ năng và tâm thế giúp bạn đi đường dài với vai trò QA. Giảng viên nói thẳng: role QA khá mệt vì phải hiểu rõ quy trình và bản chất mình đang kiểm tra cái gì, nhưng cũng rất hay. Điểm mấu chốt: đừng cố học hết mọi thứ ngay, cứ vừa làm vừa học và điều chỉnh dần.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vì sao QA đòi hỏi tư duy quản lý gần với vai trò PM.
• Biết vài kỹ năng bổ trợ đáng đầu tư: viết công cụ, xây CV, linh hoạt quy trình.
• Có tâm thế học từ từ và biết kênh hỏi trực tiếp giảng viên khi vướng.

─── NỘI DUNG CHÍNH

▸ 1. Bản chất của role QA

QA khó ở chỗ bạn phải hiểu rõ quy trình, hiểu mình đang kiểm tra cái gì và vai trò này "chơi" cái gì. Nhiều người nhiều kinh nghiệm cho rằng ai làm được QA thì trước đó nên từng là PM — vì phải kiểm soát, hướng dẫn và quản lý quy trình của người khác. Nếu bạn đang làm QA mà thấy nản thì đừng vội, đây là giai đoạn nghề nào cũng có; càng đi sâu bạn càng thấy vai trò này thú vị.

▸ 2. Kỹ năng bổ trợ nên đầu tư

Có mấy thứ đáng rèn thêm. Thứ nhất, tự viết công cụ bằng VBA để kiểm tra khi output dự án là nhiều file Excel — giảng viên đã viết và chia sẻ khá nhiều tool như vậy trong khóa. Thứ hai, xây dựng CV cho đẹp bằng cách bổ sung các chứng chỉ, để hồ sơ ứng tuyển mạnh hơn. Thứ ba, học rộng thêm về hệ thống quản lý và chi phí — không cần giỏi hết ngay, cứ làm tới đâu học tới đó, có thể tiến dần lên vai trò BM/PM.

▸ 3. Linh hoạt khi áp quy trình vào dự án

Một cái bẫy thường gặp: quy trình chuẩn quá cứng nên khi apply vào dự án thực tế thì bị "dội" — dự án không thể theo đúng quy trình mẫu. Khi đó, một QA đúng nghĩa phải biết đề nghị điều chỉnh: nêu rõ nguyên nhân và đề xuất cách làm phù hợp cho từng phần, thay vì áp máy móc. Trong quá trình làm mà vướng, bạn có thể hỏi trực tiếp giảng viên qua kênh hỗ trợ của khóa.

Chương 6 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài kết khóa demo một công cụ tự động phân tích chất lượng dự án bằng cách kéo dữ liệu từ Redmine đổ thẳng vào template Google Sheets. Đây là đỉnh cao của tất cả kỹ năng đã học: thay vì thống kê thủ công từng chỉ số, bạn để tool tự lấy data và dựng sẵn báo cáo. Điểm mấu chốt: mỗi ngày chỉ cần chạy lại một lần là thấy ngay tình hình dự án, tiết kiệm rất nhiều thời gian và chi phí.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu cách một công cụ kết nối Redmine với Google Sheets qua API hoạt động.
• Biết các thông tin cần nhập để tool kéo được dữ liệu dự án.
• Hình dung được kết quả tự động: effort, trạng thái bug, chỉ số chất lượng, chart.

─── NỘI DUNG CHÍNH

▸ 1. Cấu hình và chạy tool

Vào trang tool (chat project), bạn nhập ba thông tin: API key của tài khoản Redmine, username, và link project bạn muốn thống kê (lấy từ phần project trên Redmine). Sau đó nhấn Get full rồi Submit và chờ. Tool sẽ dùng API để kéo toàn bộ dữ liệu của dự án đó về.

▸ 2. Dữ liệu đổ về template Google Sheets

Sau khi submit, dữ liệu đổ toàn bộ vào một template Google Sheets — chính là template đã demo ở các bài trước. Từ dữ liệu thô, template tự tính ra thống kê cho cả dự án: dự đoán effort của từng người, trạng thái bug, các chỉ số chất lượng và cả chart, mỗi thứ đổ ra theo từng file. Bạn không phải nhập tay hay dán số liệu nữa.

▸ 3. Giá trị của việc tự động hóa

Sức mạnh của tool nằm ở chỗ lặp lại nhanh: mỗi ngày chỉ cần chạy lại là data mới được cập nhật và mọi chỉ số, chart tự tính lại, giúp bạn nắm tình hình dự án tức thì mà không tốn công. Đây là công cụ giảng viên tự viết và sẽ chia sẻ cho học viên tham gia khóa quản lý dự án bằng Redmine. Đến đây bạn đã đi hết hành trình QA — từ khái niệm, kiểm soát chất lượng từng giai đoạn, đến thống kê và tự động hóa phân tích.